Aura freezes when X11 apps run on native chromebook display

[sunaku]

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:

# treat Aura as a desktop so that "show desktop" works correctly in openbox
# and also so that Aura is not listed in the Alt-Tab window menu in openbox
# see https://github.com/chjj/compton/issues/118#issuecomment-19513709
host-x11 xprop -name aura_root_0 -f _NET_WM_WINDOW_TYPE 32a -set _NET_WM_WINDOW_TYPE _NET_WM_WINDOW_TYPE_DESKTOP
host-x11 openbox &
host-x11 xterm

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

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

Now, once all X11 apps are closed, Aura repaints itself and behaves normally. 😎

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? 😰

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? 😕

Thanks for your consideration.

[sunaku]

I have also filed this issue on the Chromebook Central Help Forum. 🚁

[dnschneid]

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/

[sunaku]

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:

1. Run 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! 😅

Thanks for your consideration.

[sunaku]

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.

[Addicted247]

I too, can confirm this bug on the Acer C720 Chromebook.

[Addicted247]

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.

[sunaku]

Good news! 😅 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. 🌀 For example:

1. Run host-x11 xterm, observe that this issue occurs, and then kill that xterm.
2. Run host-x11 xterm, observe that this issue occurs, and then kill that xterm.
3. Run host-x11 xterm, observe that this issue DOES NOT occur, and then kill that xterm.
4. Go to step 1. 🌀

Why would this issue be so consistently periodic? 😖

[sunaku]

Another interesting observation:

1. Add the following snippet to your ~/.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>

1. Run host-x11 openbox in one crosh window.
2. Run 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. 👊

[sunaku]

I filed this bug report upstream on the chromium project as issue #418159. 🎏

[ccaapton]

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.

[dnschneid]

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.

[ccaapton]

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

[ccaapton]

@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?

[dnschneid]

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.

[sunaku]

🔥 OMG!! 💖 THANK YOU @ccaapton !! 😱

Had this issue for ages... 😭 a workaround at last! 😅

[dnschneid]

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?

[dnschneid]

Freon and xiwi pretty much make this obsolete.