[Pkg-utopia-devel] Addition of Arnaud Quette to work on Convergence (Python uPnp)

[Arnaud Quette]

2007/6/5, Sjoerd Simons <sjoerd at spring.luon.net>:
> On Tue, Jun 05, 2007 at 10:57:22AM +0200, Arnaud Quette wrote:
> > Hi Sjoerd and the team,
> >
> > 2007/6/4, Sjoerd Simons <sjoerd at spring.luon.net>:
> > >On Mon, Jun 04, 2007 at 02:01:33PM +0200, Arnaud Quette wrote:
> > >...
> > >Welcome! Feel free to join #debian-utopia on freenode IRC, which is where
> > >most
> > >of us usually hang out :)
> >
> > thanks
> > I'll try someday to join #d.u, though it's still a bit hard at home
> > (two sons, 7 months and 3 years).
> > so for the moment, async (mail) comm. is still my preferred way.
>
> No worries. Mail is fine too :)
>
> > >One thing i was wondering, Does UPNP need a server for service discovery
> > >(just
> > >like avahi-daemon for dns-sd?). If so, any idea how that would work when
> > >multiple UPNP stacks are used on a system ? For example when also using
> > >GUpnp
> > >(http://gupnp.org/). I wouldn't be surprised if rhythmbox would get a gupnp
> > >based upnp plugin RSN.
> >
> > I'm not sure exactly for the moment.
> > on the SSDP server side (seems to be 1900/udp & tcp, as per IANA), the
> > conflict will be obvious.
> > on the client side, I'm not sure! coherence advertise to have a
> > msearch client in its features, but the graphic is talking about a
> > msearch server (I interpret this as a daemon for discovery).
> >
> > I still have to talk with the upstream () who was on holidays and will
> > raise this discussion...
>
> k, cool! Might be good to also involve the gupnp guys in this and get some
> synergy going if needed :)

I've had a talk with Frank (coherence author) and seems there will be
no conflict between coherence and gupnp. Since the server socket
(1900/tcp,udp) is opened in shared mode:
http://svn.o-hand.com/view/gupnp/gssdp/libgssdp/gssdp-socket-source.c?rev=176&r1=128&r2=176

and a coherence 0.3 release is underway. scheduled by the next week.

> > As a side note, on the Utopia topic, I have some upstream efforts underway:
> >
> > - I'm currently finishing the Network UPS Tools 2.2.0 release, which
> > brings the HAL bridges.
> > a package, called nut-hal-drivers (provided hal-ups-support) will be
> > shipped, and should be integrated in the base system without having
> > HAL depending on it. This would allow the removal of this package in
> > favor of a classic nut install (which provides more feature for
> > enterprise class)
> > Any thoughts / comments? also who to bug and lobby for such things?
>
> I'm not sure what kind of intergration you want here. But wrt. to hal, feel
> free to make the changes you need in our svn if their reasonably small and
> self-contained. For bigger/more intrusive ones, please first discuss them on
> the mailing list/IRC with either me or mbiebl.

in fact, there's nothing to do on hal pkg (apart from putting a
Suggests: hal-ups-drivers in the control file).

The big point is to the have hal-ups-drivers installed by default with
hal, without having a Depends on it (either in hal or in any other
package). Since we want to be able to uninstall nut-hal-drivers and
replace it with nut (classic UPS support) without removing HAL.

not sure if I'm clear enough!?

> > - I'm also making some major LIRC enhancements, and I'm considering
> > the same kind of HAL bridging. More info:
> > https://wiki.ubuntu.com/RemoteControls
>
> I didn't look in detail at this. But feel free to add it to pkg-utopia or to
> the HAL packaging.

this was more for info for the the moment.

> But just wondering. Is LIRC going to move to the input layer
> in the end too, like the various multimedia/special keys are going now too..

in the end, maybe but still unsure. The last time we sit around a
table between Christoph (lirc), Vojtech (Linux  Input) and I, there
were some heat in the air.
This time, I'm using an iterative method ;-)
The lirc key naming will now follow the Linux Input naming (as of lirc
0.8.3), which is a good first step.

Next, LIRC will get merged in the kernel mainline (btw, I'm searching
for kernel hackers with a bit of free time and motivation here!!),
which is a good 2nd step.

The 3rd one will be HAL I think. Since this is the best level to
consolidate things, and many projects, like xorg, seems to move to
this layer for input management.
For example, composite devices (like a wiimote) exposing several
devices (some usb remotes claims to be both a keyboard and a mouse)
will so be reconsidered as 1 device...
But I still have to think more about that.

> Actually my simple nice wireless remote actually acts as a keyboard (with the
> buttons are the standard shortcuts of popular win32 apps).. And i'm using
> inputlirc to map those to LIRC.. I'd quite like improvements in that area :)

yep, the beauty of the HID standard ;-)
this is true for USB, bluetooth and maybe others... I once worked a
lot in this area, with Vojtech and others, mostly for UPSs things. But
I also produced the userland libhid for others...

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/