Closed sunaku closed 9 years ago
I have also filed this issue on the Chromebook Central Help Forum. :helicopter:
openbox isn't creating an unpainted root window, is it? If you run host-x11 xwininfo
in VT2 and then switch back to VT1, click on the frozen aura, then check the result in VT2, do you get the aura window/
Yes, I followed your steps and got the aura window:
?master ~> host-x11 xwininfo
xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
xwininfo: Window id: 0x200004 "aura_root_0"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 1366
Height: 768
Depth: 24
Visual: 0x21
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+0 -0+0 -0-0 +0-0
-geometry 1366x768+0+0
However, note that Openbox by itself doesn't trigger the issue. Instead, the issue is triggered by actual X11 apps (which actually display something on the screen) such as xterm
. As a result, we can eliminate Openbox from this scenario entirely and still reproduce the same results:
host-x11 xterm
in Crouton on an Acer C270 chromebook that (1) is not connected to any external display and (2) uses the ChromeOS stable channel at these versions:Version 35.0.1916.155
Platform 5712.89.0 (Official Build) stable-channel peppy
Firmware Google_Peppy.4389.84.0
Sorry for not providing this simplified procedure in the first place! :sweat_smile:
Thanks for your consideration.
Hi @dnschneid, another Acer C720 user confirmed this bug, so it's not something that happens solely on my particular Chromebook.
If you have access to other Chromebook models, could you please try the simple test of running host-x11 xterm
and see if that freezes Aura? (Closing the xterm should bring everything back to normal.)
Thanks for your consideration.
I too, can confirm this bug on the Acer C720 Chromebook.
Found a slight work-around. If you press Ctrl + Alt + forward arrow
you can get a screen update and you can then go from there. It seems like the Aura isn't updating like it should when it comes to normal x11 windows. I just started up Minecraft to see what would happen and it worked, but it wouldn't update what I saw until I entered the dev console, then exited it.
Good news! :sweat_smile: I'm now using ChromeOS Version 37.0.2062.120 (64-bit) where I have observed that this problem does not occur for every third X11 client that is launched. :cyclone: For example:
host-x11 xterm
, observe that this issue occurs, and then kill that xterm.host-x11 xterm
, observe that this issue occurs, and then kill that xterm. host-x11 xterm
, observe that this issue DOES NOT occur, and then kill that xterm.Why would this issue be so consistently periodic? :confounded:
Another interesting observation:
~/.config/openbox/rc.xml
file: <!-- the Aura window manager in Chrome OS -->
<application title="aura_root_0">
<decor>no</decor>
<!-- no window decorations -->
<layer>above</layer>
<!-- always on top -->
<iconic>no</iconic>
<!--<skip_pager>no</skip_pager>-->
<!--<skip_taskbar>no</skip_taskbar>-->
</application>
host-x11 openbox
in one crosh window.host-x11 xterm
in another crosh window.Notice that Aura remains responsive and the screen doesn't freeze up, even though xterm is running along side it (but hidden behind it). This leads me to think that Aura likes to be on top of all other windows when its sole display is the built-in laptop display. :punch:
I filed this bug report upstream on the chromium project as issue #418159. :flags:
Repainting issue on chromebook seems always related to the framebuffer compression. Maybe you can look at #477 and run echo 0 > /sys/module/i915/parameters/i915_enable_fbc
with root.
enter-chroot is supposed to disable fbc. Can you run cat /sys/kernel/debug/dri/0/*fbc*
and see what it says? If it's getting re-enabled for some reason then we'll need to make croutoncycle toggle it.
enter-chroot is supposed to disable fbc.
No, enter-chroot changes the permission, and allow fbc to be enabled. The one doing that is chroot-etc/xserverrc-x11
@dnschneid Actually I've pointed out in chromium issue 418159, that SNA+tearfree can solve the problem as well, but I doubt chromeos team has enough motivation to change the status quo in order to please us the minority, unless there are other huge benefits for enable SNA.
Could you push the chrome team to do it?
Whoops, I read it wrong. Perhaps host-x11 should do an fbc test-and-set then. I'll look into the bug, but I suspect touching the X11 settings would require a lot of additional testing that they'd rather not do.
:fire: OMG!! :sparkling_heart: THANK YOU @ccaapton !! :scream:
Had this issue for ages... :sob: a workaround at last! :sweat_smile:
Should we add something to host-x11 to make the workaround a little more discoverable (maybe a -g for "graphical" apps)? Or is this issue/a wiki entry with the workaround sufficient?
Freon and xiwi pretty much make this obsolete.
Hello,
When I connect my Acer C720 chromebook to an external monitor via HDMI and then close the lid (so that the only display available to the X server is the external monitor), I am able to run X11 apps successfully on the same X server as the Aura window manager using the
host-x11
script provided by Crouton:However, when I open the lid on my chromebook (so that there are 2 displays available to the X server), the chromebook's native display keeps cycling between on/off states and the external monitor keeps cycling between blank/nonblank states. :cyclone:
At this point, when I disconnect the external monitor from my chromebook by unplugging the HDMI cable, my chromebook's native display settles down (stops cycling between on/off states) and shows me my current ChromeOS session. However, everything is frozen: Aura does not repaint itself anymore until I terminate all X11 apps (minimizing the X11 apps doesn't work; Aura wants them gone for good!) so I have to awkwardly fish around the screen for close buttons on existing X11 apps (while the screen remains "stuck") and hit them all. :bullettrain_front:
Now, once all X11 apps are closed, Aura repaints itself and behaves normally. :sunglasses:
Why does Aura play nice with X11 apps when there is only 1 external display but not when there are 2 simultaneous displays (1 external monitor + 1 chromebook native display) or when there is only the chromebook native display? :cold_sweat:
Is there some kind of struggle for control between X11 apps and Aura in the latter 2 cases? If so, what is the former case doing correctly to prevent this issue? :confused:
Thanks for your consideration.