Re: xhotplugd -- project idea

[Ilya Konstantinov <anon1@future.shiny.co.il>]

On Fri, 2002-06-14 at 20:55, Tim Jansen wrote:
> On Friday 14 June 2002 16:34, Ilya Konstantinov wrote:
> >   2. Providing a way to run graphical (X) applications on HotPlug
> > triggers. xhotplugd would not provide a GUI, but only means for
> > applications to "register" a file to be executed upon a HotPlug event.
> 
> Functionality like this is certainly needed and I would be insterested in 
> helping to realize it. But you could probably also extend the the current 
> hotplug script to communicate with GUI apps. What you would need is a 
> script/program that can send events to the GUI apps, for example by sending 
> information about the event to a named pipe. A daemon of the desktop 
> environment could then listen to that pipe. The advantage of this solution is 
> that a) you can base such an app on the current hotplug system and b) you do 
> not depend on X11, it would also work for console/DirectFB/etc...

A named pipe?
I see the following problems:
1. It's clear that hotplug cannot have the listening side of this named
pipe, since hotplug isn't a daemon.
2. If the desktop environment has the listening side of the named pipe,
that means hotplug will need to search for all currently running desktop
environments on the machine.
That is why my proposal is to use an on-disk file for communications.
Don't worry - the disk buffering is effective enough to make the impact
of using the disk storage neglectible.

The xhotplugd is just the X11-specific daemon. There could be a
chotplugd for the console, which each user would run in their shell's
startup script.

Why not leave this daemon to be implemented differently by each desktop
environment? Because of the need to standardize Linux. The desktop
environments might compete on whoever offers the most user-friendly way
to configure our daemon, but the daemon would still be the same, and no
mater whether you start a GNOME or a KDE session, your "launch upon
insertion" configuration would still stay.

Another reason not to leave it to the desktop environment is that we'll
keep things like a database of keyboard-to-xkb-model mappings unified.

> >   - xhotplugd needs a way to "replay" hotplug events as-if they've just
> > occured upon startup (to simulate insertion of all existing devices).
> > Things like keyboard and mouse can and should be configured right on
> > startup, while running applications for hotplug events should wait until
> > X session loads completely.
> 
> I am not sure whether this is neccessary. You won't be notified about changes 
> in the non-hotpluggable system configuration, so the desktop environment can 
> not avoid to scan the system on startup anyway.

I simply want to unify the treatment of existing devices and "hotplug"
additions. For example, so that the same code that would reconfigure the
keyboard model upon plugging-in a different keyboard would work to
configure the initial keyboard.



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel