With multiple touch screens on one seat, the touch points IDs from the
different evdev devices may overlap. We have to remap the IDs we forward
to core weston so that the touch points all have unique IDs within the seat.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=73003
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.
The output is renamed "output" from "x11_output" and the input coordinates
are changed to wl_fixed_t from int. This way it is useable in
compositor-wayland as well as compositor-x11 and evdev.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
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
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
The issue was that touch::down event from the compositor to client apps
would send the previous motion events coordinates and this obviously made
the client do the wrong thing. This happened because we were not waiting
for a SYN event to come from evdev before sending down, motion or up events.
https://bugs.freedesktop.org/show_bug.cgi?id=51909
