xserver: Branch 'master' - 16 commits

[Keith Packard]

Michel Dänzer <michel at daenzer.net> writes:

> This commit broke input for me with xf86-input-libinput. No keyboard or
> mouse input is received. There are no errors in the log file.
>
> xf86-input-evdev works.

Ok, I spent some time yesterday figuring out what happened here. The
issue is that xf86-input-libinput is using AddEnabledDevice to register
file descriptors for input devices, and expecting that xf86Wakeup would
call the driver when input became available.

The problem is that without passing the set of ready file descriptors to
xf86Wakeup (the whole point of this series), there's no way for
xf86Wakeup to discover that input is available on a file descriptor
registered behind it's back through AddEnabledDevice.

Once the select mask is gone from the wakeup handler, AddEnabledDevice
and AddGeneralSocket are no longer as useful -- there's no way to
discover when the associated socket is ready for I/O without polling on
the descriptor each time the server wakes up (which is actually done in
several places in the server, including DMX and Xnest).

With the NotifyFD interfaces in place, I think it would be best if we
eliminated the AddEnabledDevice and AddGeneralSocket interfaces from the
OS layer. Most code using these in the core server has been changed to
use the NotifyFD interface instead and I've got patches for the
remaining cases.

This leaves open the question about how to deal with xf86 input drivers
though. The reason they're using AddEnabledDevice directly and not
calling xf86AddEnabledDevice is that they want to be handled in the
normal execution flow of the X server and not asynchronously from the
SIGIO handler.

Instead of using that kludge, I'd like to suggest that we fix the
xf86AddEnabledDevice function to do what the devices need instead, by
adding a flag to the InputInfo indicating when the driver can tolerate
reading events at SIGIO time. Then, xf86AddEnabledDevice can either
register for SIGIO or call the NotifyFD intefaces as appropriate.

Here's a patch which adds a new flag (set by default, to match the
current interface) signaling which drivers can support device I/O at
SIGIO time:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-hw-xfree86-Add-XI86_SIGNAL_IO.patch
Type: text/x-diff
Size: 2460 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20151208/83400b1e/attachment-0002.patch>
-------------- next part --------------

And here's the change to xf86-input-libinput that matches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-xf86AddEnabledDevice-instead-of-AddEnabledDevice.patch
Type: text/x-diff
Size: 1587 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20151208/83400b1e/attachment-0003.patch>
-------------- next part --------------

In terms of sequencing and validating this series, here's what I
suggest:

 1) Add the X server support. No API or ABI breakages are involved
 2) Update input drivers
 3) Switch X server to use NotifyFd everywhere
 4) Remove AddEnabledDevice and AddGeneralSocket from X server

At this point, drivers not using the new interface will not run with the
changed X server as they will fail to find AddEnabledDevices, so we'll
be able to catch them quickly.

I'm willing to make the changes for each of the input drivers that are
'interesting'; only those currently using AddEnabledDevice would need
changing. Here's the list of drivers on my machine which currently call
AddEnabledDevice; I haven't actually looked inside them to know if
they actually need changing or not:

	xf86-input-calcomp
	xf86-input-citron
	xf86-input-digitaledge
	xf86-input-dmc
	xf86-input-dynapro
	xf86-input-elo2300
	xf86-input-elographics
	xf86-input-hyperpen
	xf86-input-keyboard
	xf86-input-libinput
	xf86-input-magellan
	xf86-input-magictouch
	xf86-input-microtouch
	xf86-input-mutouch
	xf86-input-palmax
	xf86-input-penmount
	xf86-input-spaceorb
	xf86-input-summa
	xf86-input-ur98

-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20151208/83400b1e/attachment-0001.sig>