[SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

jeroentbt · 2015-07-20 12:08:08

Hey all,

This is an udev rule with which I set trackpoint speed and sensitivity:

$ cat /etc/udev/rules.d/10-trackpoint.rules.backup 
# set trackpoint sensitivity and speed [1..255]
SUBSYSTEM=="serio", DRIVERS=="psmouse", WAIT_FOR="/sys/devices/platform/i8042/serio1/serio2/speed", WAIT_FOR="/sys/devices/platform/i8042/serio1/serio2/sensitivity", ATTR{sensitivity}="255", ATTR{speed}="180"

However, since systemd v222, WAIT_FOR(_SYSFS) has been deprecated.
Which I noticed by doing an "udevadm test /sys/devices/platform/i8042/serio1/serio2".

When I remove the WAIT_FOR key I get the same error for which I put it in in the first place:

Jul 20 13:34:02 zechs systemd-udevd[241]: error opening ATTR{/sys/devices/platform/i8042/serio1/serio2/sensitivity} for writing: Permission denied
Jul 20 13:34:02 zechs systemd-udevd[241]: error opening ATTR{/sys/devices/platform/i8042/serio1/serio2/speed} for writing: Permission denied

Looks like sysfs is not ready when the rule is fired.

Any ideas on how I could fix this?

Last edited by jeroentbt (2015-09-15 13:50:47)

SammysHP · 2015-07-20 13:08:20

The source of all this pain: https://github.com/systemd/systemd/comm … aca90fbb2f

Bug must be somewhere in linux/drivers/input/mouse/trackpoint.c.

Solution: Don't know. Maybe a workaround with TAG+="systemd" and a systemd.device unit.

edit: Something like this: https://bbs.archlinux.org/viewtopic.php?id=165213

edit2: I tested a service unit together with a device unit. It works, but slows down booting somehow. The boot hangs for some seconds, independent of the sleep time in the service.

Last edited by SammysHP (2015-07-20 15:13:57)

fgrsnau · 2015-07-20 17:51:45

I’m also affected by this problem. Of course, the WAIT_FOR key is not a clean solution. Hopefully this kernel bugs get’s finally fixed. It might get a lot of traction. :-)

@SammysHP: Is tagging even possible? My device path changes sometimes. Even worse: Sometimes I need to manually run “modprobe -r psmouse; modprobe psmouse”, because the trackpoint is not working. Without a stable device path I see no possibility to let a systemd service unit depend on the proper systemd device unit.

It might be possible to use a udev RUN hook in the meantime. The script would need to wait a short period of time before setting the attributes. I have not tested it yet, though.

SammysHP · 2015-07-20 19:35:46

For me the path is absolutely stable and the trackpoint works always. The problem with RUN is that it will block udev for that time and udev tracks every child processes (even detached ones), so you can't fork/detach a subshell. In my tests I needed to wait 5-7 seconds sometimes! Not sure why the attributes are added so late.

edit: Actually this issue was called a bug years ago: http://www.thinkwiki.org/wiki/How_to_co … d_Speed.29
There's also a script that should work without the WAIT_FOR, but I don't know if that's really the case. That's more or less exactly the same what the service unit would do – and it fails without a "sleep 7".

Last edited by SammysHP (2015-07-20 19:50:42)

SammysHP · 2015-07-20 20:36:39

Update from the systemd team: https://github.com/systemd/systemd/comm … t-12259682

SammysHP · 2015-07-22 13:56:59

Another update: psmouse is not the only driver with this issue. There is a patch on the ML and Greg mentions our issue: https://lkml.org/lkml/2015/7/20/657 (best to read the whole thread)

mhshams · 2015-07-22 20:06:11

I was also affected by this issue and this page in ThinkWiki helped me:

Check for this:

To avoid the wait you can also listen for the Trackpoint input device to appear and then run a script to set the parameters
SUBSYSTEM=="input", ATTR{name}=="*TrackPoint*", RUN+="/etc/conf.d/trackpoint"
An example /etc/conf.d/trackpoint would be
#! /bin/bash
## Trackpoint settings
# When run from a udev rule, DEVPATH should be set
if [ ! -z $DEVPATH ] ; then
TPDEV=/sys/$( echo "$DEVPATH" | sed 's/\/input\/input[0-9]*//' )
else
# Otherwise just look in /sys/
TPDEV=$(find /sys/devices/platform/i8042 -name name | xargs grep -Fl TrackPoint | sed 's/\/input\/input[0-9]*\/name$//')
fi
# http://www.thinkwiki.org/wiki/How_to_co … TrackPoint
# http://wwwcssrv.almaden.ibm.com/trackpo … t3eext.pdf
#------------------------------------------------------------
if [ -d "$TPDEV" ]; then
echo "Configuring Trackpoint"
echo -n 255 > $TPDEV/sensitivity # Integer 128 Sensitivity
echo -n 110 > $TPDEV/speed # Integer 97 Cursor speed
echo -n 4 > $TPDEV/inertia # Integer 6 Negative intertia
else
echo "Couldn't find trackpoint device $TPDEV"
fi

SammysHP · 2015-07-22 21:00:48

Discussion with Lennart started. Let the war begin – urgh, I'm out.
https://github.com/systemd/systemd/comm … t-12306597

@mhshams
It might work, but it's ugly as hell. We have systemd, systemd will save the world. Uhm… I keep believing.¹

________
¹ For real. I like most of the concepts of systemd and I wonder why there's this sluggish behavior with my service.

SammysHP · 2015-07-23 09:05:58

@mhshams
Tested the script and it does not work. So for now I block udev until these damn attributes are there.

#!/bin/bash

# When run from a udev rule, DEVPATH should be set
if [ ! -z $DEVPATH ] ; then
    TPDEV=/sys/$( echo "$DEVPATH" | sed 's/\/input\/input[0-9]*//' )
else
# Otherwise just look in /sys/
    TPDEV=$(find /sys/devices/platform/i8042 -name name | xargs grep -Fl TrackPoint | sed 's/\/input\/input[0-9]*\/name$//')
fi

if [ -d "$TPDEV" ]; then
    for i in {0..10}; do
        if [ -f "$TPDEV/speed" ]; then
            echo "Configuring Trackpoint"
            echo -n 200     > $TPDEV/sensitivity
            echo -n 130     > $TPDEV/speed
            echo -n 20      > $TPDEV/drift_time

            exit 0;
        fi
        sleep 1
    done
    echo "Couldn't find attributes"
    exit 1
else
    echo "Couldn't find trackpoint device $TPDEV"
    exit 2
fi

It usually takes 6 seconds.

jakob · 2015-08-18 10:46:13

For the time being, I left the udev rule in place, removed the WAIT_FOR argument and created a service file that triggers udev again at a later point in time, i.e. at multi-user.target. On a few reboots now, this seems to do the trick:

[Unit]
Description=Activate udev rule 10-thinkpad.rules

[Service]
Type=oneshot
ExecStart=/usr/bin/udevadm trigger --subsystem-match=serio
ExecStartPost=/usr/bin/udevadm info -a -p /sys/devices/platform/i8042/serio1/serio2/

[Install]
WantedBy=multi-user.target

Put this into a file called /etc/systemd/system/press-to-select.service and activate it by

sudo systemctl enable press-to-select.service

and you should be set.

For the record, here is my /etc/udev/rules.d/10-trackpoint.rules file:

KERNEL=="serio2", SUBSYSTEM=="serio", DRIVER=="psmouse", ATTR{press_to_select}="1", ATTR{ztime}="15", ATTR{sensitivity}="180"

edit: I refined the service file a bit in order to trigger udev for serio subsystem only.

Last edited by jakob (2015-08-18 11:22:28)

jeroentbt · 2015-09-14 22:47:57

Nice fix Jakob!

My conputer was however still booting up too fast for the trackpoint to have advertised it's attributes so I added

ExecStartPre=/usr/bin/sleep 5

to the [Service] part of the unit file.

This does not seem to negatively affect the boot speed of my computer (although I must admit that it takes a while to type my password when ssh-agent launches on startup.

Judging from the PID's, enough stuff gets done while wainting for sleep to finish.

$ sudo systemctl status trackpoint-reload-udev.service 
● trackpoint-reload-udev.service - Activate udev rule 10-thinkpad.rules
   Loaded: loaded (/etc/systemd/system/trackpoint-reload-udev.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2015-09-15 00:30:22 CEST; 11min ago
  Process: 613 ExecStartPost=/usr/bin/udevadm info -a -p /sys/devices/platform/i8042/serio1/serio2/ (code=exited, status=0/SUCCESS)
  Process: 609 ExecStart=/usr/bin/udevadm trigger --subsystem-match=serio (code=exited, status=0/SUCCESS)
  Process: 417 ExecStartPre=/usr/bin/sleep 5 (code=exited, status=0/SUCCESS)
 Main PID: 609 (code=exited, status=0/SUCCESS)

Sep 15 00:30:22 zechs udevadm[613]: looking at parent device '/devices/platform/i8042':
Sep 15 00:30:22 zechs udevadm[613]: KERNELS=="i8042"
Sep 15 00:30:22 zechs udevadm[613]: SUBSYSTEMS=="platform"
Sep 15 00:30:22 zechs udevadm[613]: DRIVERS=="i8042"
Sep 15 00:30:22 zechs udevadm[613]: ATTRS{driver_override}=="(null)"
Sep 15 00:30:22 zechs udevadm[613]: looking at parent device '/devices/platform':
Sep 15 00:30:22 zechs udevadm[613]: KERNELS=="platform"
Sep 15 00:30:22 zechs udevadm[613]: SUBSYSTEMS==""
Sep 15 00:30:22 zechs udevadm[613]: DRIVERS==""
Sep 15 00:30:22 zechs systemd[1]: Started Activate udev rule 10-thinkpad.rules.

One question though. Why are you running that ExecStartPost command?

One happy camper here

Last edited by jeroentbt (2015-09-14 22:48:25)

jakob · 2015-09-15 10:53:03

jeroentbt wrote:

Nice fix Jakob!
My conputer was however still booting up too fast for the trackpoint to have advertised it's attributes so I added
ExecStartPre=/usr/bin/sleep 5
to the [Service] part of the unit file.
This does not seem to negatively affect the boot speed of my computer (although I must admit that it takes a while to type my password when ssh-agent launches on startup.

Hey jeroen, thanks for your addition! I also sometimes notice that the service gets executed normally while at other times it doesn't. But as I use my thinkpad in the docking station most of the time with an external keyboard and mouse, I haven't been forced to fix this properly yet. Your solution seems like an elegant hack.

jeroentbt wrote:

One question though. Why are you running that ExecStartPost command?

This is merely to directly have the result of ExecStart as output in journalctl and directly be able to see ther whether it worked or not.

jeroentbt · 2015-09-15 13:50:11

Thank you for that clarification.

Cheers,
Jeroen

qrosh · 2015-10-07 12:23:57

Hello,

I have the following udev rule in my 10-trackpoint.rule

 ACTION=="add",SUBSYSTEM=="input",ATTR{name}=="TPPS/2 IBM TrackPoint",ATTR{device/sensitivity}="200",ATTR{device/speed}="120"

and everything works like a charm.

Hope this works for you to

jakob · 2015-10-14 15:01:05

qrosh wrote:

Hello,
I have the following udev rule in my 10-trackpoint.rule
 ACTION=="add",SUBSYSTEM=="input",ATTR{name}=="TPPS/2 IBM TrackPoint",ATTR{device/sensitivity}="200",ATTR{device/speed}="120"

Thanks for sharing your idea!

However, this does not apply at boot time on my system. Anybody else having different results?

jeroentbt · 2015-10-25 18:30:13

jakob wrote:

this does not apply at boot time on my system. Anybody else having different results?

Same here. It looks like a different tackpoint model alltogether (T420 here).

The problem also is not that this would not apply at boot time, it's more that the trackpoint is not fully ready when it gets advertised in sysfs.

wrm · 2015-11-17 13:15:52

jeroentbt wrote:

jakob wrote:
this does not apply at boot time on my system. Anybody else having different results?
Same here. It looks like a different tackpoint model alltogether (T420 here).
The problem also is not that this would not apply at boot time, it's more that the trackpoint is not fully ready when it gets advertised in sysfs.

What worked for me:

ACTION=="add",DEVPATH=="/devices/platform/i8042/serio4/serio5",ATTR{sensitivity}="128",ATTR{speed}="200"

Hope this helps. Make sure DEVPATH leads to your trackpoint device.

Arch Linux

#1 2015-07-20 12:08:08

[SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#2 2015-07-20 13:08:20

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#3 2015-07-20 17:51:45

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#4 2015-07-20 19:35:46

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#5 2015-07-20 20:36:39

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#6 2015-07-22 13:56:59

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#7 2015-07-22 20:06:11

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#8 2015-07-22 21:00:48

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#9 2015-07-23 09:05:58

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#10 2015-08-18 10:46:13

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#11 2015-09-14 22:47:57

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#12 2015-09-15 10:53:03

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#13 2015-09-15 13:50:11

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#14 2015-10-07 12:23:57

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#15 2015-10-14 15:01:05

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#16 2015-10-25 18:30:13

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

#17 2015-11-17 13:15:52

Re: [SOLVED] [HACK] udev WAIT_FOR_SYSFS deprecated - but I think I need it

Board footer