Split-screen chroot and Aura

[appsforartists]

It can be useful to have a Linux app and Chrome running side-by-side. (For instance, having an HTML file open in Sublime Text and seeing the results in Chrome.) Can we improve the xephyr target to make this easier?

[dnschneid]

That would indeed be a nice feature. Unfortunately, Aura constrains the area the mouse can move (see #1), so unless either 1) it doesn't do that anymore (which is possible), or 2) there's now a way to fix that, this won't be possible.

[appsforartists]

I like how targets are explained in the README now. (I don't think they were a few months ago.) I think we could do a better job with X implementations though, as these are a bigger deal than which WM someone chooses. Right in the README we should have something like:

There are three ways do display Linux windows on your Chromebook:

• X11: Your Chromebook has multiple workspaces called VTs. Using X11, you can run ChromeOS in one and your Crouton software in another. You'll have a very smooth experience in both ChromeOS and your Crouton environment, but they don't interoperate very well. You won't be able to display a ChromeOS window and a Linux one side-by-side. You also won't be able to copy from one environment and paste into another, but we're working on this.
• VNC: You can set up a VNC server inside Crouton and use a Chrome App to display your Crouton apps inside a ChromeOS window. (You're basically screen-sharing with an imaginary computer.) This is a work-in-progress. It's a bit slow, and software that requires GLX (including some window managers) won't work.
• Xephyr: This splits your screen into multiple sections, with ChromeOS running in one and Crouton running in another. It uses a program called ratpoison to do this. This target is also a work-in-progress. If you'd like to try it, make sure your very first target is Xephyr (e.g. crouton -t xephyr,touch).

[dnschneid]

Probably when VNC/tabbed mode is actually added. Until then, xephyr is really just supposed to be the X server when hardware acceleration is not available (ARM). Running xephyr on x86 platforms, while supported, is definitely a power-user thing and does not need a mention in the readme.

[appsforartists]

I just did some experimentation, using the present Xephyr target. Here's what I found:

Ratpoison has two concepts that are relevant, windows and frames. For our purposes, a "window" is an environment, either ChromeOS or crouton. A "frame" is a pane that contains a window. You can split your screen into multiple frames.

• Mash Ctrl+Alt+Shift+Esc then hit : to send a command to ratpoison. I'll abbreviate this as (RP)
• (RP) :hsplit will give you two screens, side-by-side, but only one of them will have a window in it.
• (RP)-tab will change which frame you are addressing.
• Ctrl-Alt-Shift-F2 will change which window is in that frame.
• (RP)-Q will make your current frame full-screen (undoing :hsplit).
• Accidentally hitting Ctrl+Alt+F2 (muscle-memory for the old switch-to-crouton command) can put you in a really bad spot. Sometimes you'll end up with your display showing the workspace you were running before xinit started, but your other workspaces (along with mouse and keyboard control) are still managed by ratpoison. You end up driving blindly until you restart.

Ratpoison seems to have three concepts of focus. The first is which frame is being controlled (e.g which one changes if you run a RP command). This is separate from mouse focus, which is separate still from keyboard focus. You can end up selecting text in one environment and typing in another. (It's weird.)

Hitting Ctrl+Alt and moving the mouse seems to change which environment has mouse focus. I'm trying to figure out why it doesn't always work, and how to change keyboard focus at all.

[appsforartists]

Sorry, @dnschneid, I was trying to dump all the stuff I learned into a ticket before reading what you wrote. I'm able to have a cursor in each frame (I have to use a keybinding to switch between them).

My cursor will be trapped in one frame until I hit Ctrl-Alt. Then it will be trapped in the other frame.

Is this different that your prior experience?

[dnschneid]

Sounds like the WM is overriding the mouse capture, which is pretty neat.

Unfortunately, I forgot to mention that on ARM Chromebooks, you lose a chunk of hardware acceleration in Aura if it's not fullscreen, and the results are pretty hideous. Since the xephyr target is really intended as the X server for ARM, I don't think we'll be changing that anytime soon, although if you find something that works for you, great.

Is the second frame for you xephyr, or sublime launched directly into the Chromium OS's X server (via host-x11)? If it's via xephyr, beware that xephyr will toggle a keygrab whenever you hit Ctrl+Shift, which will prevent ratpoison/whatever global WM you're using from seeing the hotkey. We work around this in crouton by using xbindkeys in the chroot to pass up the appropriate hotkeys.

[appsforartists]

I was using xephyr until I discovered host-x11, which more-or-less
accomplishes what I was trying to do, so I abandoned this idea.

If I could work around the touch/scroll issues in host-x11, it'd be
perfect.

• Brenton
  Sent from my phone.
  On Aug 24, 2013 4:53 AM, "David Schneider" notifications@github.com wrote:

Sounds like the WM is overriding the mouse capture, which is pretty neat.

Unfortunately, I forgot to mention that on ARM Chromebooks, you lose a
chunk of hardware acceleration in Aura if it's not fullscreen, and the
results are pretty hideous. Since the xephyr target is really intended as
the X server for ARM, I don't think we'll be changing that anytime soon,
although if you find something that works for you, great.

Is the second frame for you xephyr, or sublime launched directly into the
Chromium OS's X server (via host-x11)? If it's via xephyr, beware that
xephyr will toggle a keygrab whenever you hit Ctrl+Shift, which will
prevent ratpoison/whatever global WM you're using from seeing the hotkey.
We work around this in crouton by using xbindkeys in the chroot to pass up
the appropriate hotkeys.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/315#issuecomment-23207495
.

[dnschneid]

Yep, that's more #1 territory.