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.
This resets to before the ad-hoc input hotplug state, ports that to
current server ABI, adds input hotplug integration, and re-adds support
for absolute coordinate events and XKB. Several other small fixes were
cherry-picked from the new 1.2 branch.
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.
Large parts of the manpage were obsolete and confused users. Current state should reflect all available driver options. Some details are still missing.
The message "cannot open input pEvdev" resulted in a lot of bug reports of confused users that did not
supply a device path. Now we tell them when it is missing or print out a reason when device open fails.
xorg-server won't generate soft autorepeat, when interval/delay are at default of 40/660 (see xkb/ddxCtrls.c:
XkbDDXUsesSoftRepeat). When we hit the defaults, we let the kernel autorepeat pass, if we differ, we swallow them all
and let the server figure out autorepeat in software.
Not just filter modifiers but every repeated key, because the software implementation will take care of what key to
repeat and what not. Otherwise the kernel's autorepeated keys interfere with the software generated ones.
We do autorepeat in software now. Informing the kernel would change the autorepeat speed on virtual terminals, which is
probably not wanted so we leave the settings untouched.
VMware's absolute pointing device does not have a pressure/touch button.
Although evdev correctly recognizes this, it sets "use_touch" for X and Y axes
regardless of the touch button. This patch clears the USE_TOUCH flag for the X
and Y axes if the device does not have a touch button.
* Use \- (ASCII dash) instead of - (hyphen), where appropriate
* Use a roff escape instead of a UTF-8 character.
* Consistent use of quote characters.
* Consistent use of typographic conventions:
italic "n" in place of "<N>" or "integer" or "number",
bold for option names, bit maps, etc.
Debian bug #446118
Set and use the X mode control, letting XInput see it properly.
Kill some cruft.
evdev.h:
Set and use the X mode control, letting XInput see it properly.
evdev_axes.c:
Set and use the X mode control, letting XInput see it properly.
evdev_key.c:
Remove some cruft, the bell func can be NULL now, so do so.
Don't bother looking for keys above 0xF7 until we can actually do
something with them.
(Old configs don't.)
evdev.c:
Add EvdevParseMapToButton and EvdevParseMapToButtons to evdev_map_parsers.
Add EvdevParseMapOption to search through evdev_map_parsers.
Fix up EvdevTokenize to handle the evdev_option_token_t changes.
EvdevAxesNew0 after BtnNew0 instead of before now.
(This isn't the right fix.)
evdev.h:
EVDEV_MAXBUTTONS -> BTN_MAX.
Redid evdevBtnRec with the new mapping goodness.
Removed v_min and v_max from evdevAbsRec.
Reworked evdev_option_token_t, no union, no is_chain.
If it's a chain, it still has a string, but the chain pointer is set.
EvdevParseMapToButton, EvdevParseMapToButtons, and EvdevParseMapOption.
evdev_axes.c:
Kill off EvdevAxesMapButton, a variant lives in evdev_btn.c now.
Changes for the evdev_option_token_t changes.
Use EvdevParseMapOption instead of repeating the contents twice.
Disable EV_ABS_V_INVERT for the moment. (Better fix maybe needed.)
evdev_btn.c:
s/Ptr /Rec */g
EvdevMapButton and parser.
EvdevMapButtons and parser.
Nuke EvdevBtnCalcRemap as a whole.
Move everything but the alloc to New1 from New0.
New mapping code, same guts os the axes mapping code even.
evdev.h:
Switch to flags in the abs and rel structs.
Add the axes struct, and defines.
Rework the abs and rel structs, moving stuff to the axes struct and moving
everything to the new mapping handling.
Add the structs and function declarations for the new tokenization stuff,
parsing stuff, and mapping stuff.
evdev.c: Add EvdevTokenize, and the evdev_map_parsers list.
evdev_axes.c:
Basicly a full rewrite, big, messy.
We now use a completely different mapping setup for axes, and mapping to
buttons is currently missing.
However we now handle ABS_CALIB and ABS_AREA, including rotation in both
rel and abs modes.
evdev_btn.c:
Disable lots of code and break things horribly, we compile but we don't
work very well.
Fixing this is next on my todo list.
