Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wayland Protocol Finally Ready for Fractional Scaling

phoronix.com

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Wayland Protocol Finally Ready for Fractional Scaling

#71

Post by seba_dos1 »

colordrops wrote: post #4
Aardwolf wrote: post #3

I still use X11, where and rely on the following features (amongst others): -taking screenshots -auto keyboard/mouse scripting with xdotool -not have unnecessary mouse/keyboard to monitor delay -4K fullscreen, windowed fullscreen and windowed gaming with nvidia drivers, for native and steam proton games -choosing to have vsync enabled or disabled in games -EDIT: I should another important one for me: xclip, read from…

- screenshots work - the keyboard and mouse can be controlled programmatically, but unaware if xdotool itself works - I don't notice any input delay with the monitors at 60Hz - I'm using the unsupported GPU flag with SwayWM and 4k games and windowed games work for me - never tried disabling vsync. I'm guessing it won't work I suspect if you use fractional scaling, the games wont run at 4k, but instead the fraction of…

> I suspect if you use fractional scaling, the games wont run at 4k, but instead the fraction of 4k

X11 games maybe; SDL's Wayland backend can deal with fractional scales and make it render at native 4k.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#72

Post by nyanpasu64 »

As I've pointed out in the MR, this only allows compositors to communicate to windows a scale factor (how many framebuffer pixels to send for each logical pixel of window size), but does not switch window sizes and subsurface positions/sizes from integer logical pixels to fixed-point logical pixels (rounded to integer physical pixels) or integer physical pixels. So Wayland is absolutely not ready for pixel-precise window resizing and positioning in the presence of fractional scaling.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#73

Post by sho_hn »

ChuckNorris89 wrote: post #54
Aardwolf wrote: post #47

Earlier quoted context omitted.

> there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed I'm not sure if that applies specifically to this case, but I'm not a fan of some standardization of protocols that is going on in Linux desktops, because: - desktop managers can't properly keep state of your windows anymore on shutting off/on monitors. Claimed reason why this is not fixable: "…

>I'm not a fan of some standardization of protocols that is going on in Linux desktops Standardization and Linux desktops are sometimes mutual conflicting terms. There's doesn't seem to be much standardization on this front but tribes of people saying "new things should be this way" and other tribes saying "n'ah mate, that sucks, we'll keep using our own better way". Linux desktops don't have the Apple/Microsoft dict…

> Linux desktops don't have the Apple/Microsoft dictatorship powers to actually enforce any kind of GUI standards so we get this constant hassle and even more fragmentation.

Do Apple and Microsoft actually have them? The GUI experience on Windows is relatively disjointed, and Apple famously did it to itself with e.g. randomly chosen brushed metal windows and other app-specific background textures. It appears far more common now for popular applications to ship their own look & feel and even theming. Let's say Discord, or even first-party, VS Code.

I'd say the accomplishments of standardization and interoperability on the Linux desktop are actually more substantial than on either Windows or MacOS. Consider that e.g. KDE and Gnome applications share a lot of important standards and are generally able to run in either vendor's shells. Windows and MacOS each effectively only have a single GUI frontend, so this kind of collaboration between vendors doesn't need to be accomplished, and it's not happening between the app makers, either.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#74

Post by enriquto »

seba_dos1 wrote: post #70
enriquto wrote: post #66

Earlier quoted context omitted.

I was going to reply in an impulsive manner (saying, derisively "so how does strace work, then? and why can you attach gdb to already running processes?"). But it turns out that you are right! Well, at least in modern ubuntu/fedora desktop installs, a few years ago they disabled the ptrace(2) system call. ("The maniacs! They did it!", I'm tempted to cry in anger.) You can still read children processes, but unless you…

> Still, it seems that an attack model based on defending against a rogue user process is quite doomed. Can't this process change the init files of other programs that will run, even if they aren't its children? No, they often can't. Things like Flatpak make it so apps have no unnecessary access to the filesystem.

Fortunately, things like snap and flatpak are still fringe projects with no realistic perspectives for a widespread adoption. Which would be ridiculous, anyway: why would you want all the programs in /usr/bin to be isolated "apps"?

Re: Wayland Protocol Finally Ready for Fractional Scaling

#75

Post by qyron »

chrismorgan wrote: post #21
bluedino wrote: post #12

I was going to say something about it being 10 years now since Apple made high DPI screens mainstream. Windows still doesn't have it working 100% yet.

On the specific topic here, fractional scaling, macOS gets it disastrously wrong, only supporting downscaling, which means that it’s impossible to get pixel-perfect output on fractional scales, which are the norm on most of their devices. I seriously can’t comprehend how they ended up going that way, given that they were the ones in a position to force developers to get things right, far more than Windows, but no, th…

I don't really know how HiDPI is implemented on Windows, but I do know some very popular VST plugins (music production software, which usually uses its own GUI and scaling integration) which still doesn't scale properly in popular plugin hosts, so you can't really talk about "getting it right in all circumstances".

This problem doesn't exist on Mac where the OS is kind of responsible for all the scaling. So, between MacOS's approach which may be not pixel-perfect but "just works" and Windows's one which usually works perfectly but still has problems in certain categories of software, I'll probably choose the former.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#76

Post by ectopod »

Aardwolf wrote: post #47
sho_hn wrote: post #38

Earlier quoted context omitted.

This is a valid and level-headed analysis. The good news is that this is not unfixable; there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed. And there has been notable progress. Specifically when it comes to screen share / remote desktop, standardization of the API to invoke sharing is happening by way of the XDG portal API efforts. There is activ…

> there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed I'm not sure if that applies specifically to this case, but I'm not a fan of some standardization of protocols that is going on in Linux desktops, because: - desktop managers can't properly keep state of your windows anymore on shutting off/on monitors. Claimed reason why this is not fixable: "…

You can usually set a custom date format without changing the locale, and you can usually find a tool to edit the nasty config file it's buried in. It is a pain though.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#77

Post by klooney »

enriquto wrote: post #74
seba_dos1 wrote: post #70

Earlier quoted context omitted.

> Still, it seems that an attack model based on defending against a rogue user process is quite doomed. Can't this process change the init files of other programs that will run, even if they aren't its children? No, they often can't. Things like Flatpak make it so apps have no unnecessary access to the filesystem.

Fortunately, things like snap and flatpak are still fringe projects with no realistic perspectives for a widespread adoption. Which would be ridiculous, anyway: why would you want all the programs in /usr/bin to be isolated "apps"?

I run most of my GUI stuff out of flatpaks now, it's pretty great. Run the latest releases on a stable LTS with no dependency problems.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#78

Post by yjftsjthsd-h »

FloatArtifact wrote: post #51
WhyNotHugo wrote: post #42

Earlier quoted context omitted.

Most of these things work fine (though with wayland-specific tools, rather than X-specific tools), except: > (4) global indicator of where my cursor is (xeyes) AFAIK, no tool allows you to do this. The issue is: clients generally can't snoop on input when they're not in foreground (e.g.: to make key-loggers less trivial). A privileged client could do this using something like layer-shell. It's a hack, but it should w…

Pretty much any accessibility or automation software suffers here without having to be a root. Wayland makes accessibility impossible is developer with its fragmentation. Want to make tools that work across now Wayland ecosystem good luck with that.

> Pretty much any accessibility or automation software suffers here without having to be a root

Even with root they'll have a harder time; there's a difference between "I can trivially tell the X server to give me details about events and then interact with arbitrary windows in arbitrary ways" vs "by running as root, I can watch raw input events come in from the mouse/keyboard and then try to figure out what they mean".

Re: Wayland Protocol Finally Ready for Fractional Scaling

#79

Post by yjftsjthsd-h »

boudin wrote: post #45
pmontra wrote: post #36

Earlier quoted context omitted.

I don't care about tearing. I'm sure my X11 tears all the time when watching videos but if I notice it I shrug it off. The point is that one of the main drivers of Wayland was to be frame perfect, have no tearing. Commendable goal, why not? but it's turning out that they had to write code to get no tearing and more code to allow it.

Wayland is frame perfect, and it's great. What's the issue with allowing users or the compositor to disable that in really specific case without sacrificing the frame perfect principle for all other uses? It's the best of both worlds

With X11, you defaulted to having tearing but could run a compositor if you wanted in order to not have it. Then Wayland showed up and loudly proclaimed that that was unacceptable and we had to be pixel-perfect, every frame, every time. ...Then a few years later, Wayland added the ability to tear, because it turned out to be useful, bringing it back to parity with X. This isn't... necessarily... technically invalid, but the optics aren't great.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#80

Post by yjftsjthsd-h »

WhyNotHugo wrote: post #40
Aardwolf wrote: post #3

I still use X11, where and rely on the following features (amongst others): -taking screenshots -auto keyboard/mouse scripting with xdotool -not have unnecessary mouse/keyboard to monitor delay -4K fullscreen, windowed fullscreen and windowed gaming with nvidia drivers, for native and steam proton games -choosing to have vsync enabled or disabled in games -EDIT: I should another important one for me: xclip, read from…

> taking screenshots There's plenty of tools for this. I wrote a light and simple one that shows a tiny thumbnail, [`shotman`]( https://git.sr.ht/~whynothugo/shotman ). But there's plenty others of all sorts. > auto keyboard/mouse scripting with xdotool There's a few tools for this: https://github.com/natpen/awesome-wayland#tools > not have unnecessary mouse/keyboard to monitor delay There's none that I can notice. M…

> There's plenty of tools for this. I wrote a light and simple one that shows a tiny thumbnail, [`shotman`](https://git.sr.ht/~whynothugo/shotman). But there's plenty others of all sorts.

Your tool works on wlroots compositors, which is to say it doesn't work on GNOME or KDE.

Post reply on HN