On Thu, Jan 30, 2014 at 12:46:12PM -0500, James Cloos wrote: > [Still slowly catching up -JimC] > > >>>>> "PH" == Peter Hutterer <peter.hutte...@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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel