Regression introduced in commit b876bc0 when building on systemds with a pre
3.11 headers (RHEL7 and derivatives).
All the DPAD defines were introduced in the same kernel commit
d09bbfd2a8408a9954, we don't need a separate ifdef check for right.
Fixes#6240
Since f472d466ec ("Remove BTN_DPAD_* keys from ID_INPUT_KEY test
(#5701)") dpad buttons are excluded from keyboard keys for keyboard
detection.
Include them in joystick buttons for joystick detection.
Assign ID_INPUT_MOUSE property to devices with mouse buttons and no axis.
Libinput tries to use libwacom on devices with tablet-pad capability
which are detected by ID_INPUT_TABLET_PAD=1 property so assign pointer
class by setting ID_INPUT_MOUSE=1 to devices with mouse buttons and let
libwacom override the class for Wacom pads.
These buttons were added specifically for joysticks with lots of buttons, no
other device should be using them. See kernel commit
cf2f765f18960 "HID: handle joysticks with large number of buttons"
We only test for BTN_TRIGGER_HAPPY (an alias for BTN_TRIGGER_HAPPY1) here, a
device that sets buttons 2 and above but doesn't set 1 is considered buggy.
https://github.com/systemd/systemd/issues/6137
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At present, devices implementing the BTN_DPAD_UP/DOWN/LEFT/RIGHT
codes will be incorrectly classified as key devices. This causes
devices respecting the Linux gamepad spec (such as the DS3 as of
kernel 4.12) to be classified as keyboards by X11.
This is caused by the test_key function checking all codes on
[KEY_OK, BTN_TRIGGER_HAPPY). Unfortunately the BTN_DPAD_* codes
are placed between KEY_LIGHTS_TOGGLE and KEY_ALS_TOGGLE. This
patch splits the upper key block check into the block before and
after the BTN_DPAD_* codes. An array is used to avoid dedicated,
per block loops in the event that more event codes are added in
the future.
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
A lot of touch screens use INPUT_PROP_DIRECT to indicate that touch input
maps directly to the underlying screen, while the BTN_TOUCH bit might not be
set.
This change switches to bools and separates bit flag evaluation from
decision making and application of udev properties, while hopefully
keeping the same semantics. Apart from using BTN_LEFT instead of BTN_MOUSE
for mouse detection.
The Trust TB7300 (relabelled Waltop?) tablet has a scrollwheel which shows
up as a /dev/input/event# node all by itself. Currently input_id does not
set any ID_INPUT_FOO attr on this causing it it to not be recognized by
Xorg / libinput.
This commit fixes this by marking it with ID_INPUT_KEY.
Reported-by: Sjoerd Timmer <themba@randomdata.nl>
input_id already (tries to) tag accelerometers as such, but this only works
for absolute accelerometers. Recent kernels mark accelerometers through an
input prop. Trust that prop and always tag devices with it with
ID_INPUT_ACCELEROMETER.
Note that detection by the prop bit works the same as the existing detection
and will ensure that no other tags get set on the device.
Also referred to as trackpoint, trackstick. These are marked by recent kernels
through an input prop. Forward that prop as udev property so userspace can
easily determine whether there is a pointing stick present.
These devices were previously marked as ID_INPUT_MOUSE, for backwards
compatibility we keep that in place, the new property is an addition.
Input devices like rudders or pedals are joystick-like; they don't have
buttons, but axes like RX, THROTTLE, or RUDDER. These don't interfere with
other device types with absolute axes (touch screens, touchpads, and
accelerometers), so it's fairly safe to mark them as ID_INPUT_JOYSTICK and thus
hand out dynamic ACLs to the user.
https://bugs.freedesktop.org/show_bug.cgi?id=70734
In trying to track down a stupid linker bug, I noticed a bunch of
memset() calls that should be using memzero() to make it more "obvious"
that the options are correct (i.e. 0 is not the length, but the data to
set). So fix up all current calls to memset(foo, 0, length) to
memzero(foo, length).