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