From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Konstantinov Date: Sat, 15 Jun 2002 00:22:34 +0000 Subject: Re: xhotplugd -- project idea Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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