Mouse wheel events come as EV_REL/REL_WHEEL, and we can convert
them to clutter events on the assumption that scrolling with
the wheel is always vertical.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
xkb_state_update_key() needs to be called only on state transitions,
otherwise the state tracking gets confused and locks certain modifiers
forever.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
A wayland compositor needs to have more keyboard state than
ClutterModifierState exposes, so it makes sense for it to use
xkb_state directly. Also, it makes sense for it to provide
it's own keymap, to ensure a consistent view between the compositor
and the wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
All evdev devices are slave devices, which means that xkb state
and pointer position must be shared by emulating a core keyboard
and a core pointer. Also, we must make sure to add all modifier
state (keyboard and button) to our events.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
Hardware keycodes in Clutter events are x11 keycodes, which are
the same as evdev + 8, but we need to reverse the translation when
explicitly asked for an evdev keycode.
https://bugzilla.gnome.org/show_bug.cgi?id=705710
In some cases, applications (or actually, wayland compositors)
don't have the required permissions to access evdev directly, but
can do so with an external helper like weston-launch.
Allow them to do so with a custom callback that replaces the regular
open() path.
https://bugzilla.gnome.org/show_bug.cgi?id=704269
In commit 8f4e39b6d7 the Wayland code was updated to use the new
xkbcommon API. This involved changing the common XKB code shared with
the evdev input backend. However the evdev input backend was not
modified so it wouldn't compile. This patch just makes a minor change
to update it.
https://bugzilla.gnome.org/show_bug.cgi?id=693348
For Wayland, this is mostly the input protocol having changed, although
there's also the SHM pool API, the cursor API, as well as fullscreen and
ping.
Also port to the new (months-old) xkbcommon API, as used by Weston 0.95.
This involves having xkbcommon manage the state for us, where
appropriate. Fans of multi-layout keyboards (or just caps lock) will no
doubt appreciate these changes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The ordering of the evdev button numbers is the opposite of the
order in Clutter (the middle button is 3 instead of 2) so we need to
manually map the button numbers when creating a ClutterButtonEvent.
https://bugzilla.gnome.org/show_bug.cgi?id=680255
Acquiring the Clutter lock to mark critical sections is not portable,
and not recommended to implement threaded applications with Clutter.
The recommended pattern is to use worker threads, and schedule UI
updates inside idle or timeout handlers within the main loop. We should
enforce this pattern by deprecating the threads_enter()/leave()
functions. For compatibility concerns, we need internal API to acquire
the main lock during frame processing dispatch.
https://bugzilla.gnome.org/show_bug.cgi?id=679450
The commit 90e5088 added some extra compiler warning options that were
triggering warnings when enabling the wayland build due to missing
header includes. This adds those header includes in.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Clutter applications using evdev are typically fullscreen applications
associated with a single virtual termainal. When switching away from
the applications associated tty then Clutter should stop managing all
evdev devices and re-probe for devices when the application regains
focus by switching back to the tty. To facilitate this, this patch
adds clutter_evdev_release_devices() and clutter_evdev_reclaim_devices()
functions.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This adds a virtual function to ClutterInputDevice to translate a
keycode from the hardware_keycode member of ClutterKeyEvent to an
evdev keycode. The function can fail so that input backends that don't
have a sensible way to translate to evdev keycodes can return FALSE.
There are implementations for evdev, wayland and X. The X
implementation assumes that the X server is using an evdev driver in
which case the hardware keycodes are the evdev codes plus 8.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Because evdev isn't associated with the display system, it doesn't
have any easy way to associate an input device with a stage.
Previously Clutter would never set a stage for an input device and
leave it up to the application to set it. To make it easier for
applications which just have a single fullscreen stage (which is
probably the most common use case for evdev) the device manager now
associates all input devices with the first stage that is created
unless something has already set a stage.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This makes the option_xkb_* symbols declared for the evdev device manager
and the wayland device manager private so we don't get symbol collisions
if both of these backends are enabled.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This updates the evdev input backend code to compile and also updates
the code to not refer to the default stage and instead check for a
stage to be associated with the input device. If no stage is currently
associated with a device generating events then the events are dropped
on the floor.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
The evdev system is a bit different from other input systems in
Clutter because it's completly decorrelated from anything graphic.
In the case of embedded devices with no proper windowing system, you
might want to not implicitly create a default stage when you're
receiving the first input event.
This patch changes this behavior by not forwarding any event if you
don't have a default stage.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=651718
Create the device manager during the event initialization, where it
makes sense.
This allows us to get rid of the per-backend get_device_manager()
virtual function, and just store the DeviceManager pointer into the
ClutterBackend structure.
With glib 2.28, we'll be able to have one GSource per device manager
with child sources for earch device. Make a note to update the code
in a few months.
An array is used to translate the button to its mask. Clutter defines
the masks for button 1 to 5 but we report BTN_LEFT..BTN_TASK ie
0x110..0x117. We need to pad the array for the translation not to access
random data for buttons between 0x115 and 0x117.
We know support EV_REL events comming from evdev devices. This addition
is pretty straigthforward, it adds a x,y per GSource listening to a
evdev device, updates from EL_REL (relative) events and craft new
ClutterMotionEvents. As for buttons, BTN_LEFT..BTN_TASK are translated
to ClutterButtonEvents with 1..8 as button number.
Even with udev, the read fails before udev has a chance to signal the
change. Hence (and to handle errors gracefully anyway), let's remove the
device from the device manager in case of a read() error.
The device manager now fully owns the GSources corresponding to the
devices it manages. This will allow not only to remove the source when
udev signals a device removal but also handle read() errors gracefully
by removing the faulty device from the manager.
Just connect to the GUdevClient "uevent" signal and deals with
"add"/"remove" commands. This drives the installation/removal of
GSource to listen to the device.
Let's use the sysfs path of the device to make sure we only load evdev
device, not legacy mousedev ones for instance. We rely on the sysfs
API/ABI guarantees and look for devices finishing by /input%d/event%d.
This backend is a event backend that can be enabled for EGL (for now).
It uses udev (gudev) to query input devices on a linux system, listens to
keyboard events from input devices and xkbcommon to translate raw key
codes into key keysyms.
This commit only supports key events, more to follow.
Looking at what the X11 backend does: the unicode value is being
translated to the unicode codepoint of the symbol if possible. Let's do
the same then.
Before that, key events for say KEY_Right (0xff53) had the unicode_value
set to the keysym, which meant "This key event is actually printable and
is Unicode codepoint is 0xff53", which lead to interesting results.
The wayland client code has support for translating raw linux input
device key codes coming from the wayland compositor into key symbols
thanks to libxkbcommon.
A backend directly listening to linux input devices (called evdev, just
like the Xorg one) could use exactly the same code for the translation,
so abstract it a bit in a separate file.
