From mboxrd@z Thu Jan 1 00:00:00 1970 From: Date: Thu, 20 Jun 2002 14:06:30 +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 > From: Ilya Konstantinov > 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