wxWidgets applications on ChromeOS / Crostini - findings

35 views
Skip to first unread message

Vojtěch Bubník

unread,
Mar 16, 2021, 5:04:48 AMMar 16
to wx-u...@googlegroups.com
As you may know, Google supports Linux applications on ChromeOS through a virtualization layer called Crostini.


Chromebooks are being rapidly adopted by US schools, thus we want our PrusaSlicer software to run on Chromebooks as well. These are my findings in regard to PrusaSlicer on ChromeOS / Crostini, which may be relevant to Kicad or Audacity teams as well:

I was pleasantly surprised how well the Linux integration works. By default a relatively small Debian 10 image gets installed, which contains both GTK2 and GTK3 images, thus a Linux AppImage will most likely run without having to install another dependencies. Our PrusaSlicer runs quite well. There is a service running on that virtualized Linux, that detects desktop integration files and automatically adds a starter icon into ChromeOS task bar. Accelerated OpenGL is being virtualized through virgl on newer models and its performance is quite good.

For application distributions, AppImage and FlatPak just work. FlatPak is not installed by default, but installing it is trivial:


We have experienced the following glitches though:

1) Swapped red/blue channels in OpenGL when multi-sampling was enabled, see 


Most likely it is a bug in the OpenGL hardware virtualization layer virgl. We worked around it by detecting Chrome OS and disabling multi-sample anti-aliasing in our application on Chrome OS. It may be an OpenGL initialization issue in wxWidgets as well though.

2) Some file system glitches. Namely, some ChromeOS directories are being shared with the Linux virtual machine using 9p filesystem, and the 9p filesystem is configured to not allow setting file attributes.

We are having this issue:

however libreoffice experiences another issue:

3) Window manager issues: Window tilte bars are blank by desing, but they are there by default just eating space on the tiny screen. We cannot do much about it, but we can enter fullscreen mode on application start.


4) Entering full screen. Due to the issue 3) and because the screens on Chromebooks are tiny, there is a button on the keyboard in the first row to enter full screen mode. For example on xterm this removes the application title bar and frame. The same applies to our competitor software Cura written in Qt. For wxWidgets based applications the button does nothing, no key event is being delivered to the wxWidgets application. However manually calling wxFrame::ShowFullScreen() works.

5) When in full screen mode, Alt-Tab is passed surprisingly to the application. This has been done to support remote desktops I suppose, but it is very weird for normal desktop applications and I suppose most users would avoid to t enter full screen mode due to this issue. Is it possible to not consume the Alt-Tab events by wxWidgets?


6) Chromebook keyboards have the 1st row of keys switched to "browser back, browser forward, refresh, full screen, .....". The first row may be switched to function keys (F1..F10) in setup, also the "search" key plus the 1st row sends an F key. For the Linux wxWidgets apps, only the browser back, browser forward buttons are passed to the application with WXK_BROWSER_BACK, WXK_BROWSER_FORWARD. The other keys, namely the "full screen" key are not routed to the Linux application (maybe they are, but not translated to wxEvents).

7) Also the Chromebooks are equipped with touch screens. On Windows 10, two-finger multi touch events are automagically translated to mouse events: Zooming gesture translates to scroll wheel events, two finger moves translate to right mouse dragging. I did not have a chance to test that on Linux / GTK, but on ChromeOS all gestures work as left mouse click or left mouse dragging only. Zooming and right mouse events are not simulated. I have no idea whether the screen touch behavior on Crostini is Crostini specific, or whether this is how it works on Linux / X11 / GTK2/3. Is there any plan for such Linux / GTK mouse emulation through multi-touch gestures?

8) USB passthrough works just for enumerated devices, which are hard coded somewhere in ChromeOS. The white list may be managed by the admin tool managing network of ChromeBooks, but we don't have access to it. Thus updating firmware to our printers does not work by default.


Vadim Zeitlin

unread,
Mar 19, 2021, 2:44:04 PMMar 19
to wx-u...@googlegroups.com
On Tue, 16 Mar 2021 10:04:35 +0100 Vojtěch Bubník wrote:

VB> I was pleasantly surprised how well the Linux integration works. By default
VB> a relatively small Debian 10 image gets installed, which contains both GTK2
VB> and GTK3 images, thus a Linux AppImage will most likely run without having
VB> to install another dependencies. Our PrusaSlicer runs quite well.

This is indeed great news, thanks for sharing!

VB> We have experienced the following glitches though:
VB>
VB> 1) Swapped red/blue channels in OpenGL when multi-sampling was enabled, see
VB>
VB> https://bugs.chromium.org/p/chromium/issues/detail?id=1187819&q=virgl%20prusa&can=2
VB>
VB> Most likely it is a bug in the OpenGL hardware virtualization layer virgl.
VB> We worked around it by detecting Chrome OS and disabling multi-sample
VB> anti-aliasing in our application on Chrome OS. It may be an OpenGL
VB> initialization issue in wxWidgets as well though.

If it's a bug in wx, it should be fixed, of course. Do any other
applications using OpenGL (with multi-sample) show this issue? But it might
be better to wait until the bug above gets looked at.

VB> 4) Entering full screen. Due to the issue 3) and because the screens on
VB> Chromebooks are tiny, there is a button on the keyboard in the first row to
VB> enter full screen mode. For example on xterm this removes the application
VB> title bar and frame. The same applies to our competitor software Cura
VB> written in Qt. For wxWidgets based applications the button does nothing, no
VB> key event is being delivered to the wxWidgets application. However manually
VB> calling wxFrame::ShowFullScreen() works.

Do you know which key code this key generates at GTK level? It's probably
simple enough to map it to some (new) WXK_FULL_SCREEN, we just need to know
what its value is.

VB> 5) When in full screen mode, Alt-Tab is passed surprisingly to the
VB> application. This has been done to support remote desktops I suppose, but
VB> it is very weird for normal desktop applications and I suppose most users
VB> would avoid to t enter full screen mode due to this issue. Is it possible
VB> to not consume the Alt-Tab events by wxWidgets?

I am not sure if we really want to filter out these events if we do get
them. It's simple enough to check for them in the code and, if you really
want to get rid of them globally, you can do it in overridden
wxApp::FilterEvent().

VB> 6) Chromebook keyboards have the 1st row of keys switched to "browser back,
VB> browser forward, refresh, full screen, .....". The first row may be
VB> switched to function keys (F1..F10) in setup, also the "search" key plus
VB> the 1st row sends an F key. For the Linux wxWidgets apps, only the browser
VB> back, browser forward buttons are passed to the application with
VB> WXK_BROWSER_BACK, WXK_BROWSER_FORWARD. The other keys, namely the "full
VB> screen" key are not routed to the Linux application (maybe they are, but
VB> not translated to wxEvents).

Again, if you could please look up the GTK key codes, we should be able to
map them to something.

VB> 7) Also the Chromebooks are equipped with touch screens. On Windows 10,
VB> two-finger multi touch events are automagically translated to mouse events:
VB> Zooming gesture translates to scroll wheel events, two finger moves
VB> translate to right mouse dragging. I did not have a chance to test that on
VB> Linux / GTK, but on ChromeOS all gestures work as left mouse click or left
VB> mouse dragging only. Zooming and right mouse events are not simulated. I
VB> have no idea whether the screen touch behavior on Crostini is Crostini
VB> specific, or whether this is how it works on Linux / X11 / GTK2/3. Is there
VB> any plan for such Linux / GTK mouse emulation through multi-touch gestures?

Sorry, I'm completely lost myself in Linux/GTK multitouch support, I don't
even know at which level is this supposed to happen. We do have gestures
support in wx itself, see wxWindow::EnableTouchEvents(), but I'm not sure
if this is really what you need...

Good luck,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Reply all
Reply to author
Forward
0 new messages