Re: Help writing a virtual touchpad
Thanks a lot for your detailed response, that blog post was amazing and it made some things much more clearer. At the end, I managed to write a kernel driver that receives input through a character device and sends raw input events, without ever knowing the existence of evdev. It still need a lot of tweaking regarding resolution and which events I should send and which not. (e.g. should I communicate the pressure if my data does not contain information about it? What about tool_width/major-axis and such?) Anyway, with some trial and error the driver kinda works and I got to see 1:1 multitouch gesture on GNOME 40 :) Regarding performance: I use a userspace process to write to a character device which talks to my kernelspace code, maybe using evdev directly avoids some layers of abstraction? And in this way I don’t have to write any kernelspace code right? Repo with my code: https://github.com/thegoldgoat/toccami_driver Thank you so much, Andrea Il 11 mag 2021, 03:09 +0200, Peter Hutterer , ha scritto: > On Sat, May 08, 2021 at 12:45:24PM +0200, Andrea Somaini wrote: > > Hello, > > I was thinking about creating a virtual touchpad device for Linux > > I never worked on such low level software, so I feel kinda lost > > Can someone please point me where should I start? > > The best option you have at this point is to emulate an evdev node that > behaves like a touchpad. That's both straightforward and complicated at the > same time. The code itself is trivial (use python-libevdev, check the > examples directory) but getting touchpads right in evdev can be a bit > tricky - you really need to know the details of the evdev protocol. > > If you look at the libinput test devices (e.g. > test/litest-device-synaptics-rmi4.c) you get a **rough** idea of the events > you need to send for a finger down event and a finger move event. > You still need to handle BTN_TOOL_DOUBLETAP, etc. > What I recommend is: use libinput record to record 1, 2, 3... finger > interactions on your normal touchpad to get the set of data sent, then > emulate that device. Axis ranges and coordinates can generally be changed > at-will, but the set of events within each frame has to be correct (or > correct enough) to be processed as expected. > > https://who-t.blogspot.com/2016/09/understanding-evdev.html has some > explanations too. > > Cheers, > Peter > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Help writing a virtual touchpad
On Tue, May 11, 2021 at 10:15:39AM +0200, Andrea Somaini wrote: > Thanks a lot for your detailed response, that blog post was amazing and it > made some things much more clearer. > > At the end, I managed to write a kernel driver that receives input through > a character device and sends raw input events, without ever knowing the > existence of evdev. It still need a lot of tweaking regarding resolution > and which events I should send and which not. (e.g. should I communicate > the pressure if my data does not contain information about it? What about > tool_width/major-axis and such?) The only thing pressure is used for atm is for palm and thumb detection. Given you're writing a virtual touchpad, you shouldn't need either. Same for major/minor. Tool width is unused in libinput so I wouldn't bother with it either. > Anyway, with some trial and error the driver kinda works and I got to see > 1:1 multitouch gesture on GNOME 40 :) > > Regarding performance: I use a userspace process to write to a character > device which talks to my kernelspace code, maybe using evdev directly > avoids some layers of abstraction? And in this way I don’t have to write > any kernelspace code right? correct, uinput is a module supported everywhere and would not require a custom kernel module. Using it removes one moving part, you only need the userspace process because everything else is already there (and well-tested :) Cheers, Peter > > Repo with my code: https://github.com/thegoldgoat/toccami_driver > > Thank you so much, > Andrea > Il 11 mag 2021, 03:09 +0200, Peter Hutterer , ha > scritto: > > On Sat, May 08, 2021 at 12:45:24PM +0200, Andrea Somaini wrote: > > > Hello, > > > I was thinking about creating a virtual touchpad device for Linux > > > I never worked on such low level software, so I feel kinda lost > > > Can someone please point me where should I start? > > > > The best option you have at this point is to emulate an evdev node that > > behaves like a touchpad. That's both straightforward and complicated at the > > same time. The code itself is trivial (use python-libevdev, check the > > examples directory) but getting touchpads right in evdev can be a bit > > tricky - you really need to know the details of the evdev protocol. > > > > If you look at the libinput test devices (e.g. > > test/litest-device-synaptics-rmi4.c) you get a **rough** idea of the events > > you need to send for a finger down event and a finger move event. > > You still need to handle BTN_TOOL_DOUBLETAP, etc. > > What I recommend is: use libinput record to record 1, 2, 3... finger > > interactions on your normal touchpad to get the set of data sent, then > > emulate that device. Axis ranges and coordinates can generally be changed > > at-will, but the set of events within each frame has to be correct (or > > correct enough) to be processed as expected. > > > > https://who-t.blogspot.com/2016/09/understanding-evdev.html has some > > explanations too. > > > > Cheers, > > Peter > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Dell Totem support / libinput bug: Event for missing capability CAP_POINTER on device "Advanced Silicon S.A. CoolTouch® System System Multi Axis"
On Mon, May 10, 2021 at 09:05:55AM +0200, Max Maischein wrote: > Hi all, > > I got a Dell Canvas+Totem widget (on clearance, they are discontinued), > and got the following error message when running `libinput debug-events`: > > libinput bug: Event for missing capability CAP_POINTER on device > "Advanced Silicon S.A. CoolTouch® System System Multi Axis" > > The recorded sequence is "drop the totem on the screen, click it (this > is where the error shows up), lift it again", recorded using > > libinput record /dev/input/event9 -o dell-totem-drop-click-lift-20210510.yml > > Is there anything more I can do to help? I'd really like to use the > totem as a secondary mouse/tool, but so far, it "only" gets detected as > a primary mouse (without configuration or anything, so that's really > great already). best to file an issue against libinput, debugging over email is pretty terrible. > Is there anything more I can do to help? I'd really like to use the > totem as a secondary mouse/tool, but so far, it "only" gets detected as > a primary mouse (without configuration or anything, so that's really > great already). fwiw, if the device is indeed detected as totem, then you can't do... anything. The totem is a tablet tool and exposed as such - without client-side support to map that tool into something else you cannot use it for anything (that would require compositor, wayland and toolkit support). And the amount of effort required to add bimanual interaction to applications is, let's just say "nontrivial" :) That's the main reason totem support never got past the libinput API, the number of people using them is so close to zero that it just wasn't worth the effort. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Dell Totem support / libinput bug: Event for missing capability CAP_POINTER on device "Advanced Silicon S.A. CoolTouch® System System Multi Axis"
Hello Peter, >> I got a Dell Canvas+Totem widget (on clearance, they are discontinued), >> and got the following error message when running `libinput debug-events`: >> >> libinput bug: Event for missing capability CAP_POINTER on device >> "Advanced Silicon S.A. CoolTouch® System System Multi Axis" >> > > best to file an issue against libinput, debugging over email is pretty > terrible. I'll file a bug, thanks! >> Is there anything more I can do to help? I'd really like to use the >> totem as a secondary mouse/tool, but so far, it "only" gets detected as >> a primary mouse (without configuration or anything, so that's really >> great already). > > fwiw, if the device is indeed detected as totem, then you can't do... > anything. The totem is a tablet tool and exposed as such - without > client-side support to map that tool into something else you cannot use it > for anything (that would require compositor, wayland and toolkit support). > And the amount of effort required to add bimanual interaction to > applications is, let's just say "nontrivial" :) > > That's the main reason totem support never got past the libinput API, the > number of people using them is so close to zero that it just wasn't worth > the effort. Yes, I expected that :) My "plan" is to basically write my own libinput client to see what events I get from libinput and if I can do anything sensible with them, but before I embark on this, I wanted to know if there is a simpler way. Thanks again, -max ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
