Rotary encoder Knobe (Joystick) with Wayland-EGL platform not working
I am facing same issue with rotary encoder knobe with imx6 platform. We are using wayland-egl and weston compositor and we are not getting events in GUI.
We have browser application which receives events. If we change QT QPA PLATFORM to linuxfb everything works fine but when we set wayland-egl it is not working
It looks like events are not mapped correctly as debug log shows:
LINUXFB:
2021-10-21T08:50:55.749591+00:00 corecard stderr: qt.qpa.input: Using xkbcommon for key mapping
WAYLAND:
2021-10-21T12:02:26.850376+00:00 corecard stderr: qt.xkb.compose: using xkb compose input context
2021-10-21T12:02:26.850452+00:00 corecard stderr: qt.qpa.wayland: using input method: QComposeInputContextI also read lot of things about SEAT and other things to set in weston.ini but really don't know what to set.
Your quick response is highly appreciated !!
-- Thanks, Hitesh
Activity
According to Qt docs, eglfs and linuxfb have all the input handling code compiled-in. Using wayland-egl will instead use libinput, which most likely won't detect your rotary knob.
Easier to verify is to look at the compositor log. Use
--logas an argument towestonand paste it here as well.Thanks @mvlad for quick response !!
Attached due to not displayed well.
Edited by Hitesh Viradiya-
The log clearly says:
warning: no input devices on entering Weston.without any inputs being detected whatsoever.- Could you do a
ls -al /dev/input/*and paste it here as well please? - Do you have
udevup an running? Thought I don't how you'd run anything without it :/. - if you happen to have libinput-tools installed you can also try doing
libinput list-devicesto see if libinput sees/supports your device (which I suspect it doesn't).
/cc @whot he's the authority on the matter
Edited by Marius Vlad - Could you do a
Dear @mvlad
See below requested details: 1)
# ls -al /dev/input/* crw-r----- 1 root root 13, 64 Jan 1 1970 /dev/input/event0 crw-rw---- 1 root root 13, 63 Jan 1 1970 /dev/input/mice lrwxrwxrwx 1 root root 17 Jan 1 1970 /dev/input/rotaryencoder -> /dev/input/event0-
We don't have udev instead we have mdev and we are using buildroot with NXP's imx6/imx8 platforms.
-
We have libinput-tools installed and "libinput list-devices" shows nothing but "libinput record" shows available rotary knob. See below:
# libinput record Available devices: /dev/input/event0: liveu-rotary-encoder Select the device event number:And if I enter 0 in "Select the device event number:", it shows following
# libinput record Available devices: /dev/input/event0: liveu-rotary-encoder Select the device event number: 0 Recording to 'stdout'. version: 1 ndevices: 1 libinput: version: "1.15.6" git: "2020.08-rc1-221-g6f71b93" system: os: "buildroot:2020.08-rc1" kernel: "4.9.11-imx6-r127" dmi: "unknown" devices: - node: /dev/input/event0 evdev: # Name: liveu-rotary-encoder # ID: bus 0x19 vendor 00 product 00 version 00 # Supported Events: # Event type 0 (EV_SYN) # Event type 1 (EV_KEY) # Event code 25 (KEY_P) # Event code 28 (KEY_ENTER) # Event code 103 (KEY_UP) # Event code 105 (KEY_LEFT) # Event code 108 (KEY_DOWN) # Event type 20 (EV_REP) # Event code 0 (REP_DELAY) # Event code 1 (REP_PERIOD) # Properties: name: "liveu-rotary-encoder" id: [25, 0, 0, 0] codes: 0: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] # EV_SYN 1: [25, 28, 103, 105, 108] # EV_KEY 20: [0, 1] # EV_REP properties: [] udev: properties: quirks: events:And based on all buttons (HOME, BACK and ROTARY PUSH) and ROTATE LEFT/RIGHT it displays the correct events. See generated events for rotate left, then right and then push the rotary:
- evdev: - [ 0, 0, 20, 0, 400] # EV_REP / REP_DELAY 400 - evdev: - [ 0, 0, 20, 1, 80] # EV_REP / REP_PERIOD 80 - [ 0, 0, 1, 103, 1] # EV_KEY / KEY_UP 1 - [ 0, 0, 1, 103, 0] # EV_KEY / KEY_UP 0 - [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms - evdev: - [ 1, 742638, 1, 103, 1] # EV_KEY / KEY_UP 1 - [ 1, 742638, 1, 103, 0] # EV_KEY / KEY_UP 0 - [ 1, 742638, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1742ms - evdev: - [ 2, 132266, 1, 103, 1] # EV_KEY / KEY_UP 1 - [ 2, 132266, 1, 103, 0] # EV_KEY / KEY_UP 0 - [ 2, 132266, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +390ms - evdev: - [ 5, 361804, 1, 108, 1] # EV_KEY / KEY_DOWN 1 - [ 5, 361804, 1, 108, 0] # EV_KEY / KEY_DOWN 0 - [ 5, 361804, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +3229ms - evdev: - [ 5, 579399, 1, 108, 1] # EV_KEY / KEY_DOWN 1 - [ 5, 579399, 1, 108, 0] # EV_KEY / KEY_DOWN 0 - [ 5, 579399, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +218ms - evdev: - [ 5, 680544, 1, 108, 1] # EV_KEY / KEY_DOWN 1 - [ 5, 680544, 1, 108, 0] # EV_KEY / KEY_DOWN 0 - [ 5, 680544, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +101ms - evdev: - [ 5, 821460, 1, 108, 1] # EV_KEY / KEY_DOWN 1 - [ 5, 821460, 1, 108, 0] # EV_KEY / KEY_DOWN 0 - [ 5, 821460, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +141ms - evdev: - [ 5, 976067, 1, 108, 1] # EV_KEY / KEY_DOWN 1 - [ 5, 976067, 1, 108, 0] # EV_KEY / KEY_DOWN 0 - [ 5, 976067, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +155ms - evdev: - [ 6, 64481, 1, 108, 1] # EV_KEY / KEY_DOWN 1 - [ 6, 64481, 1, 108, 0] # EV_KEY / KEY_DOWN 0 - [ 6, 64481, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +88ms - evdev: - [ 9, 583316, 1, 30, 1] # EV_KEY / KEY_A 1 (obfuscated) - [ 9, 583316, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +3519ms - evdev: - [ 9, 841631, 1, 30, 0] # EV_KEY / KEY_A 0 (obfuscated) - [ 9, 841631, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +258msEdited by Peter Hutterer-
@whot yes "libinput list-devices" shows nothing but "libinput record" shows available rotary knob.
See for more logs I pasted in above reply. It's not joystick kind of but we have total 5 events. 2 using push buttons and 3 using rotary encoder (clock wise, anti clock wise and push the rotary encoder). We are sending KEY CODES accordingly from linux driver.
Let me know if more information is required.
libinput relies on udev to tell it what type of device it is. In this case because you're not using udev, there's no
ID_INPUT_KEYBOARDor other property set, so libinput simply won't recognise it as input device and won't use it. Once you set the required udev properties, it shoudl work as keyboard.Dear @whot thanks for your prompt response.
We can't use udev because it comes with systemd in buildroot and we are not using systemd for our system init. But we already using mdev which is light version of udev only.
Can you let me know what specifically udev does which can't be done by mdev? Also can't I hardcode some of the property in libinput so that it understand what type of device it is? We don't have any other possible input now or won't have in future for our product so we should be good even if it only supports our rotary encoder only as input device.
Please advise.
ftr, we don't need udev as much as we need libudev, specifically the ability to get a device from a devnode and list its properties. No idea how to do this with mdev though.
You can hardcode it in
evdev_device_get_udev_tags(), tag it withEVDEV_UDEV_TAG_KEYBOARDand you may be good to go.Hi @whot ,
I modified "libinput-1.15.6/src/evdev.c" file with following (in bold) and replaced generated library with /usr/lib/libinput.so.10.13.0 on my unit:
static enum evdev_device_udev_tags evdev_device_get_udev_tags(struct evdev_device *device, struct udev_device *udev_device) { enum evdev_device_udev_tags tags = 0; int i; for (i = 0; i < 2 && udev_device; i++) { unsigned j; for (j = 0; j < ARRAY_LENGTH(evdev_udev_tag_matches); j++) { const struct evdev_udev_tag_match match = evdev_udev_tag_matches[j]; if (parse_udev_flag(device, udev_device, match.name)) tags |= match.tag; } udev_device = udev_device_get_parent(udev_device); } ** tags |= EVDEV_UDEV_TAG_KEYBOARD;** return tags; }Rebooted device and still I am getting the same errors and no improvement.
Edited by Peter HuttererSorry for asking you silly questions (but I am new to this), I even did not get debug prints of this function. Is there anything needs to be enabled in weston.ini ??
core]1;? # i.MX: Disable idle timeout idle-time=0 gbm-format=argb8888 require-input=true [libinput] touchscreen_calibrator=true [shell] panel-location="" panel-position=none background-image="" [screen-share] command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resizeEdited by Hitesh Viradiya-
@HiteshViradiya, suspect @whot suggest adding something like:
diff --git a/src/evdev.c b/src/evdev.c index d8dfdadd..2eb3e273 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1668,6 +1668,9 @@ evdev_device_get_udev_tags(struct evdev_device *device, udev_device = udev_device_get_parent(udev_device); } + if (!strcmp(device->devname, "liveu-rotary-encoder")) + tags |= (EVDEV_UDEV_TAG_INPUT | EVDEV_UDEV_TAG_KEYBOARD); + return tags; } Hi @mvlad I tried this unconditionally "
tags |= (EVDEV_UDEV_TAG_INPUT | EVDEV_UDEV_TAG_KEYBOARD);" but it didn't helped.I doubt that I don't see debug prints in this function at all. So libinput is not bind properly with weston compositor or some configuration to bind libinput (which call this function) is missing.
Can you input what could be missing? Is there any tool I can check if libinput change is applied correctly ?
As per my understanding and as per QT link https://doc.qt.io/qt-5/inputs-linux-device.html
libinput is a library to handle input devices that offers an alternative to the Qt's own evdev input support. To enable using libinput, when you configure and build Qt, make sure that the development files for libudev and libinput are available. If you require keyboard support, then xkbcommon is also necessary. With eglfs and linuxfb, no further actions are necessary as these plugins use libinput by default. If libinput support is not available or the QT_QPA_EGLFS_NO_LIBINPUT environment variable is set, then Qt's own evdev handlers are used instead.
My QT5 configuration is as below:
Features used by QPA backends: evdev .................................. yes libinput ............................... yes INTEGRITY HID .......................... no mtdev .................................. yes tslib .................................. yes xkbcommon .............................. yes X11 specific: XLib ................................. no XCB Xlib ............................. no EGL on X11 ........................... no xkbcommon-x11 ........................ noThis means my QT is configured correctly. Any feedback.
Edited by Hitesh Viradiya-
You should be able to check if libinput works on embedded platforms by exporting an env variable
QT_LOGGING_RULES="qt.qpa.input=true"and then run your application. You should be able to see if the rotary knob is indeed being tagged or not and confirm that indeed it is using libinput, though so far it seems unlikely. @whot should have a better idea on why that patch doesn't work. @mvlad I am still getting warning in weston log:
[09:34:12.920] warning: no input devices on entering Weston. Possible causes: - no permissions to read /dev/input/event* - seats misconfigured (Weston backend option 'seat', udev device property ID_SEAT)My Application (which is browser) has some initial log as below:
# cat /tmp/messages.log | grep qt. 2021-10-29T09:34:16.072602+00:00 corecard stderr: qt.xkb.compose: using xkb compose input context 2021-10-29T09:34:16.075739+00:00 corecard stderr: qt.qpa.wayland: using input method: QComposeInputContext 2021-10-29T09:34:16.075869+00:00 corecard stderr: qt.qpa.wayland: Using Wayland-EGL 2021-10-29T09:34:16.125086+00:00 corecard stderr: qt.qpa.fonts: default fonts: system QFont(Sans Serif,9,-1,5,50,0,0,0,0,0) fixed QFont(monospace,9,-1,2,50,0,0,0,0,0) 2021-10-29T09:34:16.169798+00:00 corecard stderr: qt.qpa.input: Adding keyboard at /dev/input/rotaryencoder 2021-10-29T09:34:16.169942+00:00 corecard stderr: qt.qpa.input: Try to create keyboard handler for "/dev/input/rotaryencoder" "" 2021-10-29T09:34:16.170120+00:00 corecard stderr: qt.qpa.input: Opening keyboard at /dev/input/rotaryencoder 2021-10-29T09:34:16.170484+00:00 corecard stderr: qt.qpa.input: Create keyboard handler with for device "/dev/input/rotaryencoder" 2021-10-29T09:34:16.170636+00:00 corecard stderr: qt.qpa.input: Unload current keymap and restore built-in 2021-10-29T09:34:16.170757+00:00 corecard stderr: qt.qpa.input: numlock=0 , capslock=0, scrolllock=0 2021-10-29T09:34:16.173494+00:00 corecard stderr: qt.qpa.input: evdevmouse: Using device discovery 2021-10-29T09:34:16.173836+00:00 corecard stderr: qt.qpa.input: udev device discovery for type QFlags<QDeviceDiscovery::QDeviceType>(Device_Mouse|Device_Touchpad) 2021-10-29T09:34:16.187086+00:00 corecard stderr: qt.qpa.input: Found matching devices ()Any feedback/input ?
-
and replaced mdev with udev in our buildroot
Could this mean that even with the changes suggest by @whot those aren't actually executed because you really needed udev for it to be triggered? Kind of sounds like that. Well, glad it works now.
Yes that's correct @mvlad !! I just enabled eudev package in buildroot which has installed udevd and udevadm binaries. And As soon as S10udev deamon registered weston has started detecting keyboard in log. And the rest as I said, everything started working well.
apologies for the delay, I was on leave last week. Glad it's sorted, but for the future:
Is there any tool I can check if libinput change is applied correctly ?
libinput debug-eventscan be run from the builddir and is the easiest way to debug libinput's behaviour since you can even gdb through it. See the docs
