Higher values than 1 or -1 are legitimate on some devices, though not all mice
send wheel events other than 1/-1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These events are not a state of a single touchpoints but rather a notification
that all touchpoints finished processing. As such, they should have their own
type.
And make sure we actually send them when needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't really support devices changing capabilities at runtime. The kernel
has no ability to tell us when this happens on an already-opened device and
the few devices that can literally change physical capabilities (e.g. the
wiimote) open up extra kernel devices instead of modifying the existing one.
Thus, we don't need to notify about devices changing capabilities.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We now no longer add joysticks at all. They show up as absolute motion
devices without has_button, so we don't add them as a pointer. We may add
a keyboard for the keyboard-style keys, but that's fine. With the previous
commit, we no longer generate spurious absolute pointer motion for the abs
axes.
https://bugs.freedesktop.org/show_bug.cgi?id=71687
Some joysticks have certain buttons that acts keyboard keys. As such,
we'll reconize them as keyboards but not pointers. In that case, don't
send pointer motion events when we get absolute joystick events.
This rule triggers for devices with an ABS_X/Y evaluators and no
keyboard or multitouch events. There is no way we would ever add such
a device as a pointer, keyboard or touch device anyway. A pointer
device requires has_button (in which case the !has_key condtion would
fail); a keyboard device would also mean !has_key is false and a touch
screen device implies that !device->is_mt is false.
We split the device probing and idenfication somewhat arbitrarily between
these two functions. This commit combines them into one. Return of -1
indicates error, 0 success, but succesful probing can return a device
with device->caps == 0, which means we don't handle the device.
Function arguments with fixed length are still just pointers, so
sizeof(calibration) here is sizeof(float*), not sizeof(float) * 6.
evdev.c: In function 'evdev_device_calibrate':
evdev.c:693:54: warning: argument to 'sizeof' in 'memcpy' call is the same
pointer type 'float *' as the destination; expected 'float' or an explicit
length [-Wsizeof-pointer-memaccess]
memcpy(device->abs.calibration, calibration, sizeof calibration);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch ports udev-seat from weston to libinput, including adapting
libinput internals and API to provide seat and device discovery.
The public API is extended with device discovery, object reference, a
seat object. As libinput takes care of creating and destroying its
objects user data getter/setter is added in order to make it possible
for the client to directly associate an object application side with an
object library side.
Device discovery API is made up of the 'seat added', 'seat removed',
'device added' and 'device removed' events. The seat added/removed
events contains a pointer to a libinput_seat struct, while the device
added/removed events contains a pointer to a libinput_device event.
The objects are reference counted with libinput holding one reference by
default. The application can increase the reference count with
libinput_seat_ref() and libinput_device_ref() and decrease the reference
count with libinput_seat_unref() and libinput_device_unref().
The basic event struct is changed to have a 'target' union parameter
that can be either a libinput, libinput_seat or libinput_device struct
pointer.
There is one known problem with the current API that is the potentially
racy initialization.
The problem is when a device is both discovered and lost during initial
dispatchig, causing libinput to first queue a 'added' message, creating
the device with default reference count 1, then before going back to the
application queuing a 'removed' message, while at same time decreasing
reference count of the device to 0, causing it o be destroyed. The queue
will at this state contain two messages with pointers to free:ed memory.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This commit also introduces a new requirement to
libinput_device_destroy() - libinput_device_terminate() must be called
before libinput_device_destroy() in order to allow the user to dispatch
the events related to a terminating input devices while the device is
still valid.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Instead of having the user manage added and removed fd's as well as the
fd used for creating evdev devices, introduce a libinput object that
itself has an epoll fd.
The user no longer manages multiple fd's per libinput instance, but
instead handles one fd, dispatches libinput when data is available, then
reading events using libinput_get_event().
libinput_event's are now per libinstance, but divided into categories.
So far the only category is device events. Device events are categorized
by the presence of a non-NULL device pointer in the event.
The current API usage should look like:
struct libinput libinput = ...;
struct libinput_event *event;
if (libinput_dispatch(libinput) != 0)
return -1;
while ((event = libinput_get_event(libinput))) {
if (event->device)
process_device_event(event);
free(event);
}
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This commit introduces build script configuration for building a shared
library 'libinput.so' containing the evdev input device functionality
from weston.
evdev.c, evdev.h and evdev-touchpad.c are ported to not use the data
structures and API in weston and libwayland-server in order to minimize
dependencies.
The API of filter.c and filter.h are renamed to not include the
'weston_' prefix.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
If read() fails without EAGAIN/EINTR, the device is very likely dead.
However, we must not remove the device as it might be muted/revoked. So we
simply remove the event-source to avoid polling the device and simply wait
for the udev-remove signal now.
Note that we cannot call evdev_device_destroy() as the caller created the
FD and might need custom code to close it (like weston_launcher_close()).
We used to test for abs | rel | button, which inits a pointer device for
a device with just rel or abs capabilities. We now make sure we have either
rel or abs as well as button.
Previously only the touch up key event was used for single-touch
devices and the touch down event was generated on the first motion
event. This was breaking if the touch up and down events were sent
without a motion in-between because the evdev driver wouldn't generate
a touch down event and Weston would lose track of the number of touch
points that are down. This patch changes it to track the up and down
key events as pending events similar to how it does for multi-touch
devices.
https://bugs.freedesktop.org/show_bug.cgi?id=69759
Instead of having a mask of pending events there is now an enum with a
single value to represent the one pending event. The event gets
flushed explicitly as part of the handling code for each event type
rather than in the outer event reading loop. The pending event is used
so that we can combine multiple motion events into one and to make
sure that we have recieved the latest position before sending a touch
up or down event. This should fix the following problems with the old
approach:
• If you release a finger and press it down again quickly you could
get the up and down events in the same batch. However the pending
events were always processed in the order down then up so it would
end up notifying two down events and then an up. The pending event
is now always flushed when there is a new up or down event so they
will always be in the right order.
• When it got a slot event it would immediately change the slot number
and then set the pending event. Then when it flushed the events it
would use the new slot number to flush the old pending event so the
events could have the wrong finger. The pending event is now
immediately flushed when a slot event is received so it will have
the right finger.
• If you get more than 32 events in one read then it was resetting the
pending events before processing the next batch in
evdev_process_events. If four fingers were pressed down at once then
it ended up with more than 32 events and the sync message would be
in the second batch. The pending flag for the last finger was
getting cleared so it never got emitted. In this patch the pending
event is no longer reset after reading nor is it explicitly flushed.
Instead it is flushed when we receive a EV_SYN event or a different
pending event needs to replace it.
The touchpad handling code was trying to use the pending event
mechanism to notify the relative motion events. I'm not sure why it
was doing this because it looks the event would effectively get
emitted as soon as the touchpad_process function is finished anyway
and it wasn't accumulating the values. Instead I've just changed it to
emit the event directly.
https://bugs.freedesktop.org/show_bug.cgi?id=67563
If two fingers are released almost simultaneously then evdev can send
the touch up events in one bunch without sending a sync event
in-between. However, the evdev_device struct only keeps track of one
pending touch up event so in this case the second touch up event would
override the first and it would be lost. This patch changes it to also
flush the events whenever the slot changes so that it will flush the
previous touch up event before trying to queue the next one.
https://bugs.freedesktop.org/show_bug.cgi?id=67563
We don't always get both an X and an Y event in a SYN report, so we end
up transforming the coordinate we don't get twice. For example, if we
only receive an ABS_X event, we transform the already transformed
device->abs.y again in transform_absolute() when applying the calibration.
We don't handle them in any way now and having your steering wheel move
the cursor isn't useful. Applications can still open evdev devices and
access them directly like they already do.
Other clients of an evdev device need to have the events they receive
be separated, in moment in time, from other events by an EV_SYN/
SYN_REPORT. This is the responsibility of the client who writes events
into the stream.
device->mt.slot is uninitialized when we're not receiving the
evdev slot events. Always use ID 0 as we do when we generate the
touch down and motion events.
For touchpads, device->dispatch is set up when exiting
evdev_handle_device() and a potential source for a memleak.
This can't actually happen at the moment, as evdev_handle_device() won't
fail for touchpads after setting up the dispatch but prevent this from
happening in the future.
If touches are already present on the device, absinfo has the currently
active touch slot. There's a race condition where the slot may change before
we enable the fd and we thus miss out on the ABS_MT_SLOT event. It's still
slightly more correct than assuming whatever comes next is slot 0.
For Protocol B devices, mtdev merely routes the events and is not needed.
For Protocol A devices, mtdev is needed, so fail for those devices now if we
mtdev fails.
mtdev as currently used in weston is a noop. mtdev's purpose is to convert
Protocol A devices (without ABS_MT_SLOT) to Protocol B devices (slots).
For Protocol B devices mtdev merely routes the events, so checking for
slots and then using mtdev based on that adds no functionality.
Check for ABS_MT_POSITION_X/Y instead and use that to categorise a device
as MT device. mtdev will provide us with a slotted protocol for all devices.
https://bugs.freedesktop.org/show_bug.cgi?id=54428
