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

51–60 of 102 posts

Re: Wayland Protocol Finally Ready for Fractional Scaling

#51

Post by FloatArtifact »

WhyNotHugo wrote: post #42
enriquto wrote: post #20

Earlier quoted context omitted.

> I still use X11, where and rely on the following features To which I would add: (1) taking screenshots from the command line (xwd) (2) moving windows around from the command line (xwit) (3) keyboard-free copy-paste between different programs: select to copy, middle-click to paste (4) global indicator of where my cursor is (xeyes) (5) define global key combinations that launch programs (xbindkeys) (6) globally confi…

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.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#52

Post by FloatArtifact »

yjftsjthsd-h wrote: post #39
RealStickman_ wrote: post #14

Earlier quoted context omitted.

Have you tried ydotool as a replacement for xdotool? It also works on X, as it uses uinput. https://github.com/ReimuNotMoe/ydotool

There are a couple of tools that can programmatically perform input events. They have some caveats because they work at a lower level so you might need to give them root permissions when that wouldn't have been necessary before, but they do work. The question is if that's all that you were using xdotool for; it's not limited to faking input events. For instance, xdotool can monitor events and trigger actions when you…

This 1,000% for accessibility software or automation frameworks. We don't want a privileged root privileges for emulating mouse/key presses in any application. As a side note Monitoring events might be reasonable, but I wish service could register to monitor without root privileges. Therefore, allowing user discretion.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#53

Post by mort96 »

ybc37 wrote: post #31
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…

> xclip, read from and write to the clipboard in the command line There's wl-clipboard with the commands wl-copy and wl-paste: https://github.com/bugaevc/wl-clipboard Works flawless in my experience.

Doesn't that have to create a window to interact with the clipboard? That makes it quite disruptive in some contexts.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#54

Post by ChuckNorris89 »

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: "…

>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 dictatorship powers to actually enforce any kind of GUI standards so we get this constant hassle and even more fragmentation.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#55

Post by mort96 »

MichaelCollins wrote: post #24
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…

Just do yourself a favor and stick with using what already works. Don't upgrade to the new shiny thing unless you already know the reasons why you want to. Among all the other technical issues, Wayland devs have an attitude issue. Users asked for fractional scaling for years and were faced with flat refusals and insulting quips from the wayland developers. The only reason they've added it now is because Valve asked t…

The thing is, the old way is also clearly broken. For me, X11 has always been a slow, stuttery, screen-tearing mess across a range of hardware, while Wayland is much better at shipping complete frames on time during normal desktop use. So it's a choice between the broken old thing and the broken new thing.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#56

Post by exitheone »

enriquto wrote: post #50
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…

Thanks for your answers! It's reassuring that most things will still be possible. Still, xeyes is the favorite program of my kid who is starting to learn linux... I'd have a hard time selling wayland to him. > to make key-loggers less trivial Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user. This seems to…

> Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user.

That's not true. Reading other processes memory requires root even for processes of the same user.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#57

Post by mort96 »

Jonnax wrote: post #10

I think it's been 10 years since that Canonical Mir project that created a lot of drama. I remember Intel removing their code from their driver saying they won't support them as Wayland was the future, for example. And it finally gets fractional scaling now? How is colour management on Wayland? Is there HDR support?

There has been "fractional scaling" support in the way macOS does it forever: if you wanna scale at 1.8x, let the application draw at 2x, then make the compositor downscale everything. So it's not like it hasn't been possible before, it's just more efficient now I suppose?

Re: Wayland Protocol Finally Ready for Fractional Scaling

#58

Post by zbuf »

cycomanic wrote: post #28
maskros wrote: post #17

Earlier quoted context omitted.

He is referring to input lag: the delay from input to visible change on the monitor. The double buffering and compositor step added by Wayland adds some delay. You may not personally notice it, or be used to it, but it's always there. Some people are more bothered by input lag than others, and there are so many compounding factors today that make it worse than ever. It's not only the double buffering in graphics subs…

It seems your subjective feeling is not reflected in measurements. At least for kwin wayland is as fast as uncomposited x11 https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-...

Don't these results show a 20% slower based on the median?

Plus, the test uses a display at 120Hz, which is a substantial head start -- by making each frame of delay half as long compared to us mere mortals running at 60Hz.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#59

Post by [deleted] »

Conan_Kudo wrote: post #23
chrismorgan wrote: post #21

Earlier quoted context omitted.

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…

macOS got it "wrong" because their own displays were all integer scaled. They don't care about the rest.

[deleted]

Re: Wayland Protocol Finally Ready for Fractional Scaling

#60

Post by jpetso »

Sakos wrote: post #48
WhyNotHugo wrote: post #41

Earlier quoted context omitted.

> For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the ti…

> Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the timer expires. You complaint is like saying "the Linux kernel won't render markdown for me". No, it won't, you're looking at the wrong part of the stack. Xorg also doesn't prevent you from using an application that does have these functions. Wayland does prevent you. > but it's perfectly possible to write with…

> Is that why they're so unresponsive to user needs?

It's because Wayland is a set of protocols, rather than a single dominant implementation.

In order to do it right, cross-compositor and flexible, you have to get different actors with different interests and bandwidth agree on a standard. This takes time.

In order to get it working fast, developers need to make a compositor-specific implementation first and then put in the extra work of getting it through the standards discussion as well as switching their compositor ecosystem to the new standard.

Until this happens with all parts that you care about, you're going to be annoyed either about interoperability or functionality. Pick your poison, and cue Moxie's "The Ecosystem is Moving" blog post. Also, keep using X11 until Wayland has the features you want. Most DEs/WMs haven't ripped out X11 support yet, and hopefully won't until their support of Wayland protocols is solid enough.

Post reply on HN