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).

Comments

Chrome

[Anonymous Coward]

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.

Re:Chrome

[Anonymous Coward]

It's a replacement for X11 on ChromeOS. Not a replacement for X11 in general. Also, since X11 is getting removed from ChromeOS in favor of Freon, it is, by definition a replacement. If you don't need all of the functionality of X, you can replace it with something simpler.

The Browser is NOT the OS

[duckintheface]

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.

Re:The Browser is NOT the OS

[jedidiah]

Relative to Google's own requirements for Chrome, it's an improvement. Relative to someone interested in a real OS or Linux in particular, Chrome already jumped the shark anyways.

Freon? You gotta be kidding:

[Hartree]

You mean Freon as in R-11 or R-12 which increase the ozone hole and were banned? (It's Dupont's trademark. Wonder if they asked first.)

Is the next release gonna be named Thalidomide? Or maybe Dimethyl Mercury?

Let me guess

[RightwingNutjob]

Network transparency is not supported because noone uses it.

Re:Let me guess

[RightwingNutjob]

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.

Re:Let me guess

[DrXym]

You can't "improve" X11 without making it not X11. e.g. make IPC async and it's not X any more. And at that point you may as well ditch the lot and write it properly, taking advantage of the hardware that every modern PC has to render a desktop decently locally first (the common use case) and taking advantage of existing remoting tech to take care of the uncommon use case. And that's what Wayland does - it describes a protocol for a client application to talk directly with a window manager that cuts X11 out of the picture.

Weston already demonstrates built in RDP support. It wouldn't be a stretch to imagine VNC or other protocols appearing in time to serve different remoting scenarios. I'm sure that unless you're expecting to play video or games in realtime they would suffice and if you are expecting to play video or games in realtime there are better ways to do those things already.

Re:Let me guess

[raxx7]

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.

Re:Let me guess

[Uecker]

You can't "improve" X11 without making it not X11. e.g. make IPC async and it's not X any more.

First, one can extend X11 fairly easily, this has been done in the past. Second, X11 already has asynchronous IPC. Wayland copies this model exactly: Async IPC over a UNIX domain socket (locally). There is no fundamental difference or improvement here.

And at that point you may as well ditch the lot and write it properly, taking advantage of the hardware that every modern PC has to render a desktop decently locally first (the common use case) and taking advantage of existing remoting tech to take care of the uncommon use case.

Again: bullshit. X11 can do take advantage of the hardware in exactly the same way as Wayland. So this whole argument is build around the misconception that X11 is slow because of something it does to support remoting. This is not true: 1. X11 is not slow (Valve found OpenGL on X11 to be faster than on Windows). 2. Direct rendering essentially works in the same way as Wayland (atleast with DRI3).

And that's what Wayland does - it describes a protocol for a client application to talk directly with a window manager that cuts X11 out of the picture.

So maybe combining the compositing manager and the server into one piece has a small advantages. I doubt this. But if this is the case, this could be done with X11 as well. No need to ditch a protocol with decades of compatibility.

Weston already demonstrates built in RDP support.

I don't want RDP. RDP is not compatible with X. RDP is also a propriertary protocol fron Microsoft with a core standardized by the ITU. I sure hell to not want this as a replacement for X.

It wouldn't be a stretch to imagine VNC or other protocols appearing in time to serve different remoting scenarios.

Yes, implement X. Then come back.

I'm sure that unless you're expecting to play video or games in realtime they would suffice and if you are expecting to play video or games in realtime there are better ways to do those things already.

I am not playing games. I want my new applications to work with old display servers and old applications to work with new servers. I also want to have perfect integration of remote applications. This is not really about shuffling bits.

Re:YANIH

[dmbasso]

I don't think Bazaar can be included in the NIH set, as upstart and mir can. When they started working on Bazaar, there was no distributed VCS that was as simple and intuitive as what they had implemented. I've used Darcs before switching to Bazaar, and though I don't remember specifics, I remember feeling much more comfortable using bzr. In the end, git is the clear winner of the DVCS race (Mercurial folks might disagree with me), but you can't blame Canonical for investing in their solution (a very good one, imho). Btw, bzr was first released two weeks before git's first release.

Re:YANIH

[serviscope_minor]

Screw idealism, you'll take X and it's fifty million extensions from my cold dead hands!

I love how X is the only system that people complain about when it gets API updates while remaining backwards compatible. Are you going to stop using Wayland when it progresses on from the 1.0.0 release or are you fine because it doesn't call new API calls "extensions"?

And I like my start up scripts like I like my Egyptian tombs, hard to understand and full of things to trap and destroy you!

I prefer hard to understand over impossible to understand. And before you claim that systemd is easier to understand, please make the ACPI sleep key send my laptop to sleep under systemd. So far many people have told me how systemd is "simpler" but no one has been able to help me fix this really simple problem. It worked just fine under the old system.

Oh yeah and to boot, my system boots slower!

So, um yay?

Re:Linux is not an OS

[Dragonslicer]

Linux is just the kernel, maybe the heart of the operating system, but not the OS itself. The OS is the kernel and the whole bunch of other stuff that allows you to run the program you click, type or tap at.

That depends on exactly how you want to define "operating system". You can make the argument that the "operating system" really is just the kernel, and that everything else, including the X server, are user-level programs. In particular, this is true in Linux, where many system services that some people would consider part of the operating system are just normal processes.