Easier to track if we leave the original files alone. Actual changes to the
doxygen style:
* indent <dd> blocks
* hide the navigation sub-items. Our current style expands the full navigation
menu but File-list, etc. is mostly useless and just wastes space.
* force some space below the main bar
* change the header sizes around a bit. Primary goal here: making <h1> smaller
than the title
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
This will allow switch devices known to libinput to be exposed. Currently,
this is SW_LID.
libinput also handles switch events internally, e.g. a laptop touchpad will
be disabled autmoatically when the lid is closed. This is transparent to
the caller, although the caller will also receive the event. See
https://bugs.freedesktop.org/show_bug.cgi?id=86223
This features is intended to be the main driver for the interface.
Co-Authored-By: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: James Ye <jye836@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
freedesktop.org always serves https for the documentation. if Mathjax is
pulled in from http, browsers reject it [1]
Let's take the default doxygen value but just add the https to it. In the
future we should just ship a copy of mathjax with our documentation.
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content/How_to_fix_website_with_mixed_content
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Wheres-my-beer-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
So far we've relied on the wacom kernel module to do touch arbitration for us
but that won't be the case in upcoming kernels. Implement touch arbitration in
userspace by pairing the two devices and suspending the touch device whenever
a tool comes into proximity.
In the future more sophisticated arbitration can be done (e.g. only touches
which are close to the pen) but let's burn that bridge when we have to cross
it.
Note that touch arbitration is "device suspend light", i.e. we leave the
device enabled and the fd is active. Tablet interactions are comparatively
short-lived, so closing the fd and asking logind for a new one every time the
pen changes proximity is suboptimal. Instead, we just keep a boolean around
and discard all events while it is set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Don't fork by default if we're in gdb.
Note that is_debugger_attached() is now inside #ifndef LITEST_NO_MAIN, gdb for
the litest selftest will now require a manual CK_FORK=no.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a make-like -j/--jobs option to split the number of parallel test
processes. Defaults to 8 if not specified, future patches will default this to
1 for special cases where filters are specified or gdb is detected.
Each subprocess overwrites argv[0] to be easier identifiable in the ps
output when we're trying to figure out which tests are still running.
A -j1 is equivalent to the previous functionality, i.e. we don't fork.
One quirk needed for check: any test case not part of a test runner will not
be freed and thus triggers valgrind. We do test filtering by splitting
up the tests across multiple forks (i.e. each process has several tests that
are in the list but not added to the runner). Thus we need to mark those we
expect check to free as used.
Then on cleanup we traverse the test list, add all the unused one to a
test runner and free that test runner (without actually running it). This
cleans up both the filtered tests in each subprocess and the whole test list
in the parent process which doesn't run a test itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Call it a libinput-test-suite-runner, in subsequent patches we'll handle doing
parallel tests ourselves instead of relying on automake features.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.
https://bugs.freedesktop.org/show_bug.cgi?id=96663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Move mode control to libinput. This reduces some flexibility on what we can do
with modes but makes it a lot easier for anyone to implement modes correctly
and have the LEDs apply appropriately, etc. Let's go with the option to make
the 95% use-case easy. Note: whether the mode is actually used is up to the
caller, e.g. under Windows and OS X the mode only applies to the
rings/strips, not the buttons.
A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned
to a mode group. That group has a numeric mode index and is hooked to the
LEDs. libinput will switch the LEDs accordingly.
The mode group is a separate object. This allows for better APIs when it comes
to:
* checking whether a button/ring/strip is part of a mode group
* checking whether a button will trigger a mode transition
and in the future potentially:
* checking which mode transition will happen
* setting which button should change the mode transition
* changing what type of mode transition should happen.
* moving a button from one mode group to the other
This patch adds the basic scaffolding, without any real implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Proofread-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Separate patch to avoid crowding out the actual content in the patch with the
documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
No effect so far because the dist-hook prevents us from making a tarball
without the sources anyway. But for correctness split the two up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Quite a few bugs are caused by touchpad ranges being out of whack. If we get
input events significantly outside the expected range (5% width/height as
error margin) print a warning to the log.
And add a new doc page to explain what is happening and how to fix it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a touch moves by more than 20mm within a single frame, reset the motion
history, effectively discarding the movement. This is a relatively common bug
and almost always needs a kernel fix, so add an explanatory page to the docs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
This interface handles the buttons on the physical tablet itself, including
the touch ring and the strip.
A notable difference to other libinput interfaces here is that we do not use
linux/input.h event codes for buttons. Instead, the buttons are merely
numbered sequentially, starting at button 1. This means:
* the API is different, instead of get_button() we have get_button_number() to
drive the point home
* there is no seat button count. pads are inherently different devices and
compositors should treat them as such. The seat button count makes sense
when you want to know how many devices have BTN_LEFT down, but it makes no
sense for buttons where all the semantics are handled by the compositor
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Middle button interaction is most commonly to paste and it is a single-event
interaction (button press). We provided middle button in software button mode
by emulating it with a two-finger press with L+R down at the same time. This
is also what many touchpads are spectacularly bad at, it is very common to
detect the physical button down event before the second finger registers,
resulting in left or right clicks where a middle button should be triggered.
Unless the fingers are resting on the touchpad for at least one scanout, the
success rate for middle button emulation is only at 70% or so.
This patch adds a 25%-width middle button area between the left and the right
software button, everything else stays the same. To avoid immediate breakage,
the middle button emulation remains but may be removed in the future.
The doc is updated to only refer to the middle button area now.
https://bugs.freedesktop.org/show_bug.cgi?id=94755
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
