CFT: EVDEV support in psm(4) driver

8 views
Skip to first unread message

Vladimir Kondratyev

unread,
Apr 16, 2017, 3:25:25 PM4/16/17
to cur...@freebsd.org, freebsd...@freebsd.org
Hi, FreeBSD laptop users

Following patch [1] bring in multitouch EVDEV support for Synaptics and
Elan PS/2
touchpads found in many laptops. (And for generic relative PS/2 mices as
well).
This allows to replace our limited in-kernel gesture processor with
full-blown
one from xf86-input-synaptics or xf86-input-libinput driver and makes
Synaptics and Elan PS/2 touchpad support to be mostly on par with Linux

Other mostly evdev-unrelated fixes and improvements are:

1. Fix rare but quite annoying issue in Elan hw v.4 touchpads support.
Triple-finger taps are reported as double-finger taps under several
circumstances.
2. Adjust tap min queue size on Elans to make multifinger tap detection
more reliable.
3. Adjust Elantech palm width threshold to nearly match synaptics
defaults
4. Discard pointer movements rather then mouse packets on palm detection
to reduce cursor jumping.
5. Enable palm detection on two finger touches for multitouch trackpads.
6. Reduce synaptics touch sensitivity
Increase hw.psm.synaptics.min_pressure default value from 16 to 32
to nearly match Linux driver (30-35 hysteresis loop).
This makes libinput tap detection more reliable.
7. Serialize atkbdc ports and psm softc access with mutexes
and mark psm interrupt and cdev handlers MPSAFE

Patch is made for 12-CURRENT and most probably can be applied to recent
11-STABLE (not tested)


How to test.

1. Apply patch [1]
2. Add `device evdev` and `options EVDEV_SUPPORT` to kernel config file
and rebuild kernel
3. Add hw.psm.elantech_support=1 or hw.psm.synaptics_support=1 to
/boot/loader.conf
4. Add kern.evdev.rcpt_mask=12 to /etc/sysctl.conf to enable psm source
and disable sysmouse
5. Install x11-drivers/xf86-input-synaptics port compiled with EVDEV
support enabled or
x11-drivers/xf86-input-libinput
6. Tell XOrg to use synaptics or libinput driver as primary mouse
driver:

Section "InputDevice"
Identifier "Mouse0"
Driver "synaptics"
# Driver "libinput"
Option "Device" "/dev/input/eventXXX"
EndSection

Exact value of "/dev/input/eventXXX" can be obtained with evemu-record
utiliy [2].
In most cases I have seen psm event device is located at
/dev/input/event2.
Lenovo trackpoint should appear as separate relative event device and is
handled with xf86-input-evdev driver (not tested yet)
Note: Neither HAL nor DEVD Xorg configuration backends support evdev at
present time so
x11-servers/xorg-server should be recompiled w/o autoconfiguration
support.
Alternatively DEVD or UDEV backends from coming Xorg update [3] can be
used
7. Reboot and test touchpad with XOrg or evemu-record

[1] psm(4) evdev support: https://reviews.freebsd.org/D10207
Raw diff:
https://reviews.freebsd.org/file/data/pqjvpuhwfgsu5nnamibg/PHID-FILE-uuyjx66blb344hre3nc2/D10207.vson.id27478.whitespaceignore-most.diff
[2] evemu port: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218383
Not commited yet.
[3] Xorg 1.19.3 update:
https://lists.freebsd.org/pipermail/freebsd-x11/2017-March/019100.html
(Patch content is slightly garbled)


--
WBR
Vladimir Kondratyev
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Jan Kokemüller

unread,
Apr 17, 2017, 7:00:16 AM4/17/17
to Vladimir Kondratyev, cur...@freebsd.org, freebsd...@freebsd.org
Hi Vladimir,
this patch works great for me!
I'm testing this with a semi-mt Synaptics touchpad and a TrackPoint of a
Lenovo T420. I'm running 12-CURRENT (amd64) and Xorg 1.19.3 from
Matthew's CFT with the libudev-devd backend. The Evdev devices are
picked up correctly by libudev-devd and xf86-input-libinput (even the
TrackPoint). I haven't tested this with xf86-input-synaptics (which is
in maintenance mode) or xf86-input-evdev. I am not
using xf86-input-mouse or xf86-input-keyboard.

What works (everything):
- true smooth scrolling with Xinput2 (tested with GTK3 Firefox or
gtk3-demo)
- TrackPoint scrolling holding the middle button
- both horizontal/vertical scrolling
- two finger scrolling powered by libinput (this semi-mt touchpad
doesn't really support more gestures than this)

The only thing that doesn't work out of the box is the mouse pointer on
the VT console. It wouldn't be hard though to write a small tool that
uses libinput to translate Evdev events into CONS_MOUSECTL ioctls needed
for the VT pointer.

Some comments:
- PS2_MOUSE_SYNAPTICS_PRODUCT should be 0x0007, not 0x0009
(http://lxr.free-electrons.com/source/drivers/input/mouse/psmouse.h#L86)
- The TrackPoint should be added with product id 0x000A as on Linux
and with the INPUT_PROP_POINTING_STICK Evdev property set
- I think it would be better if the same Evdev device names were
exposed as on Linux (for example "SynPS/2 Synaptics TouchPad"). Many
scripts using xinput to change device properties depend on the Linux
device names.

I've added a patch and comments to https://reviews.freebsd.org/D10265 .

Even Linux 64-bit binaries work correctly with the created
/dev/input/event* devices after applying those two patches here:
- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218625
- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218627

This will be very useful for Linux games using joysticks, game
controllers etc.

Cheers,
Jan

Vladimir Kondratyev

unread,
Apr 17, 2017, 4:10:31 PM4/17/17
to Jan Kokemüller, cur...@freebsd.org, freebsd...@freebsd.org
On 2017-04-17 13:59, Jan Kokemüller wrote:
> Hi Vladimir,
> this patch works great for me!
Great!

> I am not using xf86-input-mouse or xf86-input-keyboard.

You stepped on minefield. xf86-input-keyboard does things that should
be done by xorg-server like terminal blanking, disabling keybuffering
and so on. I had seen (and heard) some funny effects before copied
required ~20 lines of code from xf86-input-keyboard to xorg-server.

> - TrackPoint scrolling holding the middle button

Thanks for report. I was not able to test trackpoint due to lack of
hardware.

> The only thing that doesn't work out of the box is the mouse pointer
> on the VT console. It wouldn't be hard though to write a small tool
> that uses libinput to translate Evdev events into CONS_MOUSECTL ioctls
> needed for the VT pointer.

Just run moused on /dev/psm0. Unlike usermode drivers like
xf86-input-synaptics
in psm mode, in-kernel driver keeps psm0 device unbusied in sysmouse
mode.

> Some comments:
> - PS2_MOUSE_SYNAPTICS_PRODUCT should be 0x0007, not 0x0009
> (http://lxr.free-electrons.com/source/drivers/input/mouse/psmouse.h#L86)
> - The TrackPoint should be added with product id 0x000A as on Linux
> and with the INPUT_PROP_POINTING_STICK Evdev property set
> - I think it would be better if the same Evdev device names were
> exposed as on Linux (for example "SynPS/2 Synaptics TouchPad"). Many
> scripts using xinput to change device properties depend on the Linux
> device names.
>
> I've added a patch and comments to https://reviews.freebsd.org/D10265 .

Patch looks good to me. I will merge it after small refactoring.

Thank you!

--
WBR
Vladimir Kondratyev

Anthony Jenkins

unread,
Jun 7, 2017, 7:36:18 PM6/7/17
to Jan Kokemüller, Vladimir Kondratyev, cur...@freebsd.org, freebsd...@freebsd.org
I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are
reporting multiple (wrong) events and some aren't emitting any events
(or they are, but they're NoSymbol):

- Down arrow: emits KeyPress for keycode 116 (Super_R), KeyRelease for
keycode 116, KeyRelease for keycode 104 (Down)
- Left arrow: emits KeyPress for keycode 113 (Alt_R), KeyPress for
keycode 100 (Left), KeyRelease for keycode 113, KeyRelease for keycode 100
- Volume up: emits KeyPress 123 (NoSymbol), KeyPress 176 (NoSymbol),
KeyRelease for same
- Volume down: emits KeyPress 122 (NoSymbol), KeyPress 174 (NoSymbol),
KeyRelease for same
- Volume mute toggle: emits KeyPress 121 (NoSymbol), KeyRelease 121
(NoSymbol), KeyRelease 140 (NoSymbol)
- Keypad end: emits KeyPress 115 (Super_L), KeyPress 103 (End),
KeyRelease for same

I'll attach the output of 'evdev -event keyboard' for everything but the
Keypad end key which I recently found.

/usr/local/etc/X11/xorg.conf.d/evdev1.conf:

Section "InputDevice"
Identifier "Keyboard0"
Driver "evdev"
Option "Device" "/dev/input/event1"
EndSection


dmesg | grep kbd:

[ajenkins@ajenkins-hplaptop ~]$ dmesg | grep kbd
kbd: new array size 4
kbd1 at kbdmux0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0067
atkbd: keyboard ID 0x41ab (2)
kbdc: RESET_KBD return code:00fa
kbdc: RESET_KBD status:00aa
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000
atkbd0: [GIANT-LOCKED]
random: harvesting attach, 8 bytes (4 bits) from atkbd0
random: harvesting attach, 8 bytes (4 bits) from atkbdc0
kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
psm0: <PS/2 Mouse> irq 12 on atkbdc0
atkbdc: atkbdc0 already exists; skipping it


/var/log/Xorg.0.log stuff:
[ 24.763] (**) Option "config_info" "udev:/dev/input/event1"
[ 24.763] (II) XINPUT: Adding extended input device "System keyboard
multiplexer" (type: KEYBOARD, id 7)
[ 24.763] (**) Option "xkb_rules" "evdev"
[ 24.839] (II) config/udev: Adding input device AT keyboard
(/dev/input/event2)
[ 24.839] (**) AT keyboard: Applying InputClass "evdev keyboard catchall"
[ 24.839] (II) Using input driver 'evdev' for 'AT keyboard'
[ 24.839] Option "_source" "server/udev"
[ 24.839] Option "name" "AT keyboard"
[ 24.839] Option "path" "/dev/input/event2"
[ 24.839] Option "device" "/dev/input/event2"
[ 24.839] Option "major" "0"
[ 24.839] Option "minor" "45"
[ 24.839] Option "driver" "evdev"
[ 24.839] Option "config_info" "udev:/dev/input/event2"
[ 24.839] (**) AT keyboard: always reports core events
[ 24.839] (**) evdev: AT keyboard: Device: "/dev/input/event2"
[ 24.839] (--) evdev: AT keyboard: Vendor 0x1 Product 0x1
[ 24.839] (--) evdev: AT keyboard: Found keys
[ 24.839] (II) evdev: AT keyboard: Configuring as keyboard
[ 24.839] (**) Option "config_info" "udev:/dev/input/event2"
[ 24.840] (II) XINPUT: Adding extended input device "AT keyboard"
(type: KEYBOARD, id 8)
[ 24.840] (**) Option "xkb_rules" "evdev"
[ 24.840] (II) XKB: Reusing cached keymap
[ 24.840] (II) config/udev: Adding input device Synaptics Touchpad
(/dev/input/event3)
[ 24.841] (**) Synaptics Touchpad: Applying InputClass "evdev pointer
catchall"
[ 24.841] (**) Synaptics Touchpad: Applying InputClass "evdev
touchpad catchall"
[ 24.841] (**) Synaptics Touchpad: Applying InputClass "touchpad
catchall"
[ 24.841] (**) Synaptics Touchpad: Applying InputClass "Default
clickpad buttons"
[ 24.841] (II) LoadModule: "synaptics"
[ 24.841] (II) Loading /usr/local/lib/xorg/modules/input/synaptics_drv.so
[ 24.842] (II) Module synaptics: vendor="X.Org Foundation"
[ 24.842] compiled for 1.19.3, module version = 1.9.0
[ 24.842] Module class: X.Org XInput Driver
[ 24.843] ABI class: X.Org XInput driver, version 24.1
[ 24.843] (II) Using input driver 'synaptics' for 'Synaptics Touchpad'
[ 24.843] Option "_source" "server/udev"
[ 24.843] Option "name" "Synaptics Touchpad"
[ 24.843] Option "path" "/dev/input/event3"
[ 24.843] Option "device" "/dev/input/event3"
[ 24.843] Option "major" "0"
[ 24.843] Option "minor" "50"
[ 24.843] Option "driver" "synaptics"


Not sure what else to add. I have applied the patches from this email
thread. Any ideas?

Thanks in advance,
Anthony Jenkins
Hi Vladimir and Jan,

Thanks for the patches! I'm having some issues with 3 patches from this
thread:
-
https://reviews.freebsd.org/file/data/pqjvpuhwfgsu5nnamibg/PHID-FILE-uuyjx66blb344hre3nc2/D10207.vson.id27478.whitespaceignore-most.diff
These may or may not have anything to do with the patches...

1. For some reason Xorg keyboard driver isn't getting some key events,
or had shuffled them. When I first applied the patches, X thought my
<Down> arrow was <KP_Enter> and <KP_Enter> was something else. At some
point that behavior changed and <Down> worked, but <KP_Divide> emits
<KP_Multiply> and <KP_Multiply> doesn't emit anything. Rebooting didn't
change the new behavior, and I don't know what caused it to change.
Switching to a console, I get the expected characters/actions when
pressing these keys.

2. My Synaptics clickpad (and the pointer in general) freeze for several
seconds, although it hasn't done it lately. When a freeze occurs (in X
windows), other GUI processes don't seem to be affected. If I have
another pointer device attached (e.g. USB mouse), it also doesn't move
the pointer during the freeze.

Here's my config:
keyboard_issue.xev.txt

Jan Kokemüller

unread,
Jun 8, 2017, 1:35:24 AM6/8/17
to Anthony Jenkins, Vladimir Kondratyev, cur...@freebsd.org, freebsd...@freebsd.org
Hi,

On 08.06.2017 01:32, Anthony Jenkins wrote:
> I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are
> reporting multiple (wrong) events and some aren't emitting any events
> (or they are, but they're NoSymbol):

It is true that the Evdev drivers emit other keycodes compared to the
'legacy' drivers.
I'm using this command to specify the correct mapping ("-rules evdev" is
the important part):

setxkbmap -rules evdev -layout us -variant altgr-intl -option ctrl:nocaps,compose:menu

I'm not sure if this is enough for KDE. I see 'Option "xkb_rules"
"evdev"' in your log, so the correct mapping should already be used?
Maybe KDE reverts this somehow. FWIW, when I press the arrow keys in xev
I see the following (correct) output:


KeyPress event, serial 33, synthetic NO, window 0x4200001,
root 0xc2, subw 0x0, time 820816, (158,533), root:(960,556),
state 0x0, keycode 113 (keysym 0xff51, Left), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x4200001,
root 0xc2, subw 0x0, time 820911, (158,533), root:(960,556),
state 0x0, keycode 113 (keysym 0xff51, Left), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x4200001,
root 0xc2, subw 0x0, time 821494, (158,533), root:(960,556),
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x4200001,
root 0xc2, subw 0x0, time 821565, (158,533), root:(960,556),
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

Vladimir Kondratyev

unread,
Jun 8, 2017, 7:08:37 AM6/8/17
to Anthony Jenkins, Jan Kokemüller, cur...@freebsd.org, freebsd...@freebsd.org
On 08.06.2017 02:32, Anthony Jenkins wrote:
> I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are
> reporting multiple (wrong) events and some aren't emitting any events
> (or they are, but they're NoSymbol):
You can test evdev directly w/o Xserver started by running of
evemu-record utility from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218383 PR to see if
events are matching keys or not.
Note: depending on kern.evdev.rcpt_mask sysctl value only one of kdbmux
or AT keyboard devices should emit events. Not bother!
> Section "InputDevice"
> Identifier "Keyboard0"
> Driver "evdev"
> Option "Device" "/dev/input/event1"
> EndSection
This lines are not required usually if you are using devd or udev
autoconfiguration backends. Moreover they can do a harm.
Could you compare input device lists from xinput command output with
evemu-record output?
They should be the same except "Virtual core XTEST" entries. If they are
not, that could be the culprit. It is possinle that
Xorg receives one key event several times. In that case try to uninstall
xf86-input-keyboard and restart Xserver than.

> 2. My Synaptics clickpad (and the pointer in general) freeze for several
> seconds, although it hasn't done it lately. When a freeze occurs (in X
> windows), other GUI processes don't seem to be affected. If I have
> another pointer device attached (e.g. USB mouse), it also doesn't move
> the pointer during the freeze.
Try run evemu-record on synaptics device node to see if you are
receiving events from touchpad during freezes or not

Jonathan Anderson

unread,
Jun 9, 2017, 8:58:12 AM6/9/17
to freebsd...@freebsd.org, vlad...@kondratyev.su
Hi Vladimir,

On 04/16/17 15:18, Vladimir Kondratyev wrote:
> Following patch [1] bring in multitouch EVDEV support for Synaptics
> and Elan PS/2
> touchpads found in many laptops. (And for generic relative PS/2 mices
> as well).
> This allows to replace our limited in-kernel gesture processor with
> full-blown
> one from xf86-input-synaptics or xf86-input-libinput driver and makes
> Synaptics and Elan PS/2 touchpad support to be mostly on par with Linux

Thanks very much... I've been using your patch for awhile with my
Synaptics touchpad and it's lovely to have two-finger scrolling that
works properly! I did need to massage the patch to make it apply on
drm-next:
https://github.com/trombonehero/freebsd/commit/3d74a33a1bc709d289216cb946744afecb70f6b5

Sometimes I experience dropped touchpad events, particularly when the
system is busy and my wi-fi is being reconfigured. Is there anything I
can do to help debug this?


Jon

--
jona...@FreeBSD.org

Vladimir Kondratyev

unread,
Jun 10, 2017, 6:10:14 AM6/10/17
to Jonathan Anderson, freebsd...@freebsd.org
On 09.06.2017 15:57, Jonathan Anderson wrote:
> Hi Vladimir,
>
> Thanks very much... I've been using your patch for awhile with my
> Synaptics touchpad and it's lovely to have two-finger scrolling that
> works properly! I did need to massage the patch to make it apply on
> drm-next:
> https://github.com/trombonehero/freebsd/commit/3d74a33a1bc709d289216cb946744afecb70f6b5
>
>
The patch is commited to CURRENT already so you don`t need apply extra
patches anymore. Part of initial patch that I can find under your link
has not been committed as it can trigger deadlock on KDB entering.

> Sometimes I experience dropped touchpad events, particularly when the
> system is busy and my wi-fi is being reconfigured. Is there anything I
> can do to help debug this?
Are you observing SYN_DROPPED events in evemu-record output?
If so run it under "nice -n -20"
If SYN_DROPPED still persists, add debug.psm.loglevel=5 to
/boot/loader.conf, reboot and send me content of /var/log/messages. Only
"dropped touch" part of log is needed.
Event dropping occurs when kernel writes events faster than user can
read, so usually it is a user-land problem.
Reply all
Reply to author
Forward
0 new messages