Fedora 25 to Run Wayland by Default | Hacker News Reader

Fedora 25 to Run Wayland by Default

phoronix.com

60 pointsXzetaU828 comments

Does this mean remoting is available? I can't find anything recent and definitive, but the FAQ still says no. I've never understood how Wayland can even be considered usable without it. "The user owns exactly one computer" hasn't been true for a decade or more.

What do you mean by remoting? Are you talking about X11 forwarding in which case it's highly unlikely due to it not being X11.

I have access to many computers but only one of them is literally plugged into my monitor. Can I use Wayland over a network?

One could use Windows and OS X machines that way since forever, without them offering "Remote X11" sessions, so yes...

Um, that may be true on paper, but instead of using bandwidth heavy VNC or braindead systems that require you to log off locally before you can login remotely, X11 offers you a responsive and flexible solution.

Wayland is a protocol for efficient buffer sharing and windowing semantics. It can be seen as the equivalent to CreateWindow and friends on Windows -- we use binary protocols instead of C APIs, but the idea is the same.

What Wayland is not is a protocol designed for remote transport over TCP. Neither was X11, mind you. There are other, better, protocols like this, like RDP, VNC, and SPICE. These protocols use techniques from video compression and instead of shared memory.

You can use VNC and RDP with Wayland.

What do you mean when you say "neither was X11"? X11 most definitely is designed to be network transparent. After all, that was the whole concept behind X-terminals.

Also, VNC is nothing like the network transparency of X11. In X, I am able to run a single application on one machine, connecting to an X server running on a different machine. The application will be a first-class citizen in the user environment. This is in contrast to the VNC case where it lives in a separate desktop that is forwarded as a whole to be displayed in a window on the receiver side.

I used to think the same way regarding Wayland. But then I realized the abysmal state of X11 remoting: most applications I would like to use remotely are basically sending images over the network, instead of just API calls. Try using Firefox over X11 forwarding. I think some battles have been lost in this regard.

The creators of Wayland decided that it is not their task to handle remoting. You could argue that this demphasizes the issue, leaving it to insufficient VNC, dead projects like NX, or not yet production ready projects like X2Go (once they support Wayland that is).

Guacamole? https://guacamole.incubator.apache.org/

> The creators of Wayland decided that it is not their task to handle remoting.

That seems to be their decision but I can't imagine what's motivating them. How is the non-remote use case even relevant at this point? Is Wayland intended for console gaming?

If you need that feature, X11 is probably for you. Not supporting a feature is a difficult, albiet important, choice. If it's not remoting, it's 100 other features that would turn Wayland into X11. Omission differentiates as much as innovation.

I just got a 4k laptop, but my monitor is 1080p, so I'm excited about Wayland getting better faster (it's the only good way I know of to have different scaling across displays). I'm still finding all sorts of weird quirks in Linux with 4k...but, I'm also still finding quirks in lots of Windows software, too (games and music software, in particular, are prone to using their own UI toolkits and end up looking ridiculous because of it). So, I can't blame Linux for all of those problems; it's just a tricky problem, I guess.

This is one thing that Mac seems to have gotten perfect nowadays, I connect my retina laptop to non-retina monitors, and every seems to work fine, all the time.

Apple made one massive simplification -- apps only run at 1x size, or 2x size, and nothing else. This isn't theoretically "nice", but (for me) covers most use cases, and seems to have made the implementation much easier, as you can still design your interface pixel-wise, and just let the OS double scale everything.

OSX's scaling system is actually more flexible than just 1x and 2x. I often run my 4K monitor at the effective 1440p resolution. Applications such as Retina Display Manager let you choose between many more scaling sizes than the standard system settings.

AFAIK that's scaling the display, not scaling the applications?

OS X can only scale by powers of 2. If your monitor runs at native 4K (3840x2160), scaling ~1.28x renders to 6016x3384 and scales down by 2x to 3008x1692. Your example is at 1.5x (2560x1440), which renders to 5120x2880 and scales down by 2x to 2650x1440. The most efficient scale is 2x (1920x1080) because that can be rendered natively. So while you can have arbitrary effective resolutions, it's rather wasteful to render and can have serious performance implications when you're not using native or powers of 2.

It seems like that would be an easy solution; but, for probably good reasons (though reasons I don't know), Windows and Linux don't do it that way.

Gnome applications of recent vintage behave correctly, pretty much across the board. Firefox has some of its own configuration (for content, but the Gnome settings get applied to the UI), but behaves OK once configured. It's all the non-Gnome stuff that gets weird. Mostly games and music and graphics apps that don't use the system toolkit. Unfortunately, those are just the apps I most want to be able to cram a gazillion pixels onto the screen.

I'm tinkering with audio again, on both Linux and Windows, and VSTs, in particular, are awful. Unusably small, in many cases (VSTs are, IMHO, already the ugliest UIs in the world). At least most of my actual software works OK; FL Studio go an update recently that make it's UI vector-based, I guess, as it is fully scalable across any size screen, and looks really good at any size.

For reference on the ugliness of VST plugins (many of these are laughably expensive, like in the multiple hundreds of dollars for usually very simple DSP algorithms wrapped up in a ridiculous GUI):

https://www.google.com/search?tbm=isch&q=vst%20plugins

Now, just imagine them shrunk down to the size of a postage stamp...it's kinda like the thumbnails on image search, actually, on my 15" laptop display.

Great, this is an important milestone we've been waiting years for. No doubt there will be lots of problems, but that's the first step in getting them fixed.

What about Redshift on Wayland :(?

For Redshift, I rely on actual red glasses. You can find these on Amazon etc., search for "UV protection glasses". The advantage is that these work with any screen, even with paper books. The disadvantage is that you have to remember to put them on. :)

Needs to be implemented in each compositor, like most other missing details on Wayland.

Actually... Wayland fully supports transparent windows assuming you have a buffer with alpha transparency, and windows have no decoration by default. It would take a very small protocol extension to allow overlay windows which don't accept input of their own, allowing for Redshift (and other tinting tools, such as those for dyslexia) to implement such an extension without embedding it into a compositor.

Wayland has a process for standardising extensions - write the XML file defining it and send an email to the mailing list, then respond to questions - if developers cared about Wayland, they could do it.

Redshift (or flux) doesn't work that way. It adjusts the monitor's color temperature using XRandR.

Alright, though my latter point stands - standardising an extension for setting colour temperature would not be terribly difficult. You could look to libcoopgamma for ideas on managing multiple clients trying to change things at once, or write a simpler protocol that only allows one client to change things. At the very least, an unstable protocol definition and a patch for Weston would be a lot more than what we have now, and doesn't require Redshift to be cloned for each Wayland server.

FreeBSD is making progress on this, too: https://lists.freebsd.org/pipermail/freebsd-current/2016-Aug...

Misleading title. The decision here is to leave Wayland on but it can still get pulled later if it is deemed to not work well enough.

This is correct and the comment should not have been downvoted. (The article is wrong.) This is essentially just about allowing Wayland to remain the default during alpha, but it can very well be removed as default later on.

i'll believe it when i see it

Reply on news.ycombinator.com