cycloptic

>if the different implementations doesn't have a common interface it's goodbye to ever having screensharing work for everyone.

No, not really. In practice what happens is Discord/Zoom/etc do implement it for the most popular compositors and then the other compositors follow suit if they want to support those applications. You would be complaining even more if they only supported weston because their screencast mechanism is pretty limited, and it would suck if the other ones just copied that.

The current "standard" is to just use pipewire and have the display server talk to the pipewire server, most commonly using xdg-desktop-portal. This is obviously outside the scope of Wayland, because any application can talk to pipewire and share/receive a video stream. I don't know about Zoom, but Chromium has support for this in the works, so Discord should get that eventually from updating their Electron: https://github.com/electron/electron/pull/26022

Security is one of the major reasons, and this is indeed a privileged operation that should not be accessible by all clients.

The other reason is that this isn't base functionality, for example an embedded implementation has no need for screenshots.

>In my admittedly somewhat distanced opinion, Wayland's biggest mistakes were not launching with a coherent strategy for replicating functionality like screen sharing, screenshots, and to a lesser extent remote desktop/applications. They just punted and said "that's a compositor problem!" as though that was supposed to make it ok.

I am not sure what you mean here. Weston, the original implementation, includes support for screenshots, screensharing and RDP. Other implementations decided to implement those in a different way, for various reasons. The way to not "punt" this would be to use libweston but that has its own set of issues, and it seems strange to blame the Weston hackers for not upstreaming every single other thing that some implementer is working on.

The real serious issues are not really with fonts and vectors, it's when you have a surface within a surface. (In the context of a browser, think flash plugins, JS canvas and the like) Those have to be pixel sized, which means practically you are forced to 1x, 2x, 3x... It is unfortunately a special case that is incredibly common, and it has to be handled. Solving this by snapping everything to the pixel grid is another form of rounding that has its own set of artifacts with elements jittering around when the window gets resized, and it breaks down again if you try to have surfaces within those subsurfaces. (e.g. You decide to display a cached buffer within your flash app or JS canvas) These problems are exacerbated further when you have mixed DPI, it actually makes it much worse, and you still have one screen that is going to be scaled down and blurry.

At some point maybe I'll put together a post to illustrate this, I know it seems easy when you think about it but if you try to implement it you'll see it causes a huge number of problems. They are not unsolvable but the amount of clients that are going to care enough to solve them all is very small. (Fundamentally this cannot really be solved in a browser either for the reasons I described above)

If you want to work on this, please do it, but don't say I didn't warn you that it's a rabbit hole. I've actually done everything you're suggesting before in other projects, and honestly we've really only scratched the surface of why trying to do this kind of scaling is problematic.

There is no "non-broken" way that an app can consistently render at a real number scale into an integer sized buffer. Everything is going to have rounding or blurring in some way. This is unavoidable.

If you follow the email I linked a while ago, this was mostly a decision in Weston, not really particularly related to GTK. But if you want to follow the conversation on where Gnome is at with this, see here: https://gitlab.gnome.org/GNOME/mutter/-/issues/478

The end comments there are what I'm getting at, the only reliable way to do this is to just bypass scaling completely and have something where the client says "never scale my buffer at all on any monitor." But of course that has the same issues with mixed DPI and you would only really want to use it for performance-sensitive applications that are not particularly sensitive to scale.

If the app is still rendering into that box at 2/3 scale, then it is either cutting off pixels at the bottom or you will get a seam at the bottom.

>Fractional scaling is exactly what we're talking about. ... That's circular. You're arguing that the way things are done is an argument for things to continue to be done like that.

Actually no, what you are describing is ideally having no scaling at all in the compositor on any particular monitor. (Unless of course a window is stretched between them) I'm not arguing for things to be done any way, I'm saying don't misuse a feature that was designed to do something else than what you're asking for.

For a vector UI that is supposed to be pixel-aligned, you can't render that at a non-integer scale without the same blurriness that you would get with doing the scaling in the compositor. That's different from rendering print content that has no relation to pixels.

It's not correct because you are not rendering at 2/3 scale anymore, you are rendering at 0.665 or 0.67 scale. What you are describing is rounding, you can't do this without rounding. Worse, with that method the scale technically changes every time you resize the window. This is hard to explain in text on HN and I don't have reference images to illustrate this at the moment, sorry.

>Some things will be blurry, but no worse than having the compositor do it. Other things will not be blurry, and that's a huge huge benefit.

This is the same trade-off as you would get without it.

The precision isn't an issue, the error build-up is with rounding and it becomes particularly problematic when you have subsurfaces.

As I have said in another sibling comment, if you don't want the compositor to do any scaling, then don't enable scaling in the compositor.

With the PDF you would see the same results using a filtered scaler. There is unfortunately no way to do this that doesn't break down in mixed-DPI situations because of the rounding issues. If you want to add this to a wayland implementation, I won't (and can't) stop you, but I think it's a bad idea. Just my experience from trying to write various scaled interfaces, it becomes impossible to ensure that anything is pixel aligned after you introduce a non-integer transform in the graph. When the top point in the graph is the screen, that limits a lot what you can do there.

>You're just sizing the window to integer pixel sizes. Just like every X WM and Wayland compositor does.

To be clear, this is if you configured your output scaling to be 2/3. 133px is absolutely not correct there.

You can't be pixel perfect in the 1.5x screen if your renderer is scaling correctly and thus is rendering lines at 1.5 pixels wide. The result is the same on the 1.5x display, and on the 1.1x display it's worse, because now you're re-scaling the line that is already anti-aliased, blurring it twice.

If you get a 133px box, you are cutting off pixels at the bottom.

Edit: What you are asking is possible, right now. Just leave your primary display at 1x scale, change the secondary to 11/15 scale, and then turn up the sizing in your applications. It's actually better that nothing is needed in the Wayland protocol to do that.

They aren't forced to draw at 2x and be scaled down. They only need to do that if you have enabled fractional scaling. If you really want to avoid the overdraw associated with that, just don't use any scaling on your primary display and then turn the font size in your client up. Anything else that passes the fractional scale onto the client is going to have issues. The reason you pass the buffer scale in wayland is because you explicitly want the compositor to scale your buffer and you want it to do it correctly. If you don't want that, don't bother with messing with fractional scaling.

>you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties

Again, this comes back to the issue where now you need to deal with rounding in the client. Only the simplest of browsers, image viewers, 3D renderers, PDF viewers that have no UI chrome could get away with just passing on a fractionally scaled buffer. And for those, you can do what I described above, disable fractional scaling and do your scaling in the client, you don't need any special support in the compositor. I believe in most applications you can press Ctrl-Plus and Ctrl-Minus :)

IMO, X11 is practically unusable without NX/Xpra, but it has other UX issues and it still doesn't do exactly what you'd want. Throwing a protocol error is also bad UX. There's no way to present that to the user other than saying "hey this didn't work, go fix it in some other system-dependent place that I may or may not know about."

This post was going around a while ago, I don't think anything has really changed for the better since then: https://who-t.blogspot.com/2019/10/libinputs-bus-factor-is-1...

You do have to propagate the scaling factor, but as long as it's an integer scale, you don't have to convert all your coordinates to use floating-point everywhere and enforce rounding rules.

I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly. The only real way I know to do this without causing artifacts or error build-up is to have to compositor only do the rounding as the last step, which is the way it works now, and you have to use an integer scale for that. As you describe, this is the "easily solved" way, but it's only really easy because the compositor gets to handle it internally -- once you push that problem to clients it gets significantly harder.

IMO the main problem there is that the UX around dropping events and returning blank rectangles is bad. We have the tools to design other protocols centered around a real security architecture that can communicate intent properly and doesn't need to return fake data.

D-Bus is a special case because the protocol is not particularly complicated and the proxy can be used by any sandbox to implement various types of filtering on any other service that uses D-Bus. That's one of those things where if your application uses D-Bus to communicate with a service, you might just end up getting sandboxing support there "for free."

Pulseaudio is not getting much work these days, I believe the work currently is happening in Pipewire, which was built to have a fine-grained permission system that can work with any sandbox and is backwards-compatible with Pulseaudio.

I'm not sure how your IRC bouncer would work there, but presumably if you sandboxed that, it only needs to talk to the IRC socket and nothing else. For other obscure servers that have no concept of security, I'm not sure what can be done about that if nobody wants to modify them or replace them. You might just have to accept that they will need to run at elevated privileges and can clobber your system or home directory.

I think "there is only one person working full-time on maintaining Linux input libraries and he's overworked" is probably a decent excuse. I don't know what you plan to do, but I would advise against forking unless you can hire a team to accumulate testing hardware and work on this for multiple years. What we have seen too often is these forks just fizzle and get forgotten, especially if they are only focused on getting one feature to work on one very specific device.

The solution in that email is essentially how it works, the only difference is that the scaling factor is forced to be an integer.

>By faking them out and telling them "here's a 200x200 box to do your work" and then later scaling down that box to 150x150 prevents that code from working properly.

Then question I was getting at is: how do you write a renderer that does the right thing and works properly when given a box of 133.333333 x 133.333333 pixels? If you say "round in some direction" this is now a policy that must propagate to every bit in the stack that touches input and rendering.

>It's no worse than the current solution for that screen and better for the one that matches.

It actually is much worse for the one that doesn't match, because now you have lost the ability to do pixel-perfect scaling.

This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. A bit of background here: https://lists.freedesktop.org/archives/wayland-devel/2013-Ma...

To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3 without being blurry or without rounding errors? And if you wanted to avoid any additional scaling artifacts or rounding errors, how tall would you make the output buffer, in pixels? What happens when you try to stretch this window across multiple screens?

What you are describing is not enough, the X server or the X compositor would still need to scale windows up/down if they don't support scaling or if you want to have fractional scaling. It's not something a old-style window manager can do -- There is just no real "Xorg way" on how to do this right now.

Qt applications are almost certainly using the output scale property, I've tried those recently. I haven't tested Chromium's wayland backend recently, but Chromium is ignoring those physical values: https://github.com/chromium/chromium/blob/99314be8152e688baf...

Maybe your chromium is not using the Wayland backend correctly? If a Wayland application is using the physical values to determine scaling, instead of the output scale, that's a bug and you probably should consider reporting it. It's probably a mistake that the physical size information is there, it's unreliable as you have seen.

Edit: Rather than messing around with proxies, if you want to do a quick test to confirm, you could simply hack wlroots here to send a constant value: https://github.com/swaywm/wlroots/blob/b3e76d667855c16e97a4d...

Is there some reason you cannot just set the output scale? This almost certainly already does what you want. If you're talking about X11 applications running on XWayland, I think you can still change the properties there with xrandr.

>Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits

There is nothing that can be done about this from the view of the display server. The application and toolkits have to be updated to support high DPI.

I don't know of any Wayland implementations that let you do that, it wouldn't be hard to hack in, but Wayland applications should not be using that information to decide scaling. They should be using the wl_output.scale.

In X11, you can do it with xrandr --fbmm. Technically you can also set this information per-monitor but I don't think a command line option was ever added for it.

Those don't seem to matter here, the business apparently is saying that the language was precise and they were experiencing measurable harm from it.

I have to say, that still doesn't mean much to me here. In a real court system, we judge people by their actions and behaviors, sometimes their speech can play into that. I assume that's what the author was referring to. (Apparently the origin of this quote is not clear, but it does seem to come from that same time period) This can't be compared to social media, the only way to judge anyone in the context of a social media platform is by what they say. That's all there is on these platforms, if you take that away, there's nothing left. You are judging someone every time you make a decision whether to like/follow/reply/retweet or not. If your view is that all that doesn't matter and the speech is meaningless, then it follows that any perceived punishments are also meaningless.

I'm confused, what is the lesson here? That quote seems to get thrown around so often that it can be applied to anytime that anyone gets criticized for anything. The moderator's statement appears to be asking for more help with moderation, not advocating for less moderation or advocating for more hateful behavior to be allowed.

I get that it's frustrating but I don't understand what the real issue here is, or how this relates to anti-trust as some other comments are suggesting. They are under no obligation to offer any further explanation for why they won't operate a free service forever. It's a business, you can safely assume the explanation is always "because money."

Just saying, if you're happy with a *box window manager that hasn't changed much in the last 15 years, you were probably not ever the target audience of gnome. I also don't see why those type of projects would need much funding, compared to ones that are actively seeking to expand their userbase beyond developers. (and I would agree that gnome is not perfect and is not the only contender in this category)