[PATCH 01/12] dbus-core: Move to hw/xfree86/common dir

Jasper St. Pierre jstpierre at mecheye.net
Thu Jan 30 14:43:04 PST 2014

It would mean that we can finally use malloc(); and other reentrant-unsafe
functions in that codepath, which would be a really good code cleanup.

On Thu, Jan 30, 2014 at 5:14 PM, Peter Hutterer <peter.hutterer at who-t.net>wrote:

> On Thu, Jan 30, 2014 at 12:46:12PM -0500, James Cloos wrote:
> > [Still slowly catching up -JimC]
> >
> > >>>>> "PH" == Peter Hutterer <peter.hutterer at who-t.net> writes:
> >
> > PH> my long-term plan is to replace xf86-input-* with
> xf86-input-libinput.
> > PH> that is/will be a wrapper around libinput which provides almost
> drop-in
> > PH> functionality for the other drivers, including a couple of things
> that
> > PH> weren't possible before with the current driver model.
> >
> > Back when the attempts were made to move input into a separate thread,
> > it occurred to me that we should move input to separate executables.
> >
> > Ie, have the server listen(2) on a socket for input events, rather than
> > link in drivers.
> I think that's splitting along the wrong line. The base idea of input
> threads was to have event generation and event processing in separate
> threads. The former happens inside the SIGIO handler atm, the latter as
> part
> of the mainloop.
> Event generation includes all the driver handling but also the visible
> cursor sprite update - which is where the whole SIGIO idea came from.
> If you split the drivers out into a separate process, you'd split halfway
> through event generation. Which doesn't really get you that much benefit
> other than more latency (the driver polls the fd, then writes to the pipe,
> the server polls the pipe and then updates the cursor sprite).
> A good idea would be to measure if taking away the SIGIO handling from
> drivers has any noticable effects these days. But tbh I don't know how to
> measure this. The actual change is easy though, replace all
> xf86AddEnabledDevice() with AddEnabledDevice() in the drivers (same for the
> remove calls).
> Cheers,
>    Peter
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140130/7398de0a/attachment.html>

More information about the xorg-devel mailing list