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