Slashdot Mirror
Google Introduces Freon, a Replacement For X11 On Chrome OS
An anonymous reader writes With this week's release of Chrome OS M41, there is the new Freon graphics stack to replace X11 on some platforms. Freon is a very limited graphics stack to replace Chrome OS usage of X11/X.Org by having the Chrome browser communicate directly with the Linux kernel's KMS/DRM API and OpenGL ES interfaces for drawing. This design is much simpler and yields various power and performance improvements though it's not based on Wayland nor Mir (though Chrome plans to support these display server models).
If Chome browser IS the OS, then what they have is an embedded video driver. It's not a X11 replacement anymore than FB interface is a replacement for X11.
Here I'm assuming that "KMS/DRM" refers to "kernel mode setting and direct rendering manager", not anything to do with "digital restrictions management" such as establishing a protected video path for use with the Content Decryption Module draft stuff in HTML5.
and develop R22 as a replacement.
Never answer an anonymous letter. - Yogi Berra
Marketing gibberish aside, the Chrome browser is not the OS. The OS also happens to be called Chrome but it is just a variant of Linux. And the Chrome browser is a browser, not an operating system. Google wants to limit your applications to those that run in the browser to sort of simulate the "browser is the OS" look and feel, but that's not really what's going on. The confusion is intentional.
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition
And my reply is always the same: if you make a change, improve the whole system; don't make compromises to core functionality for the sake of cosmetic improvments. Bells and whistles in the window manager are cosmetic. Being able to display output (from a single window, mostly text and line art graphs, not the whole damn desktop) to a different machine across the building is not cosmetic, it is why I use Linux instead of Windows. Maybe X11 doesn't let you do some things that really are better (I wouldn't know, the only annoyance I have ever found with X11 code is that its error handler calls exit(-1) if it panics without letting you deal with it in the calling program, meaning you have to split display and core logic into two processes instead of being able to keep everything in one address space), but network transparency (what else do you call being able to say DISPLAY=whatever:X.Y my_program) is a core capability that people do use, and you won't get them on board if you turn it into an afterthought.
99% of people don't want X11 style network transparency. They want "ssh -X" and friends to work. They want to be able to remotely run individual graphical applications.
But X11-style network transparency isn't the only way. And it's not the best way.
Despite all the features available in X, application developers give limited effort to making applications work well over high latency limited bandwidth. An increasing number of applications work poorly over this links. Qt4 applications with the default raster backend work poorly sometimes even my workplace's GbE LAN (Qt5 doesn't even give you the option). Let's not even think of running Kate from home.
No application I actually use supports detaching and re-attaching to a different X server.
People have been pushed to replace "ssh -X" with NX and Xpra (or, in despair, VNC) because of these limitations (Google about them).
Similar solutions can be implemented in Wayland and they don't need the protocol to become networks transparent.
Supporting X11-style network transparency in the Wayland protocol is a futile exercise which compromises the simplicity required by the Wayland model.
Not to mention, if "ssh -X " and friends suits you... then it will work for a long time. As long as your Wayland session includes XWayland (which it will, probably for ever) and your applications retain a X11 backend, this will still work.
It's not going to die tomorrow just because we switch to Wayland compositors.