ondemand glitch

[netsocket]

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.

[Rich]

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:

Code: [Select]

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

[netsocket]

Right. It turns out to be the udevadm call.

[netsocket]

FWIW, perhaps this is the same sort of thing as 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.

[Rich]

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:

Code: [Select]

cat /proc/bus/input/devices > BusInputDevices.txtand attach  BusInputDevices.txt  to your next post we can figure it out from that.

[netsocket]

Thanks, looks hopeful. It's Vendor=06cb Product=ce26
"DELL0A7D:00 06CB:CE26"

[netsocket]

... same id, by the way, as a mouse, but "Handlers=mouse1 event5"

[Rich]

Hi netsocket
Save the attached  98-touch.rules  file to  /etc/udev/rules.d/
Run:

Code: [Select]

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

[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:

Code: [Select]

udevadm monitor --property > touch.txt
Run this in the second terminal:

Code: [Select]

sudo udevadm trigger
Wait 10 seconds.
Press  Ctrl-C  in the first terminal.
Attach  touch.txt  to your next post.

[netsocket]

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.

[Rich]

Hi netsocket
I think this version should work.

Save the attached  98-touch.rules  file to  /etc/udev/rules.d/
Run:

Code: [Select]

sudo udevadm control --reload-rules
See if running  sudo udevadm trigger  still messes up your touchpad.

[netsocket]

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

[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.

[Rich]

Hi netsocket
Maybe one of Xorgs config files is interfering:

Code: [Select]

+[   529.282] (**) DELL0A7D:00 06CB:CE26 Touchpad: Applying InputClass "libinput touchpad catchall"

[netsocket]

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