Having a motion event that's sent right after the original proximity event just
to give the values of each axis is somewhat redundant. Since we already include
the values of each axis with each type of event, we may as well use the
proximity event to give the client the starting values for each axis on the
tablet.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There isn't much purpose in having proximity in and out as different events,
combining them into one single event is more consistent with the rest of the
API, and means less code for clients to have to work with.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Added: udev-tag detection for the tablet.
libwacom assigns ID_INPUT_TABLET to all known devices but also
ID_INPUT_TOUCHPAD to all known devices with a touch interface. That's a bug
and should be fixed there but we can work around it by checking both and
making sure only one is set.
Conflicts:
src/evdev.c
test/misc.c
Devices like Wacom tablets have multiple event nodes (touch, pad and stylus).
This requires some logical grouping, e.g. setting an Intuos 5 tablet
left-handed effectively turns it upside down. That then applies to both the
stylus and the touch device.
Merging the devices into one struct libinput_device is not feasable, it
complicates the API for little benefit. A caller would still need access to
all subdevices to get udev handles, etc. Some configuration options apply to
the whole device (left-handed) but some (may) only apply to a single subdevice
(calibration, natural scrolling).
Addressing this would make the libinput API unwieldly and hard to use.
Instead, add a device group concept. Each device is a member of a device
group - a singleton for most devices. Wacom tablets will have a single group
across multiple devices, allowing the caller to associate the devices together
if needed.
The API is intentionally very simple and requires the caller to keep track of
groups and which/how many devices are in it. The caller has more powerful
libraries available to do that than we have.
This patch does not address the actual merging of devices into the same
device group, it simply creates a new group for each new device.
[rebased on top of 0.10]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Two methods are provided:
* button area - used on most clickpads, a click with a touch within a given
area generates left/middle/right clicks
* clickfinger - used on apple touchpads, a click with 1/2/3 fingers on the
touchpad generates a left, right, middle click
Both methods already exist in the touchpad code, this is just the
configuration interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices require more than just flipping around the buttons, such as
tablets.
When it comes to devices like tablets, because the position of the palm rest is
on the right, the entire tablet has to be flipped around in order to be usable
by lefties. As such, this requires that we reverse the coordinates of the
tablets in addition to flipping the buttons on the tablet. As such, renaming
these functions so that they aren't specific to devices where only the buttons
are flipped seems appropriate.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is merged on top of the wheel normalization patches. Those introduced an
axis source and an extra "discrete" value to the various internal and external
APIs. This branch changed from a single value to passing dx/dy into all scroll
events.
The conflicts are to change everything to take x, y, x_discrete, y_discrete as
values (and the source axis mask of course).
Conflicts:
src/evdev-mt-touchpad-edge-scroll.c
src/evdev.c
src/libinput-private.h
src/libinput.c
The recent normalization of wheel events means we get the angle in degrees but
we don't know how this corresponds to clicks. The M325 has a 20 degree click
angle, most other mice have 15 degrees. So an angle of 60 can be 3 or 4 click
events.
Most clients care more about the click count than the angle on a mouse wheel.
Provide that value when needed.
Adding a discrete value to the axis event leaves the possibility of defining
discrete units for finger/continuous scroll sources in the future. Right now,
these will always reuturn 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Sending separate axis events instead of one unified events is limiting,
especially when simultaneously scrolling in both directions and the caller
tries to implement kinetic scrolling.
Take a page from the tablet-support branch and instead implement the axis
event as a generic event that can contain multiple axes simultaneously.
Right now we only have two (scroll) axes and we could easily just check both
for non-zero values. If we want to allow further axes in the future, we need
a check whether an axis is set in an event, that's what
libinput_event_pointer_has_axis to scroll events() is for.
We also need the mask to notify of a scroll stop event, which could otherwise
be confused as a vertical-only or horizontal-only event.
This is an API and ABI break.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Similar to the mouse resolution, let's make the scroll distance a sensible
predictable value. Most mice use a 15 degree angle per scroll click, so let's
change to that. This will alter behaviour in clients that expect 10.
We return doubles for the axis value, so that leaves the option of
really fine-grained step sizes in the future.
We currently assume all mice have 15 degree angles. Like the DPI settings, it
will require a udev property to be set. Patch for that to follow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Discreet means to not draw attention.
Discrete means non-continuous.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
For a caller to implement/provide kinetic scrolling ("inertial scrolling",
"fling scrolling"), it needs to know how the scrolling motion was implemented,
and what to expect in the future. Add this information to the pointer axis
event.
The three scroll sources we have are:
* wheels: scrolling is in discreet steps, you don't know when it ends, the
wheel will just stop sending events
* fingers: scrolling is continuous coordinate space, we know when it stops and
we can tell the caller
* continuous: scrolling is in continuous coordinate space but we may or may not
know when it stops. if scroll lock is used, the device may never technically
get out of scroll mode even if it doesn't send events at any given moment
Use case: trackpoint/trackball scroll emulation on button press
The stop event is now codified in the API documentation, so callers can use
that for kinetic scrolling. libinput does not implement kinetic scrolling
itself.
Not covered by this patch:
* The wheel event is currently defined as "typical mouse wheel step", this is
different to Qt where the step value is 1/8 of a degree. Some better
definition here may help.
* It is unclear how an absolute device would map into relative motion if the
device itself is not controlling absolute motion.
* For diagonal scrolling, the vertical/horizontal terminator events would come
in separately. The caller would have to deal with that somehow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Original patch, before the rebase onto today's master:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Previously, the pointer could only be passed into the context on creation
time and was immutable after that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Manual changes:
* add tablet APIs to libinput.sym
* add the tablet-specific events to litest_event_type_str
* add NULL for device_remove in the tablet interface
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike all other structs, events aren't refcounted and will get destroyed
immediately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Makes them show up on the respective page and in the data structures list
doxygen generates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
doxygen supports markdown so we can expand the README with general interesting
information in markdown format and have it be the front page of the
documentation at the same time.
This requires renaming README to README.txt, but that's a relatively small
price to pay.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Avoid mismatches in what the caller expects vs what libinput actually
provides when building against newer/older versions of libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allow retrieval of the libinput context from the seat and the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The libinput device abstracts a number of things but sometimes the underlying
device is important. The udev device provides the necessary handle to access
that underlying device and various sysfs properties that may be necessary.
A function returning the device node would've done the same thing but is more
prone to race conditions than the udev_device.
https://bugs.freedesktop.org/show_bug.cgi?id=85573
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The seat of a device is currently immutable, but a device may (in a
multi-pointer case) move between different logical seats. Moving it between
seats is akin to removing it and re-plugging it, so let's do exactly that.
The physical seat name stays immutable.
Pro:
- device handling after changing a seat remains identical as handling any
other device.
Con:
- tracking a device across seat changes is difficult
- this is not an atomic operation, if re-adding the device fails it stays
removed from the original seat and is now dead
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This effectively disables the button scrolling, but since 0 is the default
button for most devices, we should allow setting the default button.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add a configuration option to allow selecting between 2-finger / edge / none
scrolling (for touchpads).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In some cases the compositor will want to know which buttons a device has.
E.g. for scrolling we want the compositor to be able to set a button to change
a relative device (e.g. a trackball) into scroll mode, so that it sends
scroll-axis events instead of pointer motion events.
In order for the compositor to be able to present a sane UI for this, it needs
to know which buttons a device has.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix libinput_device_config_send_events_get_default_mode docs referring to
itself, instead make it refer to libinput_device_config_send_events_get_mode.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous code used delta/event as scroll trigger which roughly translates
to speed, but depends on the sampling rate of the device.
For slow two-finger motion, a user may move the height of the touchpad without
ever triggering scrolling. Change the _initial_ trigger to a cumulative
trigger, i.e. once the user moved past the threshold distance, scrolling
starts regardless of the speed.
Once scrolling is engaged, the original trigger of threshold/event is
required to engange the second scroll direction.
Note that except for really slow movements, it's very easy to engage both
scroll directions on a touchpad. This is intentional, libinput does not have
enough semantic knowledge to know if horizontal scrolling is needed. So we
provide some direction locking but not much, it's up to the
client/toolkit/widget to decide if both scroll directions should be handled.
Add a comment to clarify that in the public doc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
