xhotplugd -- project idea

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

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel