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

[Waldo Bastian]

On Friday 29 July 2005 16:49, Jim Gettys wrote:
> 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

So to what extent is RegisterBlockAndWakeupHandlers not adequate then?

Cheers,
Waldo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050803/b8bf6f22/attachment.pgp>