Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: netsocket on June 04, 2022, 04:23:42 AM
-
A minor issue:
I run corepure64 and jwm on devices with a touchpad. I'm currently running v13.1 but the following was true back to v12 at least:
When I initially invoke some (perhaps not all) ondemand modules for example gvim, the module successfully installs, but there is a brief screen flash and freeze, after which the touchpad has lost its configuration. In particular, tapping is no longer enabled. If I manually reinvoke /home/tc/.mouse_config (which in my case just uses xinput to enable tapping) everything works fine.
As a workaround, I've added a .mouse_config invocation after the ondemand invocation in .jwmrc_ondemand, and that works ok.
So, not a big deal. Just wondered what might be going on. I don't see a smoking gun in /usr/bin/ondemand.
-
Hi netsocket
... I don't see a smoking gun in /usr/bin/ondemand.
I think the smoking gun may be in /usr/bin/tce-load which /usr/bin/ondemand calls.
I think it may be these two commands causing it:
sudo /sbin/depmod -a
sudo /sbin/udevadm triggerTry running them and see if they trigger the problem.
Those lines get run if the MODULES variable is set to TRUE. That gets done by a find command searching
for the word modules in any of the extensions directory names.
At least one of the (indirect) dependencies of gvim.tcz satisfies that requirement:
http://www.tinycorelinux.net/13.x/x86_64/tcz/at-spi2-atk.tcz.list
-
Right. It turns out to be the udevadm call.
-
FWIW, perhaps this is the same sort of thing as https://bugs.kde.org/show_bug.cgi?id=414559 (https://bugs.kde.org/show_bug.cgi?id=414559)
Maybe the udevadm trigger invokes a default rule for the touchpad that resets it, and an explicit rule might disarm it, though that's an end of the universe I'd have to study for a while. If I come up with anything I'll add a note.
-
Hi netsocket
... Maybe the udevadm trigger invokes a default rule for the touchpad that resets it, ...
Possible, or maybe there are no rules for it and udevadm trigger itself resets the hardware.
If you know the vendor ID and the product ID of your touchpad we might be able to adapt the rules file found here
to run your /home/tc/.mouse_config script when needed:
http://forum.tinycorelinux.net/index.php/topic,25771.msg165391.html#msg165391
You should be able to find the vendor ID and the product ID of your touchpad using either lsusb or lspci.
Or if you run:
cat /proc/bus/input/devices > BusInputDevices.txtand attach BusInputDevices.txt to your next post we can figure it out from that.
-
Thanks, looks hopeful. It's Vendor=06cb Product=ce26
"DELL0A7D:00 06CB:CE26"
-
... same id, by the way, as a mouse, but "Handlers=mouse1 event5"
-
Hi netsocket
Save the attached 98-touch.rules file to /etc/udev/rules.d/
Run:
sudo udevadm control --reload-rules
See if running sudo /sbin/udevadm trigger still messes up your touchpad.
[EDIT]: Attachment removed. See reply #10 for corrected version. Rich
-
Hi netsocket
If it does not appear to work correctly, I will need some more information.
Open 2 terminals.
Run this in the first terminal:
udevadm monitor --property > touch.txt
Run this in the second terminal:
sudo udevadm trigger
Wait 10 seconds.
Press Ctrl-C in the first terminal.
Attach touch.txt to your next post.
-
Hi Rich,
Thanks for the file. It did not however change behavior.
I did as you suggested. I figured you didn't need to see extraneous touchpad events, so I slept the `udevadm trigger` a few seconds while I navigated to the other terminal. Also, I left 99-touch.rules in /etc/udev/rules.d
touch.txt is attached, - actually touch.txt.gz, since even after editing out some heading and trailing chatter about the power supply, the file was longer than the max size permitted. Let me know if the liberties I took were counterproductive.
I appreciate the help. As I say, this is not a problematic bug but one I've noticed for quite a while, and it's nice to get some insight.
-
Hi netsocket
I think this version should work.
Save the attached 98-touch.rules file to /etc/udev/rules.d/
Run:
sudo udevadm control --reload-rules
See if running sudo udevadm trigger still messes up your touchpad.
-
Hi Rich,-
Thanks. No change in behavior. I captured and attached the diff in Xorg.0.log after udevadm trigger. Looks as if the whole input side of the server undergoes reconfiguration.
Regards,
netsocket
-
... Maybe if instead of an immediate call to .mouse_config we inserted a short sleep (admittedly a hack) or some test of whether the configuration has settled? I changed .mouse_config to do something similar. I verified that .mouse_config is actually invoked after `udevadm trigger`, but apparently there's a race, and a reset of the touchpad happens after 98-touch.rules. Just hacking a short sleep prior to the .mouse_config xinput invocation doesn't work. Backgrounding a sleep and then the invocation does.
-
Hi netsocket
Maybe one of Xorgs config files is interfering:
+[ 529.282] (**) DELL0A7D:00 06CB:CE26 Touchpad: Applying InputClass "libinput touchpad catchall"
-
Hi RIch, -
I think that's probably the ticket. Now that I think of it, the touchpad configuration is almost ok - I'm happy enough with it after enabling tapping. So rather than adding a .mouse_config to finish up, I should chase down how to get the Xorg/libinput autoconf to do it for me (maybe still by a callout to .mouse_config, but on the thread of the server). Then the trigger would be harmless. <slaps forehead>
Regards,
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.
-
Hi netsocket
So you changed 98-touch.rules to:
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 ?
-
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.
-
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.
-
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:
sudo editor /home/tc/.mouse_configor:
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.
-
True enough. Thanks one more time for all your attention.
-
Hi netsocket
You are welcome. :)
-
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
-
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:
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:
./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.
-
Hi Rich, -
Sure. Would you like me to back out my xorg.conf change to run the test?
-
Hi netsocket
I don't think that's necessary. It shouldn't effect which events get triggered.
-
OK. Done -
-
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.
-
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.
-
Hi netsocket
OK, let's say that is what is happening. The touchpad is basically treated as 2 devices:
first mouse0
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
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.