This failed on devices without a middle button, we just didn't have a test
device to trigger this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't have the same libevdev context that libinput has so if libinput
disables/enables event codes we don't see that and may get unexpected
behavior in the test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This device has BTN_LEFT, BTN_RIGHT, BTN_FORWARD and BTN_BACK, add the
missing range to the pad init function.
https://bugs.freedesktop.org/show_bug.cgi?id=99785
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
makes it easier to filter out debugging messages
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libinput-debug-events prints keycodes as they come in. This makes it dangerous
to be run by users (especially in the background) because it will leak
sensitive information as it is typed. Obfuscate the base set of keycodes
by default, require a --show-keycodes switch to show it.
The few times we actually need the keycodes, we can run the switch in the
debugging tool.
This does not affect keys outside of the main block on the keyboard (F-keys,
multimedia keys).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This will eventually feature the architecture diagrams, etc. But for now it's
mostly just a list of what will be and what won't be supported.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
dwt is needed on internal touchpads only and those external ones that are a
combo device. This also now gives us the same check for palm detect and dwt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Specify the layout of the combo so we know when to initialize palm detection.
This allows us to drop palm detection on external touchpads otherwise,
replacing the wacom-specific check with something more generic..
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Simplest implementation for what we need right now, it turns off an event on
the evdev device and turns it back on again. This allows us to change bits in
the 'normal' event stream, such as changing the tool type without triggering
proximity events for the BTN_TOOL_PEN that all test devices send by default.
This won't work for absolute devices because we need to re-enable with a
struct input_absinfo. But we don't need that ability for now anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't initialize click methods on devices with physical buttons. This model
is a special case, it's not a clickpad but it only has one button (because one
button is all you ever need and whatnot).
https://bugs.freedesktop.org/show_bug.cgi?id=99283
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't init the required /sysfs files, so let's not spew a lot of warnings
during the test suite.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Usually we reply INVALID before we reply UNSUPPORTED but that's only for those
values where the value is a programming error. But in this case it's a bit
more complicated. INVALID is only for the cases where the button doesn't exist
on the device, if we don't have button scrolling at all then we have
UNSUPPORTED for all.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not much we can do here, our virtual devices don't have the sysfs files
required, so they have 0 modes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Set the dispatch type on creation, then check that whenever we try to get the
dispatch struct. This avoids a potential mismatch between the backends.
Plus, use of container_of means we're not dependent on the exact layout
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These tablets only ever give us a close event, the open event is broken. So
when we detect keyboard events, fix the kernel device's state by writing the
event to the fd.
We still sync the lid state manually, in case this fails and we don't get the
SW_LID through the normal event sequence. If it works fine, the real open
event will just be ignored.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the chassis type is 9 or 10 (Laptop, Notebook) let's assume that our lid
switch works. On anything else we leave it at unknown.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
