In the mouse driver, these options are only used if XFree86LOADER is
undefined. configure.ac in the xserver forces said define to 1 if we're
building the xfree86 DDX, so I don't see the point of having them around.
Especially since they weren't used in evdev anyway.
This is a bit of a mess. The MS Optical Desktop 2000 registers both relative
and absolute axes on the same device (the mouse). The absolute axes have a
valid min/max range for x/y and thus overwrite the x/y relative axes in the
server (no, this is not a server bug). And I wouldn't be surprised if other
devices have similar issues.
Since the device only sends relative events after that, the mouse is
essentially restricted to the min..max range of 0..255. The server simply
doesn't do unrestricted relative axis and restricted absolute axis on the same
device (not for the same axis numbers anyway).
Not many mice do this, but some do, Apple Mighty Mouse in particular, and
it makes click-and-drag pretty much impossible to use.
Arguably we should filter _all_ repeat events from the kernel and handle
synthesizing them in the server.
Don't do this in the button map. That's writeable by clients, which means
they have the chance to get it wrong. Just swap right and middle around
in event dispatch before you get to the user's map.
Even though we don't have keycodes for anything above 127, make sure our
map always covers up to 255. This ensures that the keycode range never
changes.
Spiritually cherry-picked from a9e87f29cc
and 6db4a9fb84.
There are two major classes here, touchscreens and touchpads. Touchpads
are logically more like relative devices, in that your initial touch
should not warp the cursor. So attempt to detect touchpads (via the
existence of BTN_TOUCH) and translate absolute events from those devices
to relative motion.
