Tap to click doesn't work in chroot before switching back to Chrome OS

[thieman]

Using the latest xfce target as of March 2 on an ARM Samsung Chromebook. Upon entering the chroot, tap to click doesn't work in xfce. If I switch back to Chrome OS, then back to xfce, tap to click works.

[trebinor]

I can confirm this one. Happened for me in xfce and lxde on ARM Samsung.

[jpl888]

@dnschneid I don't think this is the same issue as #28, no mouse-clicks, left or right, will work for me the first time I switch into the chroot. If it's any help, this only started appearing for me after updating to the latest crouton as per the other thread.

[grdoba]

This issue was also mentioned in #27. I can also add, if I start the chroot in the background like sudo startxfce4 -b the tapping in xfce does not work at all. The cycling between the chroot and the chrome os does not help in this case.

[ghost]

I have done some testing and can confirm this to be an issue on xfce4, unity and lxde so it is not DE related. Clicking itself works, but you have to click all the way through. Tap to click does not work.

[tedm]

I'd like to try to write a temporary fix for this, what I'm considering is in either a c program or script, going to chromos desktop mode, then doing a trackpad motion/gesture with a command, then putting that script or program as a cron job running every minute or two or able to be called upon demand in the path, saving the 4 keystrokes and trackpad motion, and 4 keystrokes back?

Does this sound doable?

[dnschneid]

I think the fix lies in a tweak to the ratpoison config that lies in your chroot's /usr/local/bin/croutonwm. I just haven't had time to play around to figure out what it needs.

[tedm]

the following sequence seems to work: kill ratpoison pid, restart croutonwm.

just killing ratpoison enables tap to click, but unable to hot key back to chromeos, ratpoison doesn't seem to want to restart easily by itself, but croutonwm brings it back up with the ability to hot-key back.

I think ratpoison and/or croutonwm need to initialize or set the trackpad state and maybe a position, as when hot-keying into the chroot from a non mouse enabled window (crosh) seems to more often leave one in the non tap to click mode.

[dnschneid]

Ted, that is a really good observation. Try this: add a sleep before launching the chroot: sleep 5; sudo startxfce4, and while it's sleeping, switch to a tab that has normal mouse motion or whatever. See if tap-to-click works once xfce starts.

[tedm]

Tried the sleep 5, it still intermittently loses tap to click in the chroot. I also observed this though, by hot keying from the chroot into a full screen crosh window, and not doing any trackpad activity, just typing in the crosh window, then hot keying back to the chroot, you have almost surely lost tap to click.

Can regain, by hot keying back to chromeos and moving mouse at top tabs area or borders of crosh window, then is active back in chroot.

[tedm]

tr.sh in /usr/local/bin - chmod to executable, owner should be user

!/bin/bash

kill $(pgrep ratpoison) /usr/local/bin/croutonwm

[dnschneid]

You shouldn't need to run either command as root. Still looking into a proper solution.

[tedm]

update - the script above tr.sh is probably not a good idea. Each time it is run, it adds a process of croutonwheel and possibly other things. At one point, I couldn't get a terminal window to overlap on top of a Chromium full screen window, but I am not sure it was the script's fault. Am running beta channel on chromeos, 27.xx - but it does bring back tap to click fast ;)

[JEBean]

The script is a good temporary fix, and in my experience needs executing only once on initial entry (I added it to the startups) and seems to have no detrimental effects when used that way.

I never have a working touch to click on entry to the xfce4 chroot and my manual fix - switch to crosh, two-finger tap anywhere to invoke context menu, switch back to xfce4 - worked consistently but was becoming very irritating. The little "autostart" script removes the irritation :-)

[tedm]

a startup script, where you are setting other variables like LC_ALL, would be a good place for it, but as David has mentioned, a proper fix is probably going to be something very simple in courtonwm/ratpoison, which I might try to dig in today for fun and learning. For those switching back to chromeos and back to enable tap to click, just swipe on a mouse active portion of the screen, not on a crosh terminal.

[tedm]

typing the following also re-enables tap to click, but I'm not sure why, the flash is similar to killing ratpoison and restarting with croutonwm - in a terminal as root, type

less /etc/crouton/keylaunchrc-xephyr

contents of this file (target is xfce / precise) have not been modified, more and cat display the contents fine, but less (a bug?) appears to interpret some keystrokes that restart ratpoison or croutonwm? This terminal instance will now be dead.

[x3qt]

Any progress on this issue?

[dnschneid]

Only if you consider fixing it "progress."

Turns out it was the Chromium OS feature that defensively disables tap-to-click while you're typing that was causing the problem, which makes sense, since once you switch to the chroot, Aura no longer gets mouse events. It also explains why the various black magic workarounds worked...

Anyway, upgrade your chroot and confirm that it fixes it, please.

[thieman]

Only if you consider fixing it "progress."

Thanks for the fix!

[x3qt]

@tthieman feels like a time return to aib for you.

@dnschneid Thanks for the fix! Will test as soon as possible.

[tedm]

Thanks! Updated xfce and it seems to be fixed!!