Re: xhotplugd -- project idea

[<Jim.Gettys@hp.com>]

> 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