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

[Peter Hutterer]

On Thu, Jan 30, 2014 at 05:43:04PM -0500, Jasper St. Pierre wrote:
> 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.

in the driver, yes. but not in the server unless you drop the SIGIO-handler
reading from the separate driver process. but then you're already not using
SIGIO handling in the driver process at which point the question raises: why
not just do exactly that in the server?

Cheers,
   Peter

PS: Ignore this email if you were talking about dropping SIGIO anyway


> 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
> >
> 
> 
> 
> -- 
>   Jasper