Talk:Libinput

Scrolling issue

I'm not sure where to go for support of this.

Accidentally scrolling where my palm touches my T460s trackpad enters some text

http://s.natalian.org/2016-09-16/libinput-list-devices.txt

How do I limit or disable this unwanted behaviour?

—This unsigned comment is by Hendry (talk) 02:30, 16 September 2016. Please sign your posts with ~~~~!

Look through the man page for libinput(4). "DisableWhileTyping" might be what you are looking for. -- Cqql (talk) 02:34, 16 September 2016 (UTC)

"DisableWhileTyping" is enabled by default. TappingDrag may be another culprit. --Indigo (talk) 17:59, 11 November 2024 (UTC)

How to adjust touchpad scroll speed?

Does someone know how to adjust, change or modify the rate/speed of the touchpad scrolling?

--Orschiro (talk) 04:41, 26 June 2017 (UTC)

To adjust touchpad scroll speed you can download libinput-config-git^AUR and modify the config

/etc/libinput.conf

scroll-factor=0.3

The changes should take effect on next boot.

--Pavelskipenes (talk) 22:30, 28 November 2022 (UTC)

Alternatives to libinput-gestures

I've been interested by the functionalities provided by libinput-gestures or fusuma. However, after trying libinput-gestures I was disappointed to find out that it was unusable on my laptop due to using the output of libinput debug-events which is not a stable way to read inputs.

Moreover, libinput-gestures being written in Python (which is an interpreted language), brings another limitation : you must either add your linux user as a member of the input group, or use the sgid way on the interpreter. Both methods pose a security risk and make life easier for keyloggers.

The article mentions alternatives :

• fusuma is written in ruby, and uses libinput debug-events : it has the exact same issues
• gebaar is written in C++ but is unmaintained. Moreover, it recommends adding your linux user to the input group, which I think should be avoided as mentioned above. All this also applies to gebaar's fork.

For all the reasons above, I don't think these softwares should be recommended without at least warning the reader.

I have been working on an alternative to address these concerns, which I'm writing in C. It offers nearly the same features as the Python libinput-gestures (with a few key differences) :

• Is its own binary : you can change the group owner to input, set the sgid on it, and then run it as a regular user that is not a member of the input group themselves.
• Supports mapping gestures to external commands immediately when a pinch or a swipe reaches a given threshold. Supports repeating these actions when the swipe or pinch continues after first crossing the threshold.
• Supports triggering actions
• Does not support runtime configuration files for now (I plan on adding this soon) : you need to edit a header file and compile it yourself (similar to some suckless programs such as dwm)
• Does not support "diagonal" swipes

I'm leaving a GitHub link to this project for those of you that want to check it out.

It still a bit rough around the edges, however, it's getting close to a state where it can replace the Python libinput-gestures while fixing its two biggest quirks. After I add support for runtime configuration files, add some proper documentation, and bundle this up in an easy to install way, I hope this will be good enough that it can be recommended here. What process should I follow before adding it to the article ?

Pcouy (talk) 17:22, 4 May 2023 (UTC)

Thanks for asking. You're welcome to phrase a short, general warning (see Template:Warning) and place it in the article (e.g. at the end of Libinput#Gestures before the subsections), if you believe it is warranted (ideally link an external reference/discussion of the underlying issue).

For your own package: As general guidance we prefer contributions to be accompanied by an installable package, but there are regular exceptions to that. So, I suggest you create an Aur package for the project first. If you need help for creating the PKGBUILD, there is an AUR mailing list with a lot of helpful people.

As for adding a subsection for your tool/package: We always endeavour content to be neutral (re 'recommendation'), describing pros/cons to let users decide. Also, we don't want to duplicate upstream documentation but link to it and keep wiki content Arch Linux focussed. I suggest you draft a short subsection first (e.g. in your personal User:Pcouy page) and move it as a new subsection to Libinput#Gestures once you're happy with it. If you wish you can also link a draft here first to ask for opinions, that's up to you as subject expert.

As a final sidenote: Personally I find your project naming choice not ideal and can anticipate confusion with the widely known python version. Also I note you mix singular and plural (libinput-gestures vs libinput-gesture) for both the python upstream and your project. Both are bound to create confusion for users (and their installs). Perhaps consider renaming the project first, which would iron both out.

--Indigo (talk) 09:21, 6 May 2023 (UTC)

Thanks for the feedback. I'll add a warning for my concerns about the currently recommended tools. I'll also closely follow your advice on publishing it as an AUR and staying neutral and objectively presenting pros and cons.

I've fixed the mixup between singular and plural in both the post and the readme.

About the confusion you anticipate, do you think it's fine to keep the same repository name on github and then using a different package name when I release it later as a package ?

Pcouy (talk) 11:52, 11 May 2023 (UTC)

Sorry, I missed your question; for the wiki it does not matter how you name your AUR package. --Indigo (talk) 18:11, 11 November 2024 (UTC)