From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Konstantinov Date: Sat, 15 Jun 2002 00:48:11 +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 Sat, 2002-06-15 at 04:03, Tim Jansen wrote: > On Saturday 15 June 2002 02:22, Ilya Konstantinov wrote: > > 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. > > I would rather worry that it is more difficult to be notified about events > (you would need to mess with FAM, dnotify or something like this). dnotify could be optional. stat()ing once in a while works great too. It's not expensive really. With buffers, it won't even result in disk reads. > > Why not leave this daemon to be implemented differently by each desktop > > environment? Because of the need to standardize Linux. > > Which functionality could a daemon provide beside X11 configuration (that > could be done inside X11 as well)? The second functionality is launching programs on events. You cannot launch X clients reliably unless you're an X client yourself (since otherwise you don't have the same DISPLAY, the same XAUTHORITY; and since you need to launch the registered app on every running X server). Here I'm not sure whether it's better to have a single list or a per-desktop environment list -- since programs to launch are commonly tightly connected to the desktop environment. e.g. different "New device is found" programs, different apps to handle digital cameras etc. > I would prefer a library instead of another daemon running in background. Then > KDE could embed it as a kded module that uses standard C calls for > communication instead of a stand-alone process which communicates using > another RPC protocol. It would be important that the library can be > integrated into event loops though. In that case, I might imagine a different solution -- each desktop environment can implement its own xhotplugd, which'll base its USB-keyboard/mouse-to-model mapping on our configuration file (in /etc/hotplug/) and otherwise work as they see fit. The advantage in this method would be that the daemon could offer configuration in a method standard for the given desktop environment. The disadvantage would be that a KDE digital camera program couldn't try to register itself for Camera USB devices unless its running under a KDE xhotplugd, since it expects to talk to it via DCOP. _______________________________________________________________ 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