Page MenuHomeFreeBSD

enable synaptics and elantech touchpads by default
ClosedPublic

Authored by zeising on Jun 3 2019, 8:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 18 2024, 4:58 PM
Unknown Object (File)
Feb 18 2024, 10:57 AM
Unknown Object (File)
Feb 17 2024, 11:26 PM
Unknown Object (File)
Dec 31 2023, 1:51 AM
Unknown Object (File)
Dec 25 2023, 7:56 PM
Unknown Object (File)
Dec 22 2023, 9:06 PM
Unknown Object (File)
Dec 12 2023, 6:21 PM
Unknown Object (File)
Dec 9 2023, 12:57 PM

Details

Summary

It's time to enable synaptics and elantech touchpads by default. Today, users have to fiddle with loader tunables to get their touchpads to use things such as two finger scroll and so on, even in X. By enabling these settings by default, we get a better desktop experience in X, since xserver and evdev can make use of the more advanced synaptics and elantech features.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 24670

Event Timeline

This change should do what it says it will do.
Let's see if we can get a bunch of 'works for me' reports from testers :)

sys/dev/atkbdc/psm.c
517

We should perhaps also enable trackpoint support, while we're at it. What do you think @wulf ?

I wasn't even aware of this until I read the code...

Count this "accept" as "commit approval"

sys/dev/atkbdc/psm.c
517

Yes, please, make Lenovo users happy!

This revision is now accepted and ready to land.Jun 3 2019, 9:04 PM
0mp added a subscriber: 0mp.

Sounds like a good idea!

Also enable trackpad support by default.

This revision now requires review to proceed.Jun 4 2019, 8:24 AM
This revision is now accepted and ready to land.Jun 4 2019, 10:50 AM
salvadore requested changes to this revision.EditedJun 4 2019, 11:06 AM
salvadore added a subscriber: salvadore.

I tested by patching my stable sources r348603.

The system successfully found my Elantech touchpad:

kernel: psm0: <PS/2 Mouse> irq 12 on atkbdc0
kernel: psm0: [GIANT-LOCKED]
kernel: psm0: model Elantech Touchpad, device ID 0

However I was unable to get it working with X. Tapping is almost completely broken and after a few minutes the pointer also stops to move. Most probably I have not configured correctly xorg (I tried using libinput, but I was unsuccessful: suggestions are welcome), but in any case, it does not work out of the box for me. Then, unless my case is very rare, I would avoid enabling touchpad support by default.

This revision now requires changes to proceed.Jun 4 2019, 11:06 AM

This is for current only, where changes to the drivers has been made as well, and evdev is the default. Which version of FreeBSD are you using? Can you provide logs, and output from libinput list-devices.

Thanks.

This was tried some years ago, but then reverted as the probing was deemed too intrusive (see r255152 and r255210). I don't know if something changed in the meantime.

I've had "synaptics_support" and "trackpoint_support" enabled for years on my Thinkpads without problems though.

This was tried some years ago, but then reverted as the probing was deemed too intrusive (see r255152 and r255210). I don't know if something changed in the meantime.

I've had "synaptics_support" and "trackpoint_support" enabled for years on my Thinkpads without problems though.

That was indeed years ago, 2013 to be exact. There has been changes to the driver since then, quite a few commits. I don't know if anything has changed with regards to probing, or even what was meant by "too intrusive". I've send a mail on this topic to current@ asking for feedback there as well, hopefully someone will respond there. Perhaps the issues can be fixed instead, but as long as hardly anyone uses this, that won't happen.

I still feel we need to enable this, to get good support in graphical environments (where most touchpads tend to show up). Not having features such as 2 finger scroll does not look good.

I think libinput does not see my touchpad at all. Here is a log with the mouse driver installed:

I think xorg chooses the mouse driver instead of using libinput, then the mouse driver works in a buggy way with touchpad support enabled. If I remove from the system the mouse driver, then I am unable to move the pointer in any way and I get this other log:

In any case, libinput list-devices does not return any output.

In D20507#442998, @phascolarctos_protonmail.ch wrote:

In any case, libinput list-devices does not return any output.

In that case, it's not running properly. What version of FreeBSD are you using? is evdev enabled in the kernel?

In D20507#442998, @phascolarctos_protonmail.ch wrote:

I think libinput does not see my touchpad at all. Here is a log with the mouse driver installed:

It looks like xorg choose wrong protocol. PS/2 instead of sysmouse. Please, run moused before Xorg to get console mouse pointer moveable with trackpad. And run Xorg only after that!

I think xorg chooses the mouse driver instead of using libinput, then the mouse driver works in a buggy way with touchpad support enabled. If I remove from the system the mouse driver, then I am unable to move the pointer in any way and I get this other log:

In any case, libinput list-devices does not return any output.

Our devd Xorg autoconfiguration backend does not support evdev devices out of box, so you have to add evdev devices to your xorg.conf with hands or apply patch from PR/196678

FreeBSD version is 12.0-STABLE r348603.
I was missing evdev support (I needed both device evdev and options EVDEV_SUPPORT).
Now libinput returns the following output:

The touchpad still does not work.

(written while wulf was writing his comment. Now I'm going to try his suggestions.)

In D20507#443011, @phascolarctos_protonmail.ch wrote:

(written while wulf was writing his comment. Now I'm going to try his suggestions.)

simplest way to start moused on /dev/psm0 properly is

# service moused onestart

Starting moused worked, there was no need to apply the patch from PR/196678. I have tested a bit the touchpad and everything seems to work as expected.
Thank you very much zeising and wulf.

As for enabling the touchpad support by default, I agree, but I think the possible need for moused should be documented in the handbook (I could not find it in there). For example in section 5.9:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-understanding.html

This revision is now accepted and ready to land.Jun 4 2019, 3:19 PM

After some digging it appeared that xf86-input-mouse unconditionally enables so called "native operation level" being attached to /dev/psm0 device node. It means that it effectively replaces our kernel driver with his own PS/2 packet parser.
So we have 2 choices:

  1. Forbid enabling of "native operation level" in xf86-input-mouse driver. It looks like commenting out one #define line
  2. Force all touchpad users to run moused to grab /dev/psm0 device and reroute its packets via /dev/sysmouse before Xorg is started.

I prefer solution 1.

If you can tell me which is the line to comment or provide a patch I can test it.

In D20507#443112, @phascolarctos_protonmail.ch wrote:

I prefer solution 1.

If you can tell me which is the line to comment or provide a patch I can test it.

Please edit /usr/ports/x11-drivers/xf86-input-mouse/files/patch-src-bsd_mouse.c and replace
+#define XPS2_SUPPORT
with
+/*#define XPS2_SUPPORT*/
at line 20.
Than reinstall recompiled x11-drivers/xf86-input-mouse port, stop moused, and restart Xorg.

I tested and it works. Thanks!

Unless solution 1 has some side effects for someone (I think to people using a mouse instead of a touchpad), I think this is the solution to adopt: if we want touchpads to work out of the box, we can not ask users to start moused before xorg. Of course, they can add moused_enable="YES" to their rc.conf, but if we can make a small change to the xf86-input-mouse port it looks much easier: it affects only users of xorg and avoids to run a daemon on the system.

In D20507#443152, @phascolarctos_protonmail.ch wrote:

I tested and it works. Thanks!

Unless solution 1 has some side effects for someone (I think to people using a mouse instead of a touchpad),

I doubt it can produce side effects. Albeit psm packet parser is replaced with Xorg`s one, PS/2 device recognition is still relies on in-kernel probe() function. So Xorg can not handle any PS/2 devices unknown to base system.

I think this is the solution to adopt: if we want touchpads to work out of the box, we can not ask users to start moused before xorg. Of course, they can add moused_enable="YES" to their rc.conf, but if we can make a small change to the xf86-input-mouse port it looks much easier: it affects only users of xorg and avoids to run a daemon on the system.

Better solution is to run moused from devd exactly like it is done for ums(4), but it does not work for me now.

I think editing xf86-input-mouse is the better option as well.

A thing I do not like about the moused solution is that it shows a pointer on consoles too: I find it annoying.

I made a diff file for the suggested patch for xf86-input-mouse, if it can be useful for testing. I can also open a new PR on bugzilla for asking to commit it if you want, with a link to this revision to explain where it comes from and who found this solution.

This was tried some years ago, but then reverted as the probing was deemed too intrusive (see r255152 and r255210). I don't know if something changed in the meantime.

Synaptics and Elantech probe() does not depend on loader tuneables at all. Magic knock and capability queries are always performed regardless of kernel boot parameters so it cannot be called "too intrusive".
But IBM trackpoint probe() is different thing. It is performed in different ways depending on 'synaptics_support' variable value.
Browsing through the commit log shows me that there were several patches submitted by you to fix various trackpoint issues circa 2015 so it's worth trying to enable it by default again as support of this device is definitely changed since 2013.

... so it's worth trying to enable it by default again as support of this device is definitely changed since 2013.

Very much agreed -- if setting those tunables to 1 uncovers any bugs with other devices, those bugs can be fixed.

This revision was automatically updated to reflect the committed changes.