Leveraging of Chrome's X server about crouton HOT 23 CLOSED

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

from crouton.

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

from crouton.

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

from crouton.

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.

from crouton.

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?

from crouton.

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

from crouton.

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.

from crouton.

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 :-)

from crouton.

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.

from crouton.

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/

from crouton.

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. =)

from crouton.

The trick was openbox --replace.

from crouton.

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

from crouton.

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.

from crouton.

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

from crouton.

True; I believe there's a patch somewhere in #144 for properly handling the host-x11 case as well.

from crouton.

I'm not sure if this topic is still interesting for you guys, but I have been able to start xterm/awesome using the stock xserver on my C720, by starting a new instance of X.
Here are the steps to start awesome:
1). As usual, run the preparation commands as root like below:

#!/bin/sh -e

echo 0 > /proc/sys/kernel/hung_task_panic

for fbc in '/sys/kernel/debug/dri/0/'*fbc*; do :; done
if [ -f "$fbc" ] && ! grep -q 'disabled per module param' "$fbc"; then
    fbc='/sys/module/i915/parameters/i915_enable_fbc'
    chgrp video "$fbc"
    chmod g+w "$fbc"
fi
drm_relax_file="/sys/kernel/debug/dri/drm_master_relax"
if [ -f "$drm_relax_file" ]; then
    echo 'Y' > "$drm_relax_file"
fi
echo 0| tee  /sys/module/i915/parameters/i915_enable_fbc

2). create a bash script, call it guestWM.sh:

#!/bin/sh -e
OLDAXUTH=$XAUTHORITY
export XAUTHORITY='/var/host/Xauthority'

sudo minijail0  -b /dev,/dev,1 \
    -b /dev/pts,/dev/pts,1 \
    -b $OLDAXUTH,$XAUTHORITY \
    -b /var/run/dbus,/var/host/dbus,1 \
    -b /var/run/shill/resolv.conf,/etc/resolv.conf \
    -v -p -C /usr/local/archlinux \
    /bin/bash -c "exec awesome"

3). run sudo xinit ~/Downloads/guestWM.sh -- /usr/bin/X :1 -nohwaccess -noreset -logfile /tmp/abc.log vt3

I think arm chromebooks should also be able to do it, although I can not test it by myself. Anyone could test for this?

from crouton.

I'm not sure if this has been answered or is of any interest to others, but here goes.

Following @ccaapton's hints I've started up awesome in a separate screen and on my Asus c720 it works great. I can even turn i915_enable_fbc back on after the screen has started and it's all good.

Now I tried doing what @dnschneid suggested in the 2nd note and it works even better- external screen support and all (SDL games work, so does mplayer2, etc). The last hurdle to perfection remains Skype. For whatever reason, when it's started in the same xserver as aura, it fails to render the window- all I see is a white square (it logs in just fine).

For now running it through local SSH X-forwarding seems to work, so I guess Skype uses some weird way of rendering itself that doesn't play well with Aura present on the same screen.

Finally, why I'm so hell-bent on running a single Xserver: switching back and forth between awesome and Chrome using Crtl+Alt+F[1-9] causes the screen to glitch if I'm running dual screen. Sometimes the screen turns blank for 5-10s even.

Any hints on debugging Skype much appreciated :)

from crouton.

EDIT: I moved this discussion to a new issue #931.

Amazing! ✨ Aura and Openbox work simultaneously on the same X server (using this xprop trick by @richardgv) when my Acer C720 chromebook is connected to an external monitor and its lid is closed:

# 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, once I disconnect my external monitor, I run into problems: Aura does not repaint itself anymore while X11 apps exist (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 are 2 displays (1 external monitor + 1 chromebook native display) but not when there is only 1 chromebook native display? 😰

Thanks for your consideration.

from crouton.

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

from crouton.

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

from crouton.

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.

from crouton.

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.

from crouton.