Leveraging of Chrome's X server

[davidradkowski]

Hi

Not an issue, more a question/feature request:
Would it be possible to use Chorme's X server to run chroot-ed X/gtk apps?
Some quirky ssh tunneling?

Cheers

[dnschneid]

(Edit 2015-02-14: this is way obsolete. xiwi (X in a window) is the best bet moving forwards.)

You can actually do this, but you probably won't like the results.

1. Copy the contents of /var/run/chromeoslogin.auth to your chroot/home/user/.Xauthority file (and make sure the resulting .Xauthority is readable by the user).
2. Enter the chroot if you haven't already, export DISPLAY=:0.0, and then you should be able to launch applications into ChromeOS's X server.
3. You'll quickly notice that Aura doesn't have an X11-compliant window manager, so you'll be tempted to start your own. In fact, why not start the entire desktop environment, say, Xfce? (startxfce4) You can actually do this, and Aura will become just another window--except for whatever reason, it constrains the cursor to its client space, so you won't be able to touch the window borders, or go to the panel unless it doesn't reserve space for itself (e.g. you should be able to poke at an auto-hiding panel).
4. Okay, we can work around this. If you're in Xfce, hit Alt+F11 to toggle full-screen on the Aura window; most WMs have something equivalent you can use. Now the window will be full-sized, and you'll be able to move the mouse anywhere (assuming you have only one monitor). You can then Ctrl+Alt+Arrow to switch between workspaces, and you'll have somewhat better integration.
5. Wait, what's that you say? You have a Chromebook and only up through F10? In Xfce, you can Alt-F2 (Forward) to get a run dialog, run xfwm4-settings, and change the default shortcuts in the keyboard tab.
6. Great! So we have Aura taking up a workspace, and we can quickly swap between workspaces using the shortcut keys, running applications alongside. Perfect, right? Not really.
   • We can't really put any windows above Aura since it's running in full-screen mode (unless your WM supports putting full screen applications "always on bottom").
   • Aura doesn't use the X11 clipboard, so there's no copy-paste integration.
   • The ChromeOS X11 server is relatively minimal, with only one font (so non-toolkit apps, or apps that use X11 fonts will look terrible)
   • Aura disables coreevents for most input devices (such as trackpads), preferring to do gesture recognition and whatnot on its own. That means trackpad scrolling of any kind will not work outside of Aura. Not even the mousewheel of an external mouse will work. You will have to re-learn the scrollbar. It's like returning to the stone age, really. I think you can re-enable coreevents via some X11 command, but I don't know how Aura would react to that.
   • The Aura lock screen is still inside that same window, so it won't lock your X11 session as a whole; you'll still have to run xscreensaver or something. Ignoring the elephant that is passwordless root on VT2.
   • No idea what will happen with multiple monitors, and I'm kind of scared to find out.
   • On the plus side, you might be able to re-enable powerd without having the device think you're idle while you're working outside of the Aura interface. Haven't tested this, though...

So basically, integration is very poor, so you don't gain much. It has pretty much the same interface problems as the X11 approach, so you don't resolve much. And with its specialized X11 server and non-X11-compliant Aura interface, you win more issues. Not very appealing.

But hey, if you can find a creative use for this, let me know...

[davkg]

Hey, out of curiosity I tried the first few steps, but I'm getting some weird issues. Graphical programs do seem to start, but they flicker and disappear. e.g. If I start leafpad, I'm able to type some text in and save a a file even though I can't see leafpad anymore. The same thing occurs when I try starting fluxbox.
This also happens with X forwarding over SSH.

Is there a way to fix this?
edit: I'm on the ARM Chromebook, dev channel

Thanks,
David

[dnschneid]

The ARM Chromebook's X server has some hacks to improve performance. crouton has a hack of its own to get around this, using ratpoison. Install crouton with -t xephyr at a minimum (xfce, unity, etc, all include this by default on ARM), then enter the chroot and run croutonwm to enable the hack (running xinit or starting xfce/unity/etc runs this by default as well).

[davkg]

Thanks for the response! It works as expected. I'll be sticking to the usual crouton targets, but it's nice to know this works as well.

[nskaggs]

So I created an account just to join in this discussion :-) I really like the idea of pulling a specific app from chroot into the aura workspace and running it. For folks who love skype for instance, they could run chrome os, with a skype binary pulled across to run in chrome's x11 server. I realize the integration points (like making a launcher, proper alt-tab and copy/paste) might be difficult or impossible to pull off, but i'm curious to hear your thoughts on how to try.

My own usecase for this is running my favorite editor (yes, I'd rather not be stuck with vim) in chrome's x11, thereby eschewing the need to run a full blown version of ubuntu desktop (or even have it installed in my chroot). Running openbox to get around the WM issue works well enough, dropping aura and all windows into an aura root, while giving you the basic window management features for the application itself. It's uber hacky, but if you could get corevents (mouse scrolling please!) it would be enough.

So, how could you re-enable core events?
How could we work on integration points? Add-on to aura? Create a WM that speaks to aura that can translate for x11 apps?

[dnschneid]

Note that since my long post above, a few things have gotten easier with the introduction of the xephyr target:

1: If you install the xephyr target, the proper XAUTHORITY will be automatically copied to /etc/X11/host-Xauthority in the chroot.
2: Still applies.
3-5: You've gotten around using openbox. I'm not very familiar with openbox; did you set it so that it keeps aura full-screened or something? What happens with alt-tab? Also, you're likely to have annoyances on ARM, where this bug still exists.

Integration:

• Still required to keep Aura full-screen.
• Still no clipboard integration. I poked around the source a little bit but no integration points stood out to me.
• Still stuck with the minimal X server, although that might not bother you.
• The lack of mousewheel turned out to not be due to coreevents, but due to Chromium OS mapping the mouse wheel to a separate axis in order to implement really smooth scrolling. You should be able to get mouse wheel functionality by running the croutonwheel script from within the chroot (install the xephyr target). Fundamentally it should work with root window managers other than ratpoison, but you'll need to tweak line 57 and comment out 78 through 80. Again, that should work, but I haven't tested it.
• Lock screen is still an issue. Not sure if there's a dbus event when the lock screen turns on; if there is, you may be able to trigger a lock screen (xscreensaver, xlock, etc) for the X session as a whole by scripting with host-dbus dbus-monitor --system.
• Still haven't tried multiple monitors in this kind of setup. Feeling lucky?
• There's now proper X11/powerd integration, but you'll have to run it manually in this setup. croutonpowerd within the chroot should work fine.

If you can get something reasonable and reliable set up, this may be worthy of a target...

[nskaggs]

Thanks for the updates. I'll try and fix the lock screen and mouse issues with your suggestions /fingers crossed. The other "big" integration point would be clipboard -- I tried hacking around with the xserver clipboard, but I've no idea how that is working in aura.

On the other caveats:

• 1. Interesting -- i played with xephyr but only briefly
• 3-5. Fortunately I'm not on ARM -- I'd focus on getting this to work on the intel targets first. Yes openbox will keep aura fullscreen. I played around with how alt-tab works, but the best setup was to let openbox handle alt-tab completely. You end up with swapping between your X11 apps, and aura + desktop. If you want to switch windows, I use the f5 key or manually do so. I'm guessing/thinking/hoping if this works out we could do more here. I also messed with tinywm: http://incise.org/tinywm.html and would probably go that direction.
• Multiple monitors -- heh, let's not get fancy. That said I've actually no way to test this on my chromebook, no cable.

[nskaggs]

Just a quick update to say the proof of concept worked out well. Croutonwheel (with some hacks) and croutonpowrd both work great. I switched the wm to fluxbox with some slight config changes, so I could remap alt+tab to something like the search key so alt+tab isn't broken in aura, and switching between your X11 app and the rest of aura is easy. The lock screen issue remains, I'll have to play around more with it. I was really hoping for clipboard support and I see this: #144. I'm watching with great interest :-)

[dnschneid]

Cool! You might want to write up your solution on a new page in the wiki in case others want to do something similar.

Additionally, once #126 is finished, your solution will probably be even simpler.

[agriffis]

The information in this ticket and #126 is awesome, thanks. With this information it becomes trivial to run synergy on the Chromebook, so sharing mouse/keyboard with a desktop works. See http://synergy-foss.org/spit/issues/details/3433/

[appsforartists]

This is really cool. I just started testing it, but it seems to be working for me. (chromoslogin.auth is now chromelogin.auth). I can use the mouse to switch keyboard focus between the windows, and I can drag the Sublime Text window with its menubar. I can't, however, intuitively resize the window or send it behind Aura in the Z stack.

Openbox isn't working for me in the chroot I normally use with X11. I'll make a new one and see if it works for me there.

I don't know if ChromeOS has improved since this issue was closed, but if we could get this working, it would be the holy-grail of running Linux apps on ChromeOS. =)

[appsforartists]

The trick was openbox --replace.

[moocow1452]

So this would be the way to go rather than trying to port something like VirtualGL or TurboVNC to Chrome?

[mitchellurgero]

I use Chrobuntu and just start the chroot with "sudo startunity" (I have unity installed not xfce)

This automatically started unity in full screen, I can use graphical applications fine, but I have been looking for an X server extension for chrome, but instead of pulling apps into aurora, pull apps into ubuntu instead?

Just an idea.

[nskaggs]

Hmm, with #126 and #144 now complete, I'm guessing we could make something nicer for this.

[msf]

I just wanted to stay that I successfully ran openbox + Aura on the native X server on arm (tegra K1)
I used a crouton cli install of Debian where I have openbox installed.

I'm VERY interested in having a reliable way of running X apps from debian running with Xforwarding on the native X server.
This is important for me because:

• xephyr is very very slow in my system, unusable I would say.
• a second X server on the chroot with fbdev is unstable and has some color inversion issues
• couldn't yet run the chrooted X server with the tegra K1 binary drivers

[lovedheart]

Can you give some steps how tor un native X sever on tegra k1? @msf Thanks in advance.

[pocc]

I'm trying to follow this guide, but I'm getting some errors:

Gtk-WARNING **: cannot open display:

Invalid MIT-MAGIC-COOKIE-1 keyOpenbox-Message:
Failed to open the display from the DISPLAY environment variable.

I'm working on a Toshiba Chromebook 2, and have set up cinnamon, lxde, and xfce chroots. I'm assuming it's something stupid simple if the DISPLAY environment variable is having issues.

[dnschneid]

This is mostly going the way of the dodo with the advent of xiwi (X in a window) and the migration to Freon (Chromium's new display server) fundamentally breaking host-x11.