Re: Libinput-touch screen detection
On Wed, Oct 02, 2019 at 04:40:24PM +, sanjay anvekar wrote: > Hi Peter, Thank you for your response. I tried changing udev properties > but it didn't help. Here is output from udevadm command.udevadm info > /dev/input/event0P: > /devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0048/input/input0/event0N: > input/event0S: input/by-path/platform-21a4000.i2c-eventE: > DEVLINKS=/dev/input/by-path/platform-21a4000.i2c-eventE: > DEVNAME=/dev/input/event0E: > DEVPATH=/devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0048/input/input0/event0E: > ID_INPUT=1E: ID_PATH=platform-21a4000.i2cE: > ID_PATH_TAG=platform-21a4000_i2cE: MAJOR=13E: MINOR=64E: SUBSYSTEM=inputE: > USEC_INITIALIZED=2341962 > > Also tried with 'libinput-debug-events' and following is > outputlibinput-debug-events --device /dev/input/event0 --verboseinput device > 'touchscreen', /dev/input/event0 not tagged as input devicefailed to create > input device '/dev/input/event0'.Failed to initialized device > /dev/input/event0 > I tested this input device with 'evetest' application and it works, but > doesn't work with libinput. > How do I debug further and conclude that it is Kernel driver issue ? Please > let me know. > Thanks & Best Regards,Sanjay fwiw, the plain text your email client sends appears to be ... broken. you're missing ID_INPUT_TOUCHSCREEN which is probably you're missing BTN_TOUCH on the evdev node. run libinput record and that'll tell you the bits set for the device - for a touchscreen you need ABS_X/Y and BTN_TOUCH as the minimum. look for the udev-builtin-input_id.c file in the systemd git repo, that will tell you how the various ID_INPUT_FOO tags get applied. Then you need to make sure the kernel exports those. Cheers, Peter > > > > > On Wednesday, 2 October, 2019, 02:50:39 pm GMT+1, Peter Hutterer > wrote: > > On Tue, Oct 01, 2019 at 04:08:17PM +, sanjay anvekar wrote: > > Hi All, I am new to Wayland. I am using Weston 1.9.0 on imx6x board with > > touchscreen display of resolution 1024x768. I am seeing touchscreen as > > /dev/input/event0 device and it is working. I confirmed functioning of > > touchscreen using "cat /dev/input/event0" command. Unfortunately, I don't > > see touchscreen is listed by libinput application i.e. > > 'libinput-list-devices'. If I connect USB mouse then I see mouse is listed > > by 'libinput-list-devices' application, but not touchscreen. I am running > > Qt application and it is not able to detect touch inputs. Please let me > > know your inputs to resolve this problem. > > most likely the udev property ID_INPUT and/or ID_INPUT_TOUCHSCREEN is > missing for this device, libinput debug-events --verbose should print > *something* at least for the device. > > If the property is missing though that means that it doesn't export the > correct evdev bits to be picked up by the udev builtin, so most likely the > kernel driver needs to be fixed. > > Cheers, > Peter > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput-touch screen detection
Hi Peter, Thank you for your response. I tried changing udev properties but it didn't help. Here is output from udevadm command.udevadm info /dev/input/event0P: /devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0048/input/input0/event0N: input/event0S: input/by-path/platform-21a4000.i2c-eventE: DEVLINKS=/dev/input/by-path/platform-21a4000.i2c-eventE: DEVNAME=/dev/input/event0E: DEVPATH=/devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0048/input/input0/event0E: ID_INPUT=1E: ID_PATH=platform-21a4000.i2cE: ID_PATH_TAG=platform-21a4000_i2cE: MAJOR=13E: MINOR=64E: SUBSYSTEM=inputE: USEC_INITIALIZED=2341962 Also tried with 'libinput-debug-events' and following is outputlibinput-debug-events --device /dev/input/event0 --verboseinput device 'touchscreen', /dev/input/event0 not tagged as input devicefailed to create input device '/dev/input/event0'.Failed to initialized device /dev/input/event0 I tested this input device with 'evetest' application and it works, but doesn't work with libinput. How do I debug further and conclude that it is Kernel driver issue ? Please let me know. Thanks & Best Regards,Sanjay On Wednesday, 2 October, 2019, 02:50:39 pm GMT+1, Peter Hutterer wrote: On Tue, Oct 01, 2019 at 04:08:17PM +, sanjay anvekar wrote: > Hi All, I am new to Wayland. I am using Weston 1.9.0 on imx6x board with > touchscreen display of resolution 1024x768. I am seeing touchscreen as > /dev/input/event0 device and it is working. I confirmed functioning of > touchscreen using "cat /dev/input/event0" command. Unfortunately, I don't > see touchscreen is listed by libinput application i.e. > 'libinput-list-devices'. If I connect USB mouse then I see mouse is listed > by 'libinput-list-devices' application, but not touchscreen. I am running > Qt application and it is not able to detect touch inputs. Please let me > know your inputs to resolve this problem. most likely the udev property ID_INPUT and/or ID_INPUT_TOUCHSCREEN is missing for this device, libinput debug-events --verbose should print *something* at least for the device. If the property is missing though that means that it doesn't export the correct evdev bits to be picked up by the udev builtin, so most likely the kernel driver needs to be fixed. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput-touch screen detection
On Tue, Oct 01, 2019 at 04:08:17PM +, sanjay anvekar wrote: > Hi All, I am new to Wayland. I am using Weston 1.9.0 on imx6x board with > touchscreen display of resolution 1024x768. I am seeing touchscreen as > /dev/input/event0 device and it is working. I confirmed functioning of > touchscreen using "cat /dev/input/event0" command. Unfortunately, I don't > see touchscreen is listed by libinput application i.e. > 'libinput-list-devices'. If I connect USB mouse then I see mouse is listed > by 'libinput-list-devices' application, but not touchscreen. I am running > Qt application and it is not able to detect touch inputs. Please let me > know your inputs to resolve this problem. most likely the udev property ID_INPUT and/or ID_INPUT_TOUCHSCREEN is missing for this device, libinput debug-events --verbose should print *something* at least for the device. If the property is missing though that means that it doesn't export the correct evdev bits to be picked up by the udev builtin, so most likely the kernel driver needs to be fixed. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput drops keys from infrared remotes after changing keymap
Hi Sean, On 02-10-2019 11:33, Sean Young wrote: Hi, On Tue, Oct 01, 2019 at 03:32:52PM +0200, Hans de Goede wrote: On 01-10-2019 10:39, Sean Young wrote: On Mon, Sep 30, 2019 at 01:29:59PM +0200, Hans de Goede wrote: So can you please explain your specific use-case here? Simply loading a new keymap while logged in, or rather solve the issue of "my remote doesn't work after loading the correct keymap". > My longer term goal is to provide gnome-control-center plugin for configuring IR receivers. So what I'm hearing is that from libinput's perspective, an input device should not change once created. In order to support this use-case, either ask the user to logout/login or the kernel should re-create the input device when the keymap changes. Right, so if this is for a gnome-control-center plugin then I guess the idea is the user sets things up once and then they never change, right? Yes, that's the idea. It might need an interface for testing keymaps and/or adding custom keymaps. That depends on the community, really. So how does the keymap stay set / gets stored ? Do you write it out globally so that udev will do the right thing next boot. So ir-keytable comes with a udev rule which automagically load the keymap based on what's in /etc/rc_maps.cfg. I'm not sure how this should be written from g-c-c or whether this is right thing to do. See: https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/70-infrared.rules Ok. Or does the g-c-c plugin register an autostart user service which does this once the user logs in? I'm not convinced that's the right approach. Right, I agree. I think i would be best for the g-c-c plugin to set the rcmap globally which would mean writing out /etc/rc_maps.cfg. The normal way to do this is a small dbus activated daemon (so that it is not running all the time and is not started unnecessarily at boot) which can write out /etc/rc_maps.cfg for us. Such a daemon would then normally use polkit to check if the process making dbus calls to change the config is allowed to do so (reading it can be allowed to the world I think). Assuming you set the mapping globally, then you need some DBUS activated helper daemon running as root, or some such, right (hopefully with access managed by polkit)? Then it wouldn't be too hard to do the: sudo udevadm trigger --action=remove /sys/class/input/event5 sudo udevadm trigger --action=add /sys/class/input/event5 Peter suggested from that daemon, and if this is only done on keymap changes, then this seems like a reasonable solution? It does seem reasonable. It seemed a bit strange at first. I've been maintaining rc-core (IR) kernel side for some time, I'm trying to move up the stack. Your help is very much appreciated! You're welcome. As mentioned above I believe a dbus activated daemon to do the actual config changes (with polkit as authorization mechanism) would be best here. That is more or less the standard design pattern for cases like this. See e.g. also systemd-localed for writing /etc/vconsole.conf, etc. Regards, Hans ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput drops keys from infrared remotes after changing keymap
Hi, On Tue, Oct 01, 2019 at 03:32:52PM +0200, Hans de Goede wrote: > On 01-10-2019 10:39, Sean Young wrote: > > On Mon, Sep 30, 2019 at 01:29:59PM +0200, Hans de Goede wrote: > > > So can you please explain your specific use-case here? > > > > Simply loading a new keymap while logged in, or rather solve the issue of > > "my remote doesn't work after loading the correct keymap". > > > My longer term goal is to provide gnome-control-center plugin for > > configuring IR receivers. > > > > So what I'm hearing is that from libinput's perspective, an input device > > should not change once created. In order to support this use-case, either > > ask the user to logout/login or the kernel should re-create the input > > device when the keymap changes. > > Right, so if this is for a gnome-control-center plugin then I guess > the idea is the user sets things up once and then they never change, right? Yes, that's the idea. It might need an interface for testing keymaps and/or adding custom keymaps. That depends on the community, really. > So how does the keymap stay set / gets stored ? Do you write it out > globally so that udev will do the right thing next boot. So ir-keytable comes with a udev rule which automagically load the keymap based on what's in /etc/rc_maps.cfg. I'm not sure how this should be written from g-c-c or whether this is right thing to do. See: https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/70-infrared.rules > Or does the > g-c-c plugin register an autostart user service which does this once > the user logs in? I'm not convinced that's the right approach. > Assuming you set the mapping globally, then you need some DBUS activated > helper daemon running as root, or some such, right (hopefully with > access managed by polkit)? Then it wouldn't be too hard to do the: > > sudo udevadm trigger --action=remove /sys/class/input/event5 > sudo udevadm trigger --action=add /sys/class/input/event5 > > Peter suggested from that daemon, and if this is only done on > keymap changes, then this seems like a reasonable solution? It does seem reasonable. It seemed a bit strange at first. I've been maintaining rc-core (IR) kernel side for some time, I'm trying to move up the stack. Your help is very much appreciated! Many thanks, Sean ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
