On Wed, Jan 29, 2014 at 05:30:22PM -0800, Keith Packard wrote: > Peter Hutterer <[email protected]> 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
