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

[Jim Gettys]

You read correctly: modern systems have some sort of hotplug mechanism.

I've been thinking that using DBUS as the way to talk to X itself might
be the way to go.

On systems without modern hotplug facilities, a configuration file could
be read and the server informed what to do from that.

In any case, agents external to the window system should decide if an
input device is to be assigned to the X server.  Those agents are likely
to consult some form of storage so that you don't have to answer the
same question each time (what process each input device should be
assigned to).

				- Jim


On Mon, 2005-08-01 at 09:43 -0700, Johnson, Charles F wrote:
> 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 intel.com
> 
> >-----Original Message-----
> >From: xorg-bounces at lists.freedesktop.org [mailto:xorg-
> >bounces at lists.freedesktop.org] On Behalf Of Jim Gettys
> >Sent: Friday, July 29, 2005 7:49 AM
> >To: Waldo Bastian
> >Cc: xorg at freedesktop.org
> >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
> >that
> >> > 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);
> it
> >> > might deadlock.
> >>
> >> Even though the X server would communicate with the dbus server,
> >wouldn't,
> >> conceptually speaking, the X server still be the server in this case?
> The
> >> dbus connection would just be another connection for clients to
> connect
> >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
> >that.
> >> First of all, with a configuration client, the X server itself would
> not
> >need
> >> to be making any calls. Second, if it would need to make a call it
> could
> >make
> >> the call asynchronously and the response would come back later,
> pretty
> >much
> >> 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
> >moment,
> >> or does that require reorganizing the X server internals first?
> >>
> >
> >Not really; the server implementation has all combinations of
> facilities
> >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 lists.freedesktop.org
> >http://lists.freedesktop.org/mailman/listinfo/xorg
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg