trackpad configuration (not a bug)

[craigerrington]

Sorry for registering this as a bug, I was trying to find an alternative contact method..

I was interested to see how to go about configuring the mouse options in xephyr - i can see a virtual mouse driver is in use, but not sure if the config is happening inside the chroot, or as part of your launch scripts..

I'm basically just trying to pass through the "mouse wheel" (two finger scroll in chrome) to xephyr for scrolling etc..

[dnschneid]

Bugs are the right place; I can label them as questions after they've been posted.

The first place to look is in targets/xephyr, which generates the chroot's /etc/X11/xinit/xserverrc, which in turn launches xephyr if appropriate. I tried for a bit and wasn't able to get mouse wheel events passed through, but you may have more luck.

Some possible leads for you:

• The ChromeOS X11 server by default has the physical mousewheel moved to buttons 8 and 9; Xephyr only supports up to 5 as far as I can tell (maybe it supports more?). If Xephyr does support more than 5 buttons, you'll need to map 8 and 9 back to 4 and 5 somehow. This may not affect two-finger-scrolling.
• The ARM Chromebook is using the cypress driver in X11 for the touchpad; I'm not sure if it's even configured to emit standard scroll events. You can use the xinput command to change X11 driver parameters on the fly (either outside the chroot, or inside if you've set export DISPLAY=:0 XAUTHORITY=/etc/X11/host-Xauthority), so you may just be able to tweak a few parameters to get it to emit the right events. Of course, you'll then need to see how the new events interact with ChromeOS.
• The chroot is able to access /dev/input/event*, so you can bypass both of the above issues if you can get Xephyr to use the device directly (I believe it is /dev/input/event1 on the ARM Chromebook). Xephyr has a flag that you can pass in to specify a driver and device for mouse input, but I wasn't able to get it to work in the relatively short amount of time I played with it. On the other hand, this may have the unintended consequence of Xephyr registering mouse clicks even when in the background, which would be very bad...

Let me know if you get it working, and I'd be elated to be able to roll that into crouton. It's a pretty annoying omission.

[dnschneid]

This hack is the best I've come up with so far; unfortunately the performance is pretty bad, but try it out and tell me what you think: https://github.com/dnschneid/crouton/blob/wheel/chroot-bin/croutonwheel Drop the script in your chroot and run it.

[craigerrington]

Brilliant! Required an install of xdotool package, but other than that perfect!

I'm not too bothered about performance, it was more an annoyance of trying it each time before remembering...now at least it does something!

Great work again.

[craigerrington]

In fact, I'm pretty happy with performance.... I've stuck the script in as an autostart application (via a launcher script) in XFCE - job done! :+1:

[dnschneid]

Just pushed a new version (same link). This now uses xev and xte to avoid creating a zillion processes every time you try to scroll, so it should perform waaay better. You'll need the x11-utils and xautomation packages. There's still a tiny chunk that needs xdotool; still trying to figure out a way to get rid of that dependency entirely. You can also now configure the scroll acceleration when you launch wheel; let me know if you find better values than the defaults :)

[craigerrington]

Superb - I'll give this a try when I get home tonight

On 16 January 2013 00:24, David Schneider notifications@github.com wrote:

Just pushed a new version (same link). This now uses xev and xte to avoid creating a zillion processes every time you try to scroll, so it should perform waaay better. You'll need the x11-utils and xautomation packages. There's still a tiny chunk that needs xdotool; still trying to figure out a way to get rid of that dependency entirely. You can also now configure the scroll acceleration when you launch wheel; let me know if you find better values than the defaults :)

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/3#issuecomment-12297693.

[craigerrington]

Found the scrip on the wheel branch...

Question - has this been pushed to the crouton script? as in,...can I use your update method, and the wheel fix will be implemented?

Or should I just take the script from the "wheel" branch and insert it into my current build?

[dnschneid]

Oh yeah, forgot to update the link here (now updated above); sorry about that. It's fully-integrated in the wheel branch, but I'm still ironing out a couple bugs with the auto-hiding of the xinput window before merging the changes into master. If you'd like to apply it using the update method, you'll have to either grab a tarball of the branch on your Chromebook and run the installer/main.sh directly, or grab it on another machine (or inside your current chroot), run make to build the crouton bundle, then run that.

[craigerrington]

I've stuck with the path of least resistance so far and just updated the script inside the chroot..

Working well (after xautomation install)

I hope you don't mind I've been writing bits and pieces of this up on my blog (craigerrington.com) and directing folk over from chromebook central etc - this is certainly the best thing I've seen released from the dev community for the Chromebook (especially on the arm devices where no one had managed this at all yet..as in, concurrent x servers).

[dnschneid]

That works :)

Thanks for the publicity! My only request is that if you post instructions, either keep them up-to-date or properly deprecate them when things change. And if you have any suggested changes to the README to make it more approachable, fire away! (I suppose that's two requests.) Also beware that once I merge in a branch, links directly pointing to files in the merged branch will become invalid (which might be useful as a tool for automatic deprecation...)

[craigerrington]

Duly noted. I've been going back and re-doing instructions etc when things change.

I'll use a "link doesn't exist" type check to properly deprecate things when they change.

I'm also trying to point people directly to your readme rather than re-doing your work. I'll have a think about changes to the Readme.md (it's great for those with a bit of tech savvy, but anyone new to concepts like chroots etc will be a little confused - some folk in the Chromebook Central google group were struggling to picture the concept..

[dnschneid]

Awesome; thanks!

[dnschneid]

Just pushed a new version of the wheel script, which should be way more reliable about hiding the xinput window without eating CPU. It also has saner default settings and activates horizontal-scrolling by default. The croutonwm script has been updated to run croutonwheel automatically.

Could you grab both files, drop them in your chroot's /usr/local/bin, disable your own wheel auto-launcher, and give it some testing? It should be rock-solid even when repeatedly launching and quitting the chroot (the xinput window should never be left visible, and it should certainly never kill the wrong window). The default parameters should be more similar to standard wheel sensitivity settings on Linux (you can override them by creating a file .croutonwheel in your home directory with parameters).

If this looks good, I'll merge it into master.

[craigerrington]

That made things crazy...

With those two scripts in place, in a clean new chroot xfce target, that's causing the two x servers to compete with each other... the chrome interface keeps coming on top, and then moving items around the screen gradually reveals xfce again...

This is on an ARM chromebook..

I'm not sure how better to describe it...

[dnschneid]

Ah, ratpoison killed itself. That explains a lot. I'll put up a fix soon.

[dnschneid]

Okay, updated croutonwheel. Try this one.

[dnschneid]

Merged into master.

[craigerrington]

Hey - did you merge this already?

I just installed an xfce target to SD and with no changes, everything seems to be working :+1:

[dnschneid]

Yep, merged it last night. Glad to hear it's working.

[hkoster1]

Mmm... so two-finger vertical scrolling should be working in the chroot on my Samsung ARM Chromebook? Well, it is not, at least not in LXDE. So, to be sure, I also installed the XFCE4 target, but there it's not working either. The "ps ax" command shows that croutonwheel is running. So, what am I overlooking? FWIW, the one- and two-finger taps on the trackpad only work after first switching back-and-forth to ChromeOS, is that related?

[dnschneid]

What version of Chromium OS are you running? (check about:version)

The switch back-and-forth part is known; see #38

[hkoster1]

Google Chrome: 26.0.1410.57 (Official Build 191765) stable-channel daisy,

anyway, my ARM Chromebook is brand new, OS updated yesterday when I switched to developer mode.

Yes, I know about #38. I also just posted a new issue #109, don't know whether that is related.

[dnschneid]

Perhaps the output of xinput test-xi2 is different due to your locale. Try running xinput test-xi2 > ~/Downloads/xinput.log under Chromium OS, doing the two-finger scroll action a bit, then killing it with Ctrl-C and posting the xinput.log file to pastebin or gist or something.

[hkoster1]

I'll investigate this further along the lines you're suggesting, be back in a couple of days to report on that.