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

[Peter Hutterer]

On Wed, Jan 29, 2014 at 05:30:22PM -0800, Keith Packard wrote:
> Peter Hutterer <peter.hutterer at who-t.net> writes:
> 
> 
> > For several server releases few changes in the drivers have actually
> > required API changes. Merging the drivers back in is a lot of work for
> > currently little benefit.
> 
> Is that mostly because the drivers aren't in the server and API changes
> are hard? Reading through the systemd integration, I wonder if we've hit
> a point where allowing the API to change a lot would be good.

of the things that need fixing in the input drivers right now, only one is
actually caused by the server design, not the API. 

specificially: the ability to communicate between modules so that a device
running with synaptics can talk to an evdev device and influence the
events, etc. 

that could be fixed without merging, it just means accessing structs we
don't access right now and having driver headers cross-pollinate each other.
Ugly, but possible.

yes, that'd be easier if we had all drivers in the server, but mainly
because that way we can rely on the driver being available and known to the
other driver. what you'll lose there is the ability to have separate modules
though (which is mostly a blast from the past anyway) and you'll end up with
essentially one input blob that handles everything. at which point the
server API doesn't matter much anymore because you only have one driver
anyway.

and that's exactly what I'm working on right now with libinput*.

regarding the systemd patches: it can be fixed with a simple flag in the
InputDriverRec that announces whether the driver supports pre-loading the
InputInfoPtr with an already-open flag. That's hardly a massive change. The
discussion was mostly whether we need the flag or could use a new API call
instead because it requires one less ifdef in the drivers.

> I do know that I've spent an awful lot of time doing cross-package
> changes just to fix warnings in the X server, and I suspect the major
> reason those have been lingering for so long is precisely because that
> amount of cross-package work is painful...

For me the main reason they've been lingering for that long is because
fixing them properly is time-consuming for little gain. I've started with
various warning fixes over the years but usually gave up after a few because
there were more pressing things to fix.

Cheers,
   Peter
 
* sorry, BSDs, Solaris, etc. start using evdev already.