Samsung 303C ARM Dock Mode mouse locks up

[devref1]

I'm using a Samsung 303C chromebook.

I've had this problem with both ChromeOS Stable & Raring combo and ChromeOS Beta & Saucy combo.

I have an external mouse and keyboard connected to the chromebook via USB. The chromebook is plugged into a monitor via HDMI, and the built in display on the chromebook is turned off (by turning the brightness down all the way), so it goes into dock mode.

ChromeOS works fine. When I start Ubuntu, it works fine for a while. Then, after a minute or 2, the mouse will stop displaying graphical updates. I can see the effect of hovering the mouse and clicking on things on the screen (with an invisible cursor), but the mouse cursor stays stuck in the position it was in when it stopped responding.

I can fix the problem by ctrl+alt+shifting out to ChromeOS and then back into Ubuntu. Also note that, after the mouse has gotten stuck, it takes a few seconds to switch to ChromeOS when I press ctrl+alt+shit+forward/back. After it switches to ChromeOS, I can then instantaneously switch back and forth between ChromeOS and Ubuntu (until the mouse locks up again in Ubuntu).

Love crouton! Thanks for creating such a useful piece of software!

[devref1]

Forgot to mention, I'm running xfce on an encrypted chroot.

[devref1]

Noticed something else:

In XFCE, when the mouse is not locked up, I can switch between between workspaces that have programs running in them instantaneously.

However, when the mouse is locked up, pressing the alt+ctrl+right or alt+ctrl+left keys to switch workspaces lags when switching to a workspace that has a program running on it.

[devref1]

Also:

I won't always get this message. But sometimes, if I play around a bit in xfce before ctrl+alt+shifting back to ChromeOS (to fix a mouse lockup), I'll get the following message in the ChromeOS shell:

ratpoison:manage.c:236: error: XGetWMName failed

[devref1]

More testing:

I tried extending the screen from the built in display to the monitor, instead of turning down the brightness on the built in display and putting the chromebook into dock mode.

When the mouse locked up, it would only lock up in the monitor portion of the screen. If I move the mouse cursor into the built in display, it continues to work correctly. But as soon as I move it into the portion of the screen at the monitor, it disappears if the mouse has locked up.

This is all within xfce. Also testing kde in raring, and had the same issue. Also tried xinit after enter-chroot (which seems to start a very basic x server with just a terminal window), and that also locked up after a while.

[dnschneid]

Weird, sounds like there's something wrong with the cursor acceleration. You can try editing /etc/crouton/xserverrc-xephyr to remove the -host-cursor parameter, and comment out line 77 in /usr/local/bin/croutonxinitrc-wrapper that launches croutoncursor. That will revert back to non-hardware-accelerated cursors, which should probably work (but look bad).

[ErwinJunge]

I've been having this same issue and can confirm that performing the edits dnschneid suggested work. I don't see anything looking bad however. What change specifically should I look for in the cursors? It might just be that I don't care enough for the looks of my cursor to notice ;)

Anyways, I guess you'd rather solve the root issue here. Anything I can do to help?

[xYuunaX]

Hi devref1,

Can you try to boot up your chromebook without the mouse plugged in.. does it still hang? I've been experiencing some weird issues with the latest Crouton. When I plug in my mouse, the system hangs or is really slow.. Switching back to ChromeOS, i can see in the terminal some error msgs. I had to switch the croutonwheel from an older version to the newer as a temp fix.

Wonder if this is related?

[dnschneid]

@vampirexhunter: when your system gets really slow, can you run top from either crouton or crosh?

[xYuunaX]

no, system hangs when I try to do something. In crosh i see:

Backtrace: [mi] Increasing EQ size to 2048 to prevent dropped events. [mi] EQ processing has resumed after 699 dropped events. [mi] This may be caused my a misbehaving driver monopolizing the server's resources. [mi] EQ overflowing. Additional events will be discarded until existing events are processed.

Backtrace: [mi] These backtraces from mieqEnqueue may point to the culprit higher up the stack. [mi] mieq is NOT the cause. It is a victim. [mi] EQ overflowing continuing. 100 events have been dropped.

Backtrace: [mi] EQ overflowing continuing. 200 events have been dropped.

Backtrace: [mi] EQ overflowing continuing. 300 events have been dropped.

Backtrace: [mi] Increasing EQ size to 4096 to prevent dropped events. [mi] EQ processing has resumed after 353 dropped events. [mi] This may be caused my a misbehaving driver monopolizing the server's resources. [mi] EQ overflowing. Additional events will be discarded until existing events are processed.

Backtrace: [mi] These backtraces from mieqEnqueue may point to the culprit higher up the stack. [mi] mieq is NOT the cause. It is a victim. [mi] EQ overflowing continuing. 100 events have been dropped.

Backtrace: [mi] EQ overflowing continuing. 200 events have been dropped. (Goes up to 1000 Events Dropped)

Backtrace: [mi] No further overflow reports will be reported until the clog is cleared.

Hope this helps, couldn't even copy paste had to type this XD Going to use an older version of croutonwheel for now :)

Thanks!

[jnack95]

I have the same problem on samsung chromebook. The USB mouse freezes the system.....same output as vampirexhunter. Seems to be normal without it and the edits listed above make everything worse.

[dnschneid]

Uh oh. @drinkcat: xi2event acting up?

[drinkcat]

@dnschneid: Yes, confirmed, there is something fishy happening when using an external mouse and the latest croutonwheel. Will check it.

[jnack95]

Thanks for all your work. You guys rule!

[dnschneid]

USB mice bogging down the system is fixed in the latest version, but the original issue here has not been touched.

@devref1: could you confirm that the problem still happens, and if my suggestion here works around the issue?

[xYuunaX]

I'm at work at the moment, so I don't have a mouse handy to try. But the Trackpad is acting weird, workspaces are switching when I slightly touch the touchpad. And Pages stutter when I move the cursor (Trackpad).

jnack95, your trackpad works fine?

[jnack95]

Hmmmm I thought it was fine until I opened the browser. When I open a browser (with a scrollable page) any movement on the trackpad scrolls the window up or down. Seems the two finger scroll is linked to the one-finger scroll (mouse wheel). Seems that could cause your problem if your workspace is set to flip with the mouse wheel.

[dnschneid]

Really sorry about that (I've screwed the trackpad/mouse heuristic up once before as well). I've just pushed a fix that should be solid; please try it out.

[jnack95]

No problem. Everything seems fine now. Thanks

[devref1]

@dnschneid I downloaded the latest crouton and did a fresh install of raring today and did some testing.

The vanilla version of crouton/raring still has the same issues with the mouse locking up.

Implementing the changes that you suggested here appears to have fixed the problem.

Thanks so much! Crouton is awesome!

[dnschneid]

Hmm, it sounds like something's up with hardware cursor acceleration on the external display. I suspect it's a bug on Chromium OS's side, but Chromium OS does fine. I wonder what it's doing differently? You're probably going to have to stick with software cursors for now.