xhotplugd -- project idea
Dear fellow developers,
I wish to propose an additional program to the hotplug package, called xhotplugd. This daemon would be tightly connected to the base hotplug program and would provide HotPlug functionality in X.
This daemon would run in every user's X session and would be responsible for:
1. Configuring the X server on the fly (as much as possible) for added
/ removed devices. Mouse configuration (port, model) and keyboard configuration (Xkb model) comes to mind.
For example:
- Plugging in a wheel mouse would set the correct protocol and switch the device from /dev/psaux to /dev/input/mouse0.
- Plugging in a fancy new keyboard with Internet keys would call "setxkbmap -model fancynewkeyboard", making the special keys available to all applications.
- Configuring a newly inserted keyboard to have the same repeat rate as the previous keyboard.
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. Communication with the daemon would likely be through X11's ICE (DCOP etc. can be added lately, as plugins).
For example:
- A digital camera management application could register to run upon plugging in a digital camera.
- KDE could (hypothetically) register to run "khotplug-add-device" upon insertion of any new device to give the user graphical feedback (like MS Windows "New device found" dialog), or to add an icon for the device on the desktop.
Notes:
1. Those features require a separate X-based daemon since the/sbin/hotplug doesn't have permissions to access the user's X display, nor it can scan for all currently running X displays.
2. As a daemon, it would not have a GUI. Configuration and
registration of applications to run on triggers is left to GUIs, such as KDE's or GNOME's Control Center.
3. In order to remain neutral in the "desktop wars", xhotplugd
wouldn't use GTK+ or Qt. Using Xlib directly in our case shouldn't be hard (the daemon would be window-less) and is required anyway (to use extensions such as XC-MISC).
4. Communications between /sbin/hotplug and xhotplugd would be done
through an on-disk file. There are couple of reasons for this:
- its much more elegant than /sbin/hotplug contacting each running
xhotplugd's socket. The on-disk file would contain all currently plugged devices, along with their time of insertion. When the on-disk file changes, all xhotplugds would re-read it and assume all devices whose time of insertion > xhotplugd's last check to be newly added.
- sockets are naturally insecure (xhotplugd cannot know whether its
really a system hotplug sending the message); files have permissions and xhotplugd can check for strict permissions (root, non-world-writable).
- 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.
5. The core daemon would be desktop environment neutral, but would
offer desktop environment-specific access methods when a given desktop environment is detected. For example, DCOP access could be offered for KDE applications. This is not an immediate goal, of course.
-----
Comments, anyone?
Could this daemon be written in C++ or do I have to use pure C?
_______________________________________________________________
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Ilya Konstantinov
For example:
- Plugging in a wheel mouse would set the correct protocol and switch the device from/dev/psauxto/dev/input/mouse0.
Actually, the 'proper' solution for this, IMO, is just port all mice drivers to the input framework. ;)
Bill
_______________________________________________________________
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line · Ilya Konstantinov
Could this daemon be written in C++ or do I have to use pure C?
It could be written in any language you want. The kernel doesn't care :)
Good luck,
greg k-h
_______________________________________________________________
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Ilya Konstantinov
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...
Quoted 5 lines
- 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.
bye...
_______________________________________________________________
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Date: Fri, 14 Jun 2002 19:55:22 +0200
From: Tim Jansen <[email protected]>
Quoted 3 lines · Ilya Konstantinov
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...
I agree with this, although I think it doesn't go far enough. I think there's a need for a general event-signalling mechanism. This can be used in a number of contexts: hotplug events, apm/acpi events, network configuration, pcmcia. The advantage of doing it this way is that it provides a uniform signalling interface, therefore making it easier to modularize the signalling and handling code. This is as opposed to the current system, in which all of the event-signalling mechanisms have their own idiosyncratic interfaces, which nearly always are conventions for invoking shell scripts. This problem is particularly obvious in the context of laptop network configuration, in which there are many different packages, each of which is composed of several parts built into a monolithic program; if all of these programs used a standard event mechanism, they could be modularized and the end user to use each module separately, even mixing modules from different packages.
I've designed and started implementing this mechanism, and plan to deploy it both for APM and for network configuration in Debian. The design is very general, and is based on sockets so that it can easily be extended to handle inter-machine signalling if that ever turns out to be useful. The protocol will be implemented on top of BEEP, so that it is easy to maintain and to secure.
I'd be interested in discussing this further if anyone is interested. Although perhaps it's not really on-topic for this mailing list.
Chris
_______________________________________________________________
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Tim Jansen
Quoted 3 lines · Ilya Konstantinov
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.
Quoted 8 lines
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.
Quoted 9 lines
Quoted 5 lines
- 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Ilya Konstantinov
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).
Quoted 2 lines
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)?
Quoted 3 lines
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
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.
bye...
_______________________________________________________________
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Tim Jansen
Quoted 3 lines · Ilya Konstantinov
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · you
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.
You certainly need a per-desktop environment list. But I would rather let an desktop environment-specific daemon (that is based on a lib) start the apps, at least in KDE this has some advantages:
- it would be possible to implement the gui or a part of it (e.g. a system tray icon or a popup dialog) in the daemon
- KServices could be used as handler, and a KServiceType to describe the handlers for various events, which is the KDE way to do things like that.
- apps could be started using kdeinit which is faster and requires less memory
Quoted 3 lines
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.
Yes, but I dont see many apps doing this, and those that do should work without these events (in the worst case you have to restart them). Most hotplug events just trigger configuration dialogs.
bye...
_______________________________________________________________
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
I've been out of touch, due to my mail being moved and Usenix...
As others have pointed out, it probably doesn't need to be a daemon
itself: but some mechanism needs building to decide if a new input device should be handed off to the X server, and provide a gui to the user the first time a new device is added so that they can decide if it should be handed off.
The X server can listen on a named pipe, or UNIX domain socket, or some similar mechanism for notification that it should start up a new device when hotplugged. I'm not happy about stat'ing a file: the inner part of the X server is a "select" or "poll" operation, and adding another system call in the second most inner loop of the X server isn't in the cards.
I've been planning to do the X side of the equasion, to make X deal with the new input mechanism and update the XInput extension to support it. It has taken longer to get to it than I wanted, due to a longer recovery to surgery last year and some other distractions. I hope to get started in the next few weeks (as soon as I finish up some GTK+ work I'm doing.) In the meanwhile, others can hack, and/or we can work on design (always a good idea).
And yes, this should be done without tying the hands of the desktop environments...
- Jim
--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[email protected]
----------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi Jim,
Here are my comments. Hope all this discussion doesn't end up in all-talk-no-code. Seen one good discussion go that way already...
XFree-or-not
======
For things like changing the mouse protocol or tablet support on the fly, implementing the support inside XFree86's code seems reasonable, since this stuff is XFree86 specific anyway.
What's about:
- Keyboard model reconfiguration (XKB) ?
- Application invocation on plugging in new devices ?
No reason to lock down users into XFree86 for this. Linux can also display into a remote X display, and there are other X servers too.
Files or sockets
========
I preferred stat()ing a file because it allows X sessions to "poll" for new devices -- so that /sbin/hotplug wouldn't need to think "How do I find all X sessions which are running on this machine? Where are those little notification sockets which every X session has opened for me?".
Having something like /var/run/hotplug-sockets/ containing sockets of all X session looked much messier and error-prone to me than a single /var/run/hotplug-state.xml.
Desktop environments or not
=============
For the mouse / Xkb model switching functionality, an X-wide solution looks smarter.
For custom application events / launching functionality, a desktop environment specific solution seems a better idea because:
1. Programs could get notifications in the desktop environment's
standard fashion, e.g. DCOP. Using ICE directly is unnecessarily difficult. Forcing everyone to link with a special library which'll talk ICE for them is a library overkill.
2. Mostly users would want a GNOME photo app to launch on plugging
their camera when running GNOME, and a KDE photo app to launch when running KDE, so there's little benefit in "unifying the app-launching-on-event". Even the "New Hardware Was Found" dialogs would be different.
----------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines
From: Ilya Konstantinov <[email protected]>
Date: 19 Jun 2002 23:19:06 +0300
To: [email protected]
Cc: [email protected]
Subject: Re: xhotplugd -- project idea
-----
Hi Jim,Here are my comments. Hope all this discussion doesn't end up in all-talk-no-code. Seen one good discussion go that way already...
I sure hope not: surgery hit me harder than expected (not to mention the mergery also going on between HP/Compaq), and I'm anxious to make progress.
Quoted 9 lines
XFree-or-not
======>
For things like changing the mouse protocol or tablet support on the fly, implementing the support inside XFree86's code seems reasonable, since this stuff is XFree86 specific anyway.What's about:
- Keyboard model reconfiguration (XKB) ?a
I need to go look at Xkb: it came along after I stopped working on X. I've spent some time looking at Xinput, however.
Quoted 1 line
- Application invocation on plugging in new devices ?
Not the X server's business; perfectly reasonable to implement outside of the X server; in fact, the only sane way.
There is an issue lurking though: authentication. To connect to the X server, you need reasonable credentials.
Quoted 3 lines
No reason to lock down users into XFree86 for this. Linux can also display into a remote X display, and there are other X servers too.
Yup. This brings the the real surface the authentication problem.
Another approach is to make it possible for a X client application to notice new devices, and start up the X application on the X client side (for X applications). This would finesse alot of the authentication problems, but present other problems (hot plug invoking an X application when no one is logged in). There are some obvious ways to potentially do this with xdm/gdm/kdm (would that the desktop projects could get together on a single display manager; sigh...)
Quoted 8 lines
Files or sockets
========I preferred stat()ing a file because it allows X sessions to "poll" for new devices -- so that
/sbin/hotplugwouldn't need to think "How do I find all X sessions which are running on this machine? Where are those little notification sockets which every X session has opened for me?".
I'm talking about the X server itself noticing new devices. It is easy to arrange some mechanism to inform all interested X clients; this is inherent in the X server's implementation. We may need to rev the Xinput extension for such notification, but this is straight forward.
Remember, your clients (or session manager) may not all be running on the same machine; so stat'ing files for clients is a non-starter.
Having the X server stat for new devices just isn't feasible. Do a "x11perf" sometime and notice the rate at which the X protocol does operations (measured in millions/second). The X server needs somehow to notice new devices via something it can select or poll on.
I think some simple protocol where the name of the new device is sent via a socket is likely sufficient.
Quoted 4 lines
Having something like
/var/run/hotplug-sockets/containing sockets of all X session looked much messier and error-prone to me than a single/var/run/hotplug-state.xml.
No, not necessary, see above.
Quoted 11 lines
Desktop environments or not
=============>
For the mouse / Xkb model switching functionality, an X-wide solution looks smarter.
For custom application events / launching functionality, a desktop environment specific solution seems a better idea because:
1. Programs could get notifications in the desktop environment's
standard fashion, e.g. DCOP. Using ICE directly is unnecessarily difficult. Forcing everyone to link with a special library which'll talk ICE for them is a library overkill.
Notifications can be arranged without using ICE; this is easy to do.
Notification is bread and butter for X servers; the general event model is:
"application says its interested in something", and the server sends all interested applications events when things happen. It is done all the time. At worst, we add an event to Xinput, or build a new extension. Not a problem.
Quoted 5 lines
2. Mostly users would want a GNOME photo app to launch on plugging
their camera when running GNOME, and a KDE photo app to launch when running KDE, so there's little benefit in "unifying the app-launching-on-event". Even the "New Hardware Was Found" dialogs would be different.
Yup. And the end user needs to be able to control what gets invoked.
But for embedded uses, we need to make a solution that can work even if no-one is logged in.
- Jim
--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[email protected]
-------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines
Here are my comments. Hope all this discussion doesn't end up in all-talk-no-code. Seen one good discussion go that way already...
If you have keyboard and are willing to code, you can help prevent that resolution ... all it needs is one volunteer to provide a simple prototype!
I'd suggest starting with getting a dialog to pop up on the local X11 display. I think the workable approach is likely to have a way for a hotplug agent to use some named local contact point (like a socket or pipe, probably in /var/run) is enough. Given such a core mechanism, and contributors, the rest can evolve.
The X11 server would be best at seeing the input hotplug events (available in 2.5 kernels). For cases like network interfaces that have never been seen before, some administrative GUI would be the right thing to pop up.
- Dave
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel