Live data from Hacker News

Wayland in 2021

shibumi.dev

121–130 of 146 posts

Re: Wayland in 2021

#121
post #13

Earlier quoted context omitted.

Nvidia works with wlroots if you use nouveau and not the proprietary drivers.

As much as I appreciate Noveau, it's not really practically usable with recent cards (due to Nvidias faults!).

It's probably not relevant in the long term anyway. I expect desktop Nvidia usage on Linux to pretty much plummet while their driver remains a blob. The trend is negative for them already.

So I fully support wlroots developer's approach to it - show Nvidia to the door until they come back with upstreamed driver.

Re: Wayland in 2021

#122
post #18
post #7

Earlier quoted context omitted.

I don't expect them to ever work properly. Basically, if you care about good Wayland user experience and proper desktop integration, you should be using AMD or Intel GPU already. Waiting for Nvidia to fix this mess is pointless. Nvidia will be DOA as long as they refuse to upstream their driver or to support Nouveau to begin with. And they didn't show any interest for years.

For Nvidia this is not a mess; they support X for their supported use-cases and that's just it, and X works pretty much perfectly for me now, even PRIME is essentially issue-less. I give them a lot of credit for making Nvidia GPUs in laptops on Linux as viable as on Windows.

PRIME is working for you? How? I couldn't get it working at all. Are there any guides for this?

Re: Wayland in 2021

#123
post #52

Earlier quoted context omitted.

Do any desktop system handle mixed DPI well? I mainly use Linux so I don't know, but one of my work laptops have windows on it and it freaks out every time I connect it to a 4k monitor. At least in linux I can use triggers and xrandr [1] to manage it even if it's not pretty, never figured out how to do it automatically in windows. Edit: I am using KDE/Qt apps for 99% of my gui stuff. Gnome etc might be worse. [1] htt…

Works perfectly on Wayfire and I assume Sway. I briefly tried out Gnome and KDE, with the former "meh" (no fractional scaling, scaling glitches when dragging between displays) and the latter garbage (couldn't find scaling settings at all, so nothing is readable on the laptop display). Widows is between "okay" and "nice" (somewhat fractional scaling, glitches between displays, some wrong scalings, but it's rare). I ha…

KDE scaling settings are pretty obviously in the Display Settings page so I'm going to say that one is user failure.

Re: Wayland in 2021

#124
post #118

Earlier quoted context omitted.

All the old X apps used xrdb, to some degree. I think of xclock, xbiff, xditview, xcalc, bitmap, etc.

Everyone stopped using xrdb more than twenty years ago, same things for drawing primitives. I understand the wish some seems to have for things to never change. It's probably very comforting but things have to move with their time or they will be left behind.

I'm not saying applications should continue to use or go back to xrdb. I'm pointing out the fact that having unified configuration system is very useful and I'm disappointed Wayland didn't pick up this idea.

Re: Wayland in 2021

#125
post #52

Earlier quoted context omitted.

Do any desktop system handle mixed DPI well? I mainly use Linux so I don't know, but one of my work laptops have windows on it and it freaks out every time I connect it to a 4k monitor. At least in linux I can use triggers and xrandr [1] to manage it even if it's not pretty, never figured out how to do it automatically in windows. Edit: I am using KDE/Qt apps for 99% of my gui stuff. Gnome etc might be worse. [1] htt…

> Do any desktop system handle mixed DPI well? MacOS handles it very well, moving a window from a high-DPI display to a low-DPI display works perfectly. I'm not sure about how Windows handles mixed-DPI, but it handles DPI changes mostly OK. I only access my Windows machines via RDP, so sometimes they get a high-DPI display and sometimes they get a low-DPI one. Apart from one program (there are per-program settings av…

IME mixed DPI under Windows is a mixed bag, with behavior varying on an app to app basis. For instance Telegram (Qt) can’t deal with being moved from one screen to the other and will look either tiny or huge, but most Win32 and WinUI apps work just fine.

This distinction doesn’t exist on macOS for the most part, even “foreign” UI libraries will appear the correct size when changing screens.

Re: Wayland in 2021

#126

Earlier quoted context omitted.

Probably how the scaling is off while you drag windows from/to hidpi displays. The scaling is only adjusted once the pointer moves to the other display. At least that's how it was for me when I used a high dpi display (160 dpi) 2 yrs ago. (I switched back to 90dpi at some point, so they might have improved it by now)

Mac OS X handles this by rendering everything at some insane resolution and the scaling just before displaying

That only applies for non-integer scales. If you run at clean 2x or 3x everything is drawn at native scale, unless the app doesn’t support HiDPI in which case it’s drawn at 1x and scaled up.

Re: Wayland in 2021

#127

Earlier quoted context omitted.

Mac OS X handles this by rendering everything at some insane resolution and the scaling just before displaying

That only applies for non-integer scales. If you run at clean 2x or 3x everything is drawn at native scale, unless the app doesn’t support HiDPI in which case it’s drawn at 1x and scaled up.

This explains why non integer looks so good.

Re: Wayland in 2021

#128

Earlier quoted context omitted.

ibus works with Gnome out-of-the-box. On sway/wlroots, you will have more luck with fcitx. I don't know which tool works best with KDE.

Why, in Wayland, support of some basic features has to do with what DE or TWM you use? It is not like this in X11 and it seems there is more adherence to the UNIX philosophy in X11.

There's no "Wayland" that could implement a generic way of handling input. Wayland is an extensible set of protocols with several implementations.

Handling input is an integral part of what a compositor does, and it's not an easy problem to solve when said input doesn't map linearly to text.

Input methods in particular are not something that X11 "solves" at all: Under X every toolkit implemented their own way of handling complex input methods. XIM existed, but it was limited and only there for compatibility with ancient applications.

There are Wayland protocols for complex input methods too. Gnome's gone all-in and integrated ibus with their own compositor, so that obviously works, but Gnome also benefits a lot from distributions like Fedora making sure it works: everything is set up correctly out-of-the-box if you use Gnome. However, more niche implementations like Sway have to deal with a lower level of integration because there's no distribution that's built around Sway to create a full desktop environment.

Re: Wayland in 2021

#129
post #118

Earlier quoted context omitted.

Everyone stopped using xrdb more than twenty years ago, same things for drawing primitives. I understand the wish some seems to have for things to never change. It's probably very comforting but things have to move with their time or they will be left behind.

I'm not saying applications should continue to use or go back to xrdb. I'm pointing out the fact that having unified configuration system is very useful and I'm disappointed Wayland didn't pick up this idea.

Wayland reflects status quo. Truly desired missing features are reimplemented — screenshots, screensharing, networking. Try to make a change, maybe you'd find out this feature is not that useful.

I'd better think why .Xresources never catched up. For example, I've downloaded Gnome theme. It contains some CSS files, a lot of images and some rc files. Or check about:config, chrome://flags/ — no images there, but interface is so much nicer than a list in man pages and plain text editing.

Re: Wayland in 2021

#130
post #106

Earlier quoted context omitted.

> A unified way to change applications settings. This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings > because the X server takes care of most of the stuff. ... , unless using a big library like wl_roots. So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? > A base graphics API based on drawing primitives like th…

> This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings That's why I said Wayland and the modern desktop in general. > So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? You're kind of right: conceptually it's not much different, except that a wm is not a full-fledged server, but simply a client talking to the X s…

Just think for a minute, entire industry abandoned xrdb and drawing primitives in X11 applications, even XOrg developers decided to ditch these features, they've started Wayland because they could not fix X11.

Either you are unbelievably smarter or you know nothing.

Post reply on HN