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
config.h includes were missing in a few files, including input.c, the
lack of which caused the X11 backend to segfault instantly due to not
having an xkbcommon context.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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
As said by krh: "Maybe we should also just call it an evdev_device
instead, shorter [and] not really ambiguous."
[krh: if my typo filled irc is going in a commit message, I'm at least going
to insert the missing words.]
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev_led_update() does not really need the whole list of device at
once, it can be called one device at a time.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Move all udev-related and now drm backend specific code into
compositor-drm.c.
This makes evdev.c free of udev and launcher-util, and allows it to be
used on Android.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
wl_input_device has been both renamed and split. wl_seat is now a
virtual object representing a group of logically related input devices
with related focus.
It now only generates one event: to let clients know that it has new
capabilities. It takes requests which hand back objects for the
wl_pointer, wl_keyboard and wl_touch interfaces it exposes which all
provide the old input interface, just under different names.
This commit tracks these changes in weston and the clients, as well as
similar renames (e.g. weston_input_device -> weston_seat). Some other
changes were necessary, e.g. renaming the name for the visible mouse
sprite from 'pointer' to 'cursor' so as to not conflict.
For simplicity, every seat is always exposed with all three interfaces,
although this will change as time goes on.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Compositor core does not do anything with udev, so the header is not
needed there. Move the #include into evdev.h, from where it gets used by
compositor-drm.c, too.
Also fix the fallout:
tty.c: In function 'tty_create':
tty.c:143:2: warning: implicit declaration of function 'fstat'
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
We dont want to receive hotplug events while being inactive.
When getting back active we enumerate all devices and would end up
with two sources for one device that may be hotplugged in the mean time.
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
Besides the new header file, there's also a change in the main evdev creation
procedure for a more suggestive name (evdev_input_add_devices ->
evdev_input_create). There's no real functional changes in this commit.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Jonas Ådahl
Neil Roberts
Daniel Stone
Satyeshwar Singh
Kristian Høgsberg
Rob Bradford
Pekka Paalanen
Benjamin Franzke
Tiago Vignatti