SetDeviceMode protocol update and server behaviour

[Peter Hutterer]

While dealing with bug 25915 I noticed that the server behaviour for the
SetDeviceMode request is inconsistent. The SetDeviceMode request changes the
mode of an input device from absolute to relative - provided the device
(driver) supports it. Note that this doesn't change the the coordinates
reported to the clients, just the way the device behaves.

The protocol spec claims the errors may be DeviceBusy, BadMode and BadMatch
but doesn't detail when BadMode is to be returned. The XSetDeviceMode(3) man
page is more detailed, claiming BadMatch for devices without valuators and
BadMode for invalid modes. This also makes seems to make more sense.

In regards to driver support it's a mess as usual. Of the drivers still
enabled in the build.sh file only aiptek supports the switch mode and
returns BadMatch from the driver. Wacom supports the switch mode with the
same behaviour. Other drivers that are of marginal importance (penmount,
citron, dmc) report !Success on failure.

This patch set updates the inputproto specification to be the same as the
XSetDeviceMode(3) man page and adjusts the server behaviour accordingly. In
theory that changes client behaviour but I haven't yet found a client that
actually cares that instead of BadMatch we would now return BadMode.
These clients should have failed for errors of !Success (which we always
returned so far), casting some doubt onto their existence.

Cheers,
  Peter