ondemand glitch

[netsocket]

Well, a brief attempt to get an xorg.conf.d rule to handle the error didn't help (though maybe I'll pick it up again at some point).
What did work in a somewhat less ugly way than a sleep was adding  to .mouse_config called by 98-touch.rules
`(udevadm settle; xinput etc)&`
where the backgrounding gets us off the `udevadm trigger` thread. No sudo needed. If not ideal, at least it scratches the itch.

Thanks for the help.

[Rich]

Hi netsocket
So you changed 98-touch.rules to:

Code: [Select]

RUN+="/b in/sh -c 'DISPLAY=:0 /home/tc/.mouse_config' &"Not sure of the placement for  &

And placed  udevadm settle  at the beginning of  .mouse_config ?

[Rich]

Hi netsocket
Turns out a script can put itself into the background:
https://unix.stackexchange.com/a/403936
If you read the comments, there is no reason to add a trailing & to the command.

So if the first 2 commands in  .mouse_config  are:

(kill -STOP $$; kill -CONT $$)
udevadm settle

The first line places the script in the background so it doesn't block udev from continuing.
The second line blocks the script until udev has finished handling events.

[netsocket]

Is that slick, or what?
I was not clear, - I just changed .mouse_config to background the udevadm settle call. The mechanism you give is obviously much nicer.

I do reflect however that that there is a security hole I hadn't thought through. .mouse_config on the udevd thread is running at elevated privilege so should be owned by the system. So maybe 98-touch.rules could invoke a separate version of the script that resides somewhere in the udev files. Or possibly a user thread could wait on a signal from 98-touch.rules, wake up and do the udevadm settle etc, which is more complex but localizes user configuration twiddling.

[Rich]

Hi netsocket

... I do reflect however that that there is a security hole I hadn't thought through. .mouse_config on the udevd thread is running at elevated privilege so should be owned by the system. ...

Life is full of compromises. OK, so you change ownership to  root:root.  Now it's owned by the system.
Here are some new security holes:

Code: [Select]

sudo editor /home/tc/.mouse_configor:

Code: [Select]

sudo cp Evil_Malicious_File /home/tc/.mouse_config

... Or possibly a user thread could wait on a signal from 98-touch.rules, wake up and do the udevadm settle etc ...

Sounds like an unnecessary complication. The  , RUN+=" ... "  in the  .rules  file is the signal.

[netsocket]

True enough. Thanks one more time for all your attention.

[Rich]

Hi netsocket
You are welcome.

[netsocket]

Hi Rich, -

One last word on this. The proposed solution was pretty effective. But when I implemented it in a faster environment there was still an occasional loss of touchpad configuration. Presumably there's a window amidst processing udevadm requests where the queue is empty so `udevadm settle` completes and the touchpad is reconfigured, and then more requests arrive.

So I believe the proper fix is one you suggested earlier. The touchpad stanza in xorg.conf.d/40-libinput.conf should be, in order to enable tapping and retain it through udevadm trigger events:
Section "InputClass"
        Identifier "libinput touchpad catchall"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
   Option "Tapping" "True"
   Option "TappingDrag" "True"
        Driver "libinput"
EndSection

After your initial suggestion I had tried this, but using the corresponding option names emitted by libinput, - which unfortunately are wrong. xorg.conf.d has its own namespace. Well, never assume.

Anyway, this is stable across triggers. I don't consider it lost effort to have pursued the alternate approach however, since it's interesting and maybe in some circumstances useful to have a window into what udev and dbus are up to.

Regards
netsocket

[Rich]

Hi netsocket
Thanks for the update and for sharing your solution.

Just to satisfy my curiosity and to see if I missed anything, I'd like you to do the following:

Download  RecordScan.sh  from here and make it executable:
http://forum.tinycorelinux.net/index.php/topic,25828.msg165650.html#msg165650

Run the following commands:

Code: [Select]

udevadm monitor --property > filename.txt &
sudo udevadm trigger && ssleep 10
fg
Ctrl-CForum error, leave out the extra  s  in  sleep.

Now run this command to create a file that only contains events for one device:

Code: [Select]

./RecordScan.sh filename.txt '6cb|6CB' 'ce26|CE26'This will find (upper OR lowercase VID) AND (upper OR lowercase PID) events for your touchpad/mouse
and save them to  RecordScan.txt.  That file should be small enough to attach to your next post.

[netsocket]

Hi Rich, -

Sure. Would you like me to back out my xorg.conf change to run the test?

[Rich]

Hi netsocket
I don't think that's necessary. It shouldn't effect which events get triggered.

[netsocket]

OK. Done -

[Rich]

Hi netsocket
Thanks, the file with all of the extra noise filtered out is much easier to deal with. I don't see any
issues there.

There's only one event that meets the requirements to launch the script, and no other touchpad
events that occur after that. In other words, I don't know why that could have happened.

[netsocket]

My thought is that the problem is complex events. The udevadm settle in .mouse_config handles a single udevadm trigger, so the touchpad reconfiguration is stable. When something like gvim is launched, however, a list of dependencies gets loaded as well. (Here I'm gonna wave my hands a little.) So multiple events are being queued, and since udevd is multi-process the udevadm settle in one process sees a drained queue while another process is adding events before the touchpad reconfiguration completes. That's why, clunky though it was, my early solution of putting a sleep in between ondemand invocation and touchpad reconfiguration seemed to work. If you wait long enough udevd will actually be done. If you're lucky.

It's a story, though admittedly large parts are made up.

[Rich]

Hi netsocket
OK, let's say that is what is happening. The touchpad is basically treated as 2 devices:
first mouse0

Code: [Select]

UDEV  [54423.839453] change   /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-DELL0A7D:00/0018:06CB:CE26.0001/input/input6/mouse0 (input)and then mouse1

Code: [Select]

UDEV  [54423.839601] change   /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-DELL0A7D:00/0018:06CB:CE26.0001/input/input7/mouse1 (input)
The script will run every time the rules match for mouse1 but not for mouse0.

So if a mouse0 event can also screw up the touchpad and it occurs after the mouse1 event, that would get missed.

If this is reproducible in the faster environment and you want to try it, I attached a rules file that tests for both devices.