Arch Linux User Repository

@thagabe This is known issue and nothing to do with Arch: https://bugs.chromium.org/p/chromium/issues/detail?id=1000966

Issue: Garcon does not connect to "Files" on ChromeOS

Currently on:

- ChromeOS BETA 78.0.3904.70 Pixelbook i5

- Arch container for ChromeOS x86

- Kernel 4.19.69-06666-g6c4f8cbba24e

- systemd 243.78-1

- journalctl -p 3 -xb:

        Oct 26 14:52:49 penguin garcon[122]: [122]: MIME types file does not

                         exist at: /home/<my home user>/.mime.types

        Oct 26 14:52:55 penguin garcon[122]: [122]: MIME types file does not

                         exist at: /home/<my home user>/.mime.types

        Oct 26 14:54:51 penguin garcon[122]: [122]: MIME types file does not

                         exist at: /home/<my home user>/.mime.types

        Oct 26 14:57:47 penguin garcon[122]: [122]: Failed reading in config

                         file: /home/<my home user>/.config/cros-garcon.conf

        Oct 26 14:57:48 penguin garcon[122]: [122]: Failure with

                         RefreshCache of: Failed to obtain authentication.

        Oct 26 14:57:48 penguin garcon[122]: [122]: Failure performing

                         refresh of package cache, code: 2

        Oct 26 15:01:13 penguin garcon[122]: [122]: MIME types file does not 
                         exist at: /home/<my home user>/.mime.types

@sovanyio No issue with xkeyboard-config for me. Up-to-date arch in the container (testing is on) and Chrome OS 78.0.3904.50 (Beta channel).

@sovanyio If you use sommelier without the full path, you need to add it to the PATH - this is what you need to do you your side and not related to this package itself.

About Eclipse - I was able to google multiple guides about how to configure HiDPI support for it. I personally don't use it, but was able to configure both Netbeans and IntelliJ IDEA to proper render without sommalier "workaround".

Issue with xkeyboard-config looks familiar, but it was addressed long ago. May be this is something new, I will double check. Are your Arch up-to-date? Which ChromeOS channel / version are you running on Pixelbook?

Yeah, so I'm on a pixelbook and I run usually at 80% scaling in ChromeOS. When using the debian container, I typically modify desktop files under /usr/share/applications/ with sommelier -X --scale=.8 --dpi=160 %command and this works very well across apps I use (sublime text, atom, eclipse, intellij).

OOTB adding the sommelier command results in:

$ xdg-open atom.desktop
/usr/sbin/env: 'sommelier': No such file or directory

and the associated desktop file being passed to Chrome is ChOS (which "opens" as a tab).

I ended up appending the cros-tools bin directory to /etc/profile and that appears to be working as expected, though I get another error with that addition, added below.

$ xdg-open atom.desktop 
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported high keycode 382 for name <I382> ignored
>                   X11 cannot support keycodes above 255.
>                   This warning only shows for the first high keycode.
> Internal error:   Could not resolve keysym XF86MonBrightnessCycle
> Internal error:   Could not resolve keysym XF86RotationLockToggle
Errors from xkbcomp are not fatal to the X server
[$USER@penguin applications]$ 
(electron4:565): Gtk-WARNING **: 18:00:07.964: cannot open display: :2

Is this now additional incompatible keys in xkeyboard-config? Perhaps expected but should note anyway that launching through ChromeOS GUI fails for both of these situations.

Without setting scaling explicitly through sommelier, the default settings screw up the dpi and scaling on eclipse making it completely unusable (though text is sharp) UI elements are way larger than expected and its generally not a fun time.

@sovanyio can you provide more information? First of all, there is 2x scaling using sommelier available out-of-the-box using right click menu in the task bar (this is achieved using separate sommelier instance with 2x scaling). Also, sommelier scaling is not the best from the point of view of visual quality - proper HiDPI support configuration like https://wiki.archlinux.org/index.php/HiDPI gives much better result.

Anyone having issues with sommelier prepends in *.desktop files for high-dpi scaling?

Apps don't launch for me then, but do work if I use the command manually. Thinking it could be due to the tools not being on PATH for the services.

Dependency added, thanks @drelyn86!

Sommelier uses xdpyinfo from xorg-xdpyinfo to detect DPI scaling.

Following change added : "Configure Control+Space passthrough for Sommelier"