Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

HiDPI. It's somewhat unusual for a top end laptop to have 1920x1080 screens these days, and Wayland doesn't support 4k very well. You can upscale, but it looks like garbage, or it has a 2x mode, which draws image and such slightly too large, or you can deal with everything being tiny.

For gaming, the latency is bad and always on vsync is horrible. They've fixed the 60Hz lock though, fortunately. This only applies to gaming though.

My primary issue with Wayland isn't quite so much that it lacks these things, it's that they seem to be of the opinion that there's only one way to do things, and any other use of the visual display system is wrong. I just have this weirdly oppressive feeling about my inability to configure it the way I want it, the same feeling I get from using Windows. Just... let me be me. I get that this is a non-technical complaint, and that it ultimately boils down to "it gives me the heebie jeebies" which isn't an argument, but it's still how I feel about it.



HiDPI? Um, what?

I've been running Wayland gnome-shell on Fedora since Fedora 25, on a Dell m3800 and now a Dell XPS 15, both with 4K internal displays. I often connect to external monitors or projectors, either 1080p or 4K.

Wayland has better HiDPI support than X and has for a long time.

In order to make X work in any reasonable way you need to configure X to render at 4K all the time on all outputs and downscale using xrandr on 1080p displays. X cannot handle different DPI settings.


>For gaming, the latency is bad and always on vsync is horrible. They've fixed the 60Hz lock though, fortunately. This only applies to gaming though.

So there is no way for a game to bypass wayland and write directly to the fullscreen framebuffer? You're just stuck with an extra frame or two of latency?


The idea of using DRM Leasing to allow the full-screen app to exclusively grab the framebuffer for itself has been floated around.

I'm not sure how graceful the alt+tab behavior of this approach would be though.


A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.


That is the problem right? Whenever there is a functionality that you could get with X11 by tweaking configurations files you have to write you own complete new Display Server in Wayland to have that functionality.

This is especially true for people that prefer low latency over tear-free rendering.


I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic. Now, people complain about there being competing Wayland implementations with different feature sets. What's it gonna be, guys?


Those complaints aren't actually opposed but perfectly complement each other.

Wayland requires* everything to be monolithically built into the display server (which is also the window manager), which means if I want to use a new WM (say, XMonad) I need to reimplement all of this stuff. Want screenshots? Build it into your WM! Want redshift? Build it into your WM! The result is that development effort will be wasted reimplementing "competing Wayland implementations" stuff that no-one actually wants.

Compare X11, where I could run an Xorg server together with any of a number of lightweight window managers, and the window manager is only responsible for, y'know, managing windows, and determining how the window decorations look. Xorg handles everything else, allowing a robust marketplace of competing WMs to arise.

* Unless/until they finally give in and standardise protocol extensions for out of process window managers.


>I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic

? what? you mixed systemd with wayland maybe, everyone knows that wayland is a protocol, this is repeated 100 times in each thread , everyone also knows that most of X features are not part of wayland


I don't think any of those problems can be solved solely in the compositor - they all require co-operation between it and the actual apps. Which means, in practice, that you'd probably have to create an entirely new version of the Wayland API for creating and managing windows, add it to all the compositors, and get all the apps to use it too, on top of all the other work involved in fixing those issues. (This is the only real way to extend the protocol and has already been done a few times - the most recent one I remember was to add the ability to minimize windows.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: