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

41–50 of 102 posts

Re: Wayland Protocol Finally Ready for Fractional Scaling

#41

Post by WhyNotHugo »

hackyhacky wrote: post #37
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…

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. 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…

> 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 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.

For example, you can simply run `sleep 3 && shotman --output` to take a screenshot of an output in three seconds. There might be other GUI tools with a pretty timer setting. I've no idea if such a thing exists or not, but it's perfectly possible to write without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi).

Re: Wayland Protocol Finally Ready for Fractional Scaling

#42

Post by WhyNotHugo »

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

> 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 work. Somebody needs to write it tho.

> (5) define global key combinations that launch programs (xbindkeys)

Compositors implement this themselves for the above reason.

> (8) run graphical programs from a headless virtual machine (ssh -X)

I guess this should work with XWayland? Keep in mind, most X applications work via XWayland. This means normal applications; xbindkeys or xeyes won't work since they rely on reading input when other applications are in foreground.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#43

Post by hackyhacky »

WhyNotHugo wrote: post #41
hackyhacky wrote: post #37

Earlier quoted context omitted.

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. 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…

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

You're missing my point. The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool: you have to use the functionality built in to the compositor. Many compositors (notably GNOME and KDE) don't support the Wayland semi-standard interface for these things.

You mentioned shotman, but that isn't even a real screnshotting tool: it's just a screenshot GUI that depends on existing functionality that may or may not be present in your compositor.

If all the compositors actually supported a standard for providing this functionality; and if that standard provided enough flexibility to do what I want, then I wouldn't complain. That's the essence of modularity. But the standards are poor and poorly-supported, and I literally can't do what I want. Your trivial example of using the sleep command to simulate delayed capture doesn't address the actual issue, and fails to recognize that no amount of hacky solutions will allow me to use a VNC screen sharing tool that shares only a specific window, because the Wayland compositors have chosen not to support that feature and failed to provide a standard way for external tools to do so.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#44

Post by BearOso »

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 none that I can notice. Mice cursor are rendered with hardware support when available. Not sure what you reference is here.

Some compositors don't use the hw cursor plane. All others that do don't update the cursor position asynchronously on mouse events, just once on the next swap. Those cases add an extra half-frame latency on average. It's worse at lower refresh rates.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#45

Post by boudin »

pmontra wrote: post #36
boudin wrote: post #32

Earlier quoted context omitted.

Why? It's quite a good idea IMO, the compositor allowing in specific case to optimise for speed rather than quality.

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

Re: Wayland Protocol Finally Ready for Fractional Scaling

#46

Post by ccouzens »

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.

Indeed. On an external screen that would be most comfortable at about 125% MacOS will only offer you 100%.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#47

Post by Aardwolf »

sho_hn wrote: post #38
hackyhacky wrote: post #37

Earlier quoted context omitted.

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. 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…

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: "the standard requires it"

- I dislike MM/DD/YYYY date formats. File managers used to have their own setting to choose your date format. Now they use some common standard so you have to set your Linux locale to something non-US. This then breaks other things. It's much nicer to be able to configure things per-application.

- Kolourpaint used to have a good color picker that showed you the numerical and hex values of colors. Now it has a horrible one that is only some palette where you can edit individual entries. You can't easily see the RGB values of a pixel in an image you open in Kolourpaint anymore. All due to "standardization", using a shared color picker component

- Focus stealing prevention no longer properly works, all due to adhering to some desktop standards

- Desktops like KDE and Cinnamon using horrible non-human editable json/xml/base64-encoded UTF-16 formats for their config

- Some Qt or GDK applications not having icons sometimes, due to them expecting some common icons available somewhere. This issue used to not exist, applications came with their own icons that just worked

I much preferred how unix and the desktop used to be, where you could manually edit textual config files to do whatever you want, and had the power and flexibility to change almost anything in intuitive ways

Re: Wayland Protocol Finally Ready for Fractional Scaling

#48

Post by Sakos »

WhyNotHugo wrote: post #41
hackyhacky wrote: post #37

Earlier quoted context omitted.

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. 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…

> 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 without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi).

The necessary APIs don't exist, so it isn't possible to write the extra functionality without changing the compositor.

Honestly, I don't understand why anybody defends Wayland at this point. It's been, what, ~~six years? Six years~~ FOURTEEN FUCKING YEARS we've been telling you that we want to be able to use our screenshot and recording applications and that removing functionality that we use day-to-day wasn't acceptable. Are the Firefox devs the same people making Wayland? Is that why they're so unresponsive to user needs?

Re: Wayland Protocol Finally Ready for Fractional Scaling

#49

Post by saurik »

hackyhacky wrote: post #37
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…

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. 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…

> ...without any of the modularity and flexibility that Linux is (allegedly) proud of.

Linux seems to have been infiltrated by people who simply don't believe in this anymore, and so we keep getting "modern" "batteries included" integrated monoliths that suck at everything but supposedly make things easier because this new crop of people don't want to have to know about or compare multiple options :(. And like, because for specific use cases the monoliths can have better performance, that gets used as a way to undermine what used to be the unique selling proposition of Linux :(.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#50

Post by enriquto »

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…

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 me like a pointless limitation that creates a lot of unnecessary complexity. But what do I know.

Post reply on HN