Crouton: Scripts like `xiwi` and `startxiwi` to use `sommelier` instead of `xiwi`

[kapilhp]

For a while now xiwi windows seem to "disappear" (not entirely!) when the system sleeps. Morever, sommelier windows seem to work better.

I have added some scripts to the sommelier page on the wiki which can serve to use sommelier instead of xiwi.

I have found them useful. Perhaps others will too. So with appropriate modifications they could be added to the installation.

runsommelier.gz
startsommelier.gz

[satmandu]

FYI the current version of sommelier works fine too, and also gives you graphics acceleration.

See https://github.com/skycocker/chromebrew/pull/4450

chronos@localhost ~ $ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) UHD Graphics 615 (AML-KBL) (0x591c)
    Version: 20.2.1
    Accelerated: yes
    Video memory: 3058MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 615 (AML-KBL)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.2.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 20.2.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

chronos@localhost ~ $ 

[kapilhp]

Are there build instructions under crouton? Or (one can always hope!) a patch?

[satmandu]

See the chromebrew recipe.

Build instructions can be figured out from there without too much trouble.

On Thu, Oct 29, 2020, 12:50 AM Kapil Hari Paranjape <
[email protected]> wrote:

Are there build instructions under crouton? Or (one can always hope!) a
patch?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/4363#issuecomment-718357871,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAILX7KRDOEGFTMYJMPM5ELSNDYCXANCNFSM4S6LKGTQ
.

[kapilhp]

Indeed the instructions are:

1. Install the additional build-dependences (Not sure that these are all! You also need the ones listed on the wiki page for sommelier)

apt-get install -y meson ninja-build cmake libdrm-dev

1. Download the source:

curl -O https://chromium.googlesource.com/chromiumos/platform2/+archive/HEAD/vm_tools/sommelier.tar.gz

1. Unpack the source:

mkdir src
cd src
tar xzf ../sommelier.tar.gz

1. Use meson to create the build directory:

meson build

1. Download virtwl.h and put it in build/linux/

mkdir build/linux
curl -O "https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/master/include/uapi/linux/virtwl.h?format=TEXT" | base64 --decode > build/linux/virtwl.h

1. Do the build:

ninja -C build

The binary for sommelier is in build. It can be stripped and installed.

With this version of sommelier one does not need to execute a wayland binary prog with sommelier prog. Once the environment is set one just executes prog. So runsommelier needs to be fixed.

[satmandu]

I hadn't thought of putting the virtwl.h in build/linux. Good idea!

Also note that chromebrew is using a sommelierd script, so that sommelier is called with the flags it needs. (Sommelier is run twice - once for X11 apps and once for wayland apps.)

Also different from the default install (though how it is actually installed) is the use of a sommelier shell script, and the actual binary being put in sommelier.elf.

[satmandu]

Also note the need for CFLAGS="-fuse-ld=lld" CXXFLAGS=-fuse-ld=lld when compiling both sommelier AND mesa if you want graphics acceleration.

(mesa can link to system egl libraries with those flags, and then sommelier wants to use libgbm.so, but once you've started pulling in system libraries, you have to use lld for all dependent libraries.)

[satmandu]

Otherwise, you get this sort of breakage:

FAILED: sommelier c++ -o sommelier sommelier.p/meson-generated_aura-shell-code.c.o sommelier.p/meson-generated_drm-code.c.o sommelier.p/meson-generated_gtk-shell-code.c.o sommelier.p/meson-generated_keyboard-extension-unstable-v1-code.c.o sommelier.p/meson-generated_linux-dmabuf-unstable-v1-code.c.o sommelier.p/meson-generated_pointer-constraints-unstable-v1-code.c.o sommelier.p/meson-generated_relative-pointer-unstable-v1-code.c.o sommelier.p/meson-generated_text-input-unstable-v1-code.c.o sommelier.p/meson-generated_viewporter-code.c.o sommelier.p/meson-generated_xdg-shell-unstable-v6-code.c.o sommelier.p/sommelier-compositor.cc.o sommelier.p/sommelier-data-device-manager.cc.o sommelier.p/sommelier-display.cc.o sommelier.p/sommelier-drm.cc.o sommelier.p/sommelier-gtk-shell.cc.o sommelier.p/sommelier-output.cc.o sommelier.p/sommelier-pointer-constraints.cc.o sommelier.p/sommelier-relative-pointer-manager.cc.o sommelier.p/sommelier-seat.cc.o sommelier.p/sommelier-shell.cc.o sommelier.p/sommelier-shm.cc.o sommelier.p/sommelier-subcompositor.cc.o sommelier.p/sommelier-text-input.cc.o sommelier.p/sommelier-tracing.cc.o sommelier.p/sommelier-viewporter.cc.o sommelier.p/sommelier-xdg-shell.cc.o sommelier.p/sommelier.cc.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group -lm /usr/local/lib64/libgbm.so /usr/local/lib64/libdrm.so /usr/local/lib64/libpixman-1.so /usr/local/lib64/libwayland-client.so /usr/local/lib64/libwayland-server.so /usr/local/lib64/libxcb.so /usr/local/lib64/libxcb-composite.so /usr/local/lib64/libxcb-xfixes.so /usr/local/lib64/libxkbcommon.so -Wl,--end-group /usr/local/lib64/gcc/x86_64-cros-linux-gnu/10.2.0/../../../../x86_64-cros-linux-gnu/bin/ld: /usr/local/lib64/libgbm.so: unknown type [0x13] section `.relr.dyn' /usr/local/lib64/gcc/x86_64-cros-linux-gnu/10.2.0/../../../../x86_64-cros-linux-gnu/bin/ld: /usr/local/lib64/libgbm.so: error adding symbols: file in wrong format

[dnschneid]

It would be fantastic to get this into a state where it can be merged as a target, complete with hardware acceleration, especially since xiwi's days are numbered.

[kapilhp]

Worked on this for a bit. However, the "fork and create a pull request" approach had to be abandoned since I could not figure out how create a new "real installer". If you need me to fill in some declaration so as to include these files in crouton, let me know.

The enclosed file sommelier.gz is the gzipped version of a "target" script for crouton.

It was tested as follows.

1. A fresh crouton was created with the command:

sudo crouton -n test -r buster -t core

1. The target script sommelier was then copied and run:

cp sommelier /tmp/crouton-installer-cache/sommelier
sudo crouton -n test -u -T /tmp/crouton-installer-cache/sommelier 

1. After entering the crouton with sudo enter-chroot -n test the following commands were executed:

sudo mkdir -p /usr/local/{bin,etc}
sudo cp sommelierrc /usr/local/etc
sudo cp runsommelier /usr/local/bin
sudo chmod +X /usr/local/bin/runsommelier

1. After this runsommelier xterm was able to pop-up a window. This has been defined as success!

Step (3) was required because I could not get the parts of the target as below to work:

# HOSTBIN='startsommelier'
# CHROOTBIN='runsommelier'
# CHROOTETC='sommelierrc'

The remaining enclosed files sommelierrc.gz, runsommelier.gz and startsommelier.gz are the files that need to be installed.

Some further remarks.

1. The script runsommelier writes its output and errors to /tmp/sommelier.log. This is probably not the correct location.

2. The SOMMELIER_ACCELERATORS environment variable should probably be user-definable. It defines which keys go through to the Chrome window manager.

3. The startsommelier script is shamelessly copied from startxiwi!

4. The runsommelier script is shamelessly copied from satmandu's script for chromebrew as is the build procedure!

5. Accelerated graphics have not been checked. According to satmandu, that may require separate sommelier processes for X and wayland. Also it may require one to use the LLVM compiler whereas the current one uses GCC.

sommelier.gz
runsommelier.gz
sommelierrc.gz
startsommelier.gz

[satmandu]

I dug some more into sommelier and how it is setup in Crostini, and I'm wondering if the best approach might be to collaborate to figure out a solution which could be used collectively among all crouton-esque distributions.
Crostini's Sommelier is setup effectively as a standalone chroot in /opt/google/cros-containers/ from which sommelier is run accessing its own libraries.

This is done by renaming the app binaries in /opt/google/cros-containers/bin/ to binary.elf and replacing by shell scripts which look like this:

#!/bin/sh
if base=$(readlink "$0" 2>/dev/null); then
  case $base in
  /*) base=$(readlink -f "$0" 2>/dev/null);; # if $0 is abspath symlink, make symlink fully resolved.
  *)  base=$(dirname "$0")/"${base}";;
  esac
else
  case $0 in
  /*) base=$0;;
  *)  base=${PWD:-`pwd`}/$0;;
  esac
fi
basedir=${base%/*}
# TODO(crbug/1003841): Remove LD_ARGV0 once
# ld.so supports forwarding the binary name.
LD_ARGV0="$0" LD_ARGV0_REL="../bin/sommelier" exec   "${basedir}/../lib/ld-linux-x86-64.so.2"   --library-path "${basedir}/../lib"   --inhibit-rpath ''   "${base}.elf"   "$@"

This allows any distribution installed in crostini to have access to the ChromeOS windowing environment via the sommelier proxy app. (Of course the name sommelier itself is aptly named as a sommelier is a wine steward who stands apart.)

Sommelier is tuned for using the virtwl interface to tunnel through crosvm to the parent system, but obviously, as we have discovered that is not necessary.

What I would suggest would be to create a minimal standalone chroot for sommelier just like in crostini which could be invoked when needed by crouton or chromebrew apps or whatever. You would just need to run the script invoking sommelier, and pass DISPLAY and WAYLAND_DISPLAY, and your apps should just work with graphical acceleration.

Obviously each such sommelier chroot would have to be tuned for each hardware type, since you may need specific hardware dri drivers than just an architecture-based package, but a community effort to do that might allow for better support of getting gui apps running.

On my nocturne builds, I'm seeing graphics acceleration when links are made to the /usr/lib64/libminigbm.so files, but this might be easier to suss out with a smaller targeted setup. A sommelier chroot might not be too hard to setup with chromebtew, but other ways should work too.

Thoughts @dnschneid ? @uberhacker ?

[MrHallway0]

The problem I see here is that Crostini didn't just copy and past Crouton's code and run it in some fancy tech they call crosvm or something. There is probably some sort of support feature that they use inside of Crostini that you need...

[satmandu]

I'm not saying that they copied crouton's code. I'm saying they implemented their own chroot to enable sommelier, inside crostini, and we could do that too for non-crostini.

Yes there is some special sauce for sleep and notifications, but their setup is in some ways more complicated because it has to go through crosvm.

[MrHallway0]

Okay... crosvm uses the vmc command to create VMs I think.
So could you copy data from a chroot to a VM... oh wait that would be slow.

[kapilhp]

Continuing from the build instructions and the installation instructions above.

Made a small change to the runsommelier script based on satmandu's patch for chromebrew.

After this glxinfo indicates that Direct Rendering is working.

runsommelier.gz

[kapilhp]

A "dummy" Debian package to ensure that dependencies of sommelier are not removed. A better way would probably be to create a sommelier package!
sommelier-dummy_1.0_all.deb.gz

[jazzgroove]

It would be fantastic to get this into a state where it can be merged as a target, complete with hardware acceleration, especially since xiwi's days are numbered.

Can you say more about this? I noticed that xiwi appears to be broken now in Chrome 89. Is the plan to adopt sommelier as the replacement?

[dnschneid]

xiwi depends on pnacl, which has been deprecated and is in a slow process of being removed entirely. sommelier would be the logical replacement.

[satmandu]

My 2 cents as a Chromebrew person:

FYI as of early January, "upstream" sommelier no longer has an option to pass in a virtwl device as /dev/null, and this breaks sommelier starting outside of a VM which provides it.

Also on devices with 4.4 kernels, sommelier sessions don't appear to survive sleep/suspend cycles, with Xwayland dying.

It might be better to get as many apps as possible using Wayland, since that doesn't require as much of a shim like Sommelier which isn't targeted to use outside of the Cristiano VM, and which needs Xwayland anyways.

I'm still having some issues with client side decorations (or maybe server-side-decorations?) not showing up correctly for all Wayland apps, but that could be some weird interaction between gtk3/gnome and the ChromeOS Wayland server.

[dnschneid]

FYI as of early January, "upstream" sommelier no longer has an option to pass in a virtwl device as /dev/null, and this breaks sommelier starting outside of a VM which provides it.

I don't see the change in sommelier. Where do you see this? Or does the parameter still exist, but /dev/null no longer functions?

[satmandu]

@dnschneid This is the relevant commit: https://chromium.googlesource.com/chromiumos/platform2/+/7ea49bbabed436e608a0b8974ec90366a787d841

"there's a few simplifications, like assuming the virtwl device is always at "/dev/wl0"."

The parameter is no longer used at all.

[dnschneid]

Sounds like we'll either need to patch around it at compile-time, add a fake device to the filesystem, or convince the maintainers to support our use-case. :(

[satmandu]

@dnschneid Doesn't sommelier seem like overkill though? If we're not punching through a VM, then why go through the hassle of a bulked up Xwayland shim? Seems to me the simpler way would be to just do whatever we need to do to get Xwayland to work with the ChromeOS wayland server directly.

As I understand it Xwayland doesn't think Exo is a proper Wayland server, but it does see Mutter or Weston as a proper Wayland server... so maybe that would be a good direction to go towards?

Honestly, I think running Xwayland through a VM tunnel via a sommelier shim is a bit of a dead-end. It reminds me of NT4's hardware acceleration problems. The performance difference between sommelier through crostini and sommelier just connecting directly to the ChromeOS Wayland server is a little insane, no? (Half as fast...)

[dnschneid]

I can't say I've investigated this in much depth.

I do want to note, though, that crouton users generally expect to be able to run their desktop environment of choice. As for running apps in windows, I don't have numbers, but based on tutorials I think it's safe to say that's a relative minority of users. So however we end up using the ChromeOS wayland server to replace xiwi needs to be able to support everyone's preferred desktop environments -- and not just those built around wayland.

[DennisLfromGA]

My 2 cents...

I much prefer running the desktop of my choice instead of just using apps in windows.
I go through hoops in Crostini like using Chrome Remote Desktop to access a desktop environment instead of just running an app in a window.

[kapilhp]

The version of sommelier that I am working on (based on git-versioned sommelier) does not have the problems outlined by @satmandu.

Regarding running a proper Desktop environment. I have not tried this. However, what I have tried and works is to use sommelier to start a second Xwayland (for example by a script like the following):

#!/bin/bash
Xwayland :1 &
DISPLAY=:1 i3 &

The default Xwayland is "rootless" and does not support a window manager. Under the second Xwayland it may also be possible to run a Desktop Environment---I have not tried.

It may be true that sommelier is "too much" for what we need. The "host-wayland" script can also start some graphical utilities. However, it does not trap the key and mouse events!

[kapilhp]

In continuation of the above, it seems to me that the sommelier target is primarily the replacement for xiwi.

To run something similar to starti3 under wayland, one can do the following:
1; First run sudo enter-chroot.

1. Run a script like the following (you may need to replace ":0" if you already have some server for that:

#!/bin/sh
XDG_RUNTIME_DIR='/var/run/chrome' Xwayland :0 &
DISPLAY=:0 i3 &

Of course, this will not do session management and so one should be doing something like xinit instead of starting Xwayland and i3 separately. However, it seems to give some version of a graphical desktop that is almost usable (see below).

This seems to mask many of the keys which are not masked if one uses host-wayland to run a wayland application like lxterminal. However, it still does not mask search+[ or search+] which would be confusing. I am not sure whether that is possible and if so, how one can do that.

[kapilhp]

To continue, one can create $HOME/.xinitrc containing:

#!/bin/bash
xsetroot -cursor_name left_ptr
exec i3

and $HOME/.xserverrc containing:

#!/bin/bash
XDG_RUNTIME_DIR=/var/run/chrome exec Xwayland

After this running /usr/bin/xinit creates a fullscreen window managed by Chromium under which one is running i3 almost as usual.

The main problem is that key combinations that are not trapped by other fullscreen windows in Chromium are also not trapped here.

In any case, this is getting off-topic. I just wanted to re-iterate that running full screen graphical desktops does not appear to require sommelier at all!

[kapilhp]

The keys that are not available to Xwayland and other apps are explained in the link:

https://chromium.googlesource.com/chromium/src/+/HEAD/ash/accelerators/accelerator_table.h#22