xhotplugd -- project idea

xhotplugd -- project idea

[Ilya Konstantinov]

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

Re: xhotplugd -- project idea

[Bill Nottingham]

Ilya Konstantinov (anon1@future.shiny.co.il) said: 
> For example:
> - Plugging in a wheel mouse would set the correct protocol and switch
> the device from /dev/psaux to /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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: xhotplugd -- project idea

[Greg KH]

On Fri, Jun 14, 2002 at 05:34:48PM +0300, Ilya Konstantinov wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: xhotplugd -- project idea

[Tim Jansen]

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...

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

xhotplugd -- project idea

[Chris Hanson]

   Date: Fri, 14 Jun 2002 19:55:22 +0200
   From: Tim Jansen <tim@tjansen.de>

   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...

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

Re: xhotplugd -- project idea

[Ilya Konstantinov]

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

Re: xhotplugd -- project idea

[Tim Jansen]

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).


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

Re: xhotplugd -- project idea

[Ilya Konstantinov]

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

Re: xhotplugd -- project idea

[Tim Jansen]

On Saturday 15 June 2002 02:48, you wrote:
> 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

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

Re: xhotplugd -- project idea

[Jim.Gettys]

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
Jim.Gettys@hp.com


----------------------------------------------------------------------------
                   Bringing you mounds of caffeinated joy
                      >>>     http://thinkgeek.com/sf    <<<

_______________________________________________
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

Re: xhotplugd -- project idea

[Ilya Konstantinov]

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

Re: xhotplugd -- project idea

[Jim.Gettys]

> From: Ilya Konstantinov <anon1@future.shiny.co.il>
> Date: 19 Jun 2002 23:19:06 +0300
> To: Jim.Gettys@hp.com
> Cc: linux-hotplug-devel@lists.sourceforge.net
> 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. 

> 
> 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.

> - 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.
> 
> 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...)

> 
> 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?".

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.


> 
> 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.

> 
> 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.

>   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
Jim.Gettys@hp.com



-------------------------------------------------------
                   Bringing you mounds of caffeinated joy
                   >>>     http://thinkgeek.com/sf    <<<

_______________________________________________
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

Re: xhotplugd -- project idea

[David Brownell]

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