Input Devices (was: Re: [Xgl/Xegl] Input Devices )

Johnson, Charles F charles.f.johnson at
Mon Aug 1 09:43:06 PDT 2005

This discussion seems to have wandered afield with the "multiseat"
subject seeming to replace it.  

Going back to the "Input Devices" subject, as a summary it sounds to me
like there is desire to move input device arrival and removal detection
to a daemon external to the X server ??  Then it detection mechanism
could be taylored to the specific OS/System it is running on with a
standard interface to the X server ??  Or am I reading too much into the
discussion so far ??

Charles Johnson
Intel Corp.
charles.f.johnson at

>-----Original Message-----
>From: xorg-bounces at [mailto:xorg-
>bounces at] On Behalf Of Jim Gettys
>Sent: Friday, July 29, 2005 7:49 AM
>To: Waldo Bastian
>Cc: xorg at
>Subject: Re: Input Devices (was: Re: [Xgl/Xegl] Input Devices )
>On Fri, 2005-07-29 at 14:10 +0200, Waldo Bastian wrote:
>> > It probably is better to use DBUS, for much of it, though we'll
have to
>> > figure out some way to send the file descriptor.  The issue here is
>> > the current internals of the X server do no have the ability for
the X
>> > server to become a client of another server (in this case, DBUS);
>> > might deadlock.
>> Even though the X server would communicate with the dbus server,
>> conceptually speaking, the X server still be the server in this case?
>> dbus connection would just be another connection for clients to
>> the xserver and send commands to the X server.
>> I can see deadlock potential if the X server was to make calls across
>DBUS and
>> blocked waiting for a response, but I don't think there is a need for
>> First of all, with a configuration client, the X server itself would
>> to be making any calls. Second, if it would need to make a call it
>> the call asynchronously and the response would come back later,
>> like other incoming dbus calls.
>> All that is needed is a way to register a fd and have the X server
>activate a
>> callback when something happens on that fd. Is that possible at the
>> or does that require reorganizing the X server internals first?
>Not really; the server implementation has all combinations of
>needed *except* for the one we need, and the code is pretty gross.
>Kristian took a close look at this last fall before he was diverted to
>helping complete Cairo (a correct call, btw; the pdf and postscript
>backends are vital for it).
>Rather than just hacking something in, I'd prefer to build a proper
>general facility, use it, and then we can gradually migrate all the
>existing uglyness over to it, resulting in a much cleaner server
>implementation.  I suspect it is a few weeks to a month's work to build
>the new select/poll facility.
>				Regards,
>					- Jim
>xorg mailing list
>xorg at

More information about the xorg mailing list