This makes the generic evdev code (i.e. the functions not relying on
udev) independent of launcher-util too. The aim is to allow re-using the
generic evdev code in the Android backend, where neither udev nor
launcher-util are available.
evdev_input_device_create() signature is changed:
- add the opened device file descriptor
- remove wl_display as unused
Also add a bit of failure logging.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev_input_device_destroy() will completement the API of
evdev_input_device_create(), both being independent from udev.
Since the udev-specific device_removed() would only call
evdev_input_device_destroy() and do nothing else, device_remove() calls
are simply replaced with evdev_input_device_destroy().
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
For a true multi-touch input device, the code ended up using
uninitialised fields of evdev_input_device::abs.
Fix it by querying the corresponding MT ranges.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Most touchscreen drivers provide ABS_X and BTN_TOUCH for legacy
single-touch emulation modes, but this isn't mandatory. Make sure we
don't ignore touchscreens with provide multitouch events with the new
API only.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If update_state is true, then notify_key will continue to call
xkb_key_update_state to update the local state mask, as before this
commit. Otherwise, it will rely on the compositor to manually update
the state itself, for nested compositors.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The O_RDWR change got lost in a rebase, and as Peter suggested as well,
make sure to set EVDEV_KEYBOARD if the device has EV_LED.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This allows backends to generate their own keymaps and pass them in for
use rather than always forcing a single global keymap, which is
particularly useful for nested compositors.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of using a uint32_t for state everywhere (except on the wire,
where that's still the call signature), use the new
wl_keyboard_key_state enum, and explicit comparisons.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of using a uint32_t for state everywhere (except on the wire,
where that's still the call signature), use the new
wl_pointer_button_state enum, and explicit comparisons.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Does what it says on the box: lists whether or not the device supports
key, absolute, relative or touch classes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Touchpad related code has been rewritten and moved to its own file
accessed by evdev via the dispatch interface.
The various functionality implemented are anti-jitter (don't jumping
around), smoother motions, touch detection, pointer acceleration and
some more.
Pointer acceleration is implemented as one generic part, and one touch
specific part (a profile).
Some ideas and magic numbers comes from xserver and
xf86-input-synaptics.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
By setting an 'evdev_dispatch' struct in 'evdev_input_device' during
device configuration the 'process' function in the associated interface
will be called with received input events. If none is set, a fallback
handler will be set instead that handle generic input functionality.
Signed-off-by: Jonas Ådahl <jadahl@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>
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.
weston-launch starts weston and provides mechanism
for weston to set/drop drm master, open a tty,
and read input devices without being root.
Execution is allowed for local-active sessions
or users in the group weston-launch.
Just like device_added, now the routines to close the compositor and vt switch
leave are using the same code to remove a device.
This patch also closes properly a mtdev device, bug spotted by Christopher
Michael.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
When the compositor is in a repaint cycle, input is processed only once
per frame. However, a call to evdev_input_device_data() would handle at
most 8 events at time. When there was more than 8 events pending for a
given frame, input lag would occur. This was most visible with multi
touch input.
This patch changes the evdev_input_device_data() so that it will handle
all the events available in the fd. In order to do that, the fd is put
in non-blocking mode, so that it is possible to loop on read and stop
on EAGAIN instead of blocking.
mtdev library translates all multitouch based devices to the slotted evdev
protocol. It provides an uniform interface for Weston, which eases mt
implementation when dealing with a big variety of devices.
Weston on drm now directly depends on such library.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts commit fc6ccb868f.
We still need root permissions for drmDrop/SetMaster. Without
integration with ConsoleKit or systemd we also don't have access
to /dev/dri/cardX in the case where we open a new VT.
==30224== Conditional jump or move depends on uninitialised value(s)
==30224== at 0x40EE3A0: evdev_flush_motion (evdev.c:284)
==30224== by 0x40EE6DC: evdev_input_device_data (evdev.c:352)
==30224== by 0x4034710: wl_event_source_fd_dispatch (event-loop.c:76)
==30224== by 0x4035171: wl_event_loop_dispatch (event-loop.c:462)
==30224== by 0x4032F76: wl_display_run (wayland-server.c:785)
==30224== by 0x8050972: main (compositor.c:2183)
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Usually there should be at least one input device, when Weston starts
up, or is reactivated by a VT switch. Add a nice warning, in case there
are no input devices.
This is to give a clue to users who happen to try Weston on DRM, and
do not get any response.
Add also a message to another failure case, that may lead to missing
input devices.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
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.
We need to store all touchpoint positions so that if we just get an
ABS_MT_POSITION_X or Y event, we can pull the other coordinate from the
cache. And we need this across invocations of evdev_input_device_data(),
so the accumulator approach doesn't work.
Instead, we go back to the approach of storing all this state in the
evdev device struct and we might as well just move the rel and abs state
there too.
This adds ABS_MT_* support for direct touch devices and notifies
the compositor. The compositor has a stub for now.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Pekka Paalanen
Kristian Høgsberg
Daniel Stone
Martin Minarik
Jonas Ådahl
Benjamin Franzke
Tiago Vignatti
Scott Moreau
Ander Conselvan de Oliveira
Olivier Le Thanh Duong