KDE Lands Wayland Fractional Scaling Support

[Quackdoc]

Then the second assumption (and this is what lead me to frame it as a backwards compatibility issue) is that the number (or fraction) of apps which don't support scaling due to being legacy or unmaintained is larger than the number (or fraction) of modern apps that refuse to support scaling, and that those fall out of use over time or eventually do get fixed.

for the majority of apps, it will be "as it is on X" because the framework is what handles scaling for the vast majority of applications. meaning if your unmaintained application miraculously works on the current toolkit, it's just a matter of updating the toolkit. for instance QT. once the patches get ported to QT5, all QT5 apps should "just work" and as for GTK, well that never worked to begin with.

the question now becomes how will various compositors handle GTK and CO. as alluded to above, this is a tricky question. I would honestly rather them just say "fine" and straight up not scale them to force GTK's hand. but meh, not everyone can afford to break half of the linux ecosystem.

[Sho_]

Only one link in it - it popped up now.

[oiaohm]

I still can't see that post.I have just found that if you put too many links in a post, it gets flagged as "spam". I think that the limit is 5 links. More than that, and it never gets approved.

So, you can get around it by splitting a post into two posts. First, make new posts by copy-pasting, then delete the old unapproved post.

Up to 3 links of your own don't normally need approval, 4 or more need approval most cases. Splitting posts to get around URL link limit can get yourself done for spamming by automated protection by posting too fast. I have successfully at times had posts have to go to mod for no other reason than I set of short posts end up posting too fast yes they contained no URLs.

Something to be aware quoting someone else post at times the system counts those URLs as yours and puts it in the mod pile and other times does not count. So yes the URL counting tries to only count the URL you add but it does not get it right all the time.

If your actions are declared too spamming with URL attempting to redirect people between threads it is possible to be tagged with lower URL count as in 1 or 0. There are language filters as well.

The reality here if your post has more than 3 URLs you need to look at them and work out if they are in fact all required to make your point.

[oiaohm]

(e) There's still a kernel of truth in your statement however, as for a time the community also had trouble in agreeing what sort of DE features should be orchestrated through Wayland IPC, and which through other channels like D-Bus IPC. I commented on this myself in a blog post a few years back. Here also I would say best practices have been slowly emerging, but it's perhaps not fully resolved yet.

Its more of a mess than that.

You mention that ICCCM and EWMH/NetWM would be up for grabs in Wayland.

https://en.wikipedia.org/wiki/Extended_Window_Manager_Hints

https://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual

Notice Gnome never under X11 implemented either ICCCM and EWMH/NetWM in gnome 3 and newer.

So I would say both of those need to be dbus specifications in future to make X11 have uniform provide of these features just as much as Wayland.

What should be implemented by X11 DE/WM never got fully resolved either so this does not give as a great starting point.

[Sho_]

So I would say both of those need to be dbus specifications in future to make X11 have uniform provide of these features just as much as Wayland.

I don't know anyone aiming to keep X11 at feature parity long-term, though.

[Sho_]

The only correct solution is to use single-connection protocol. Everything else is just a big design mistake.

This current impression cannot be anything else than some kind of a illusion. It migh appear to work now, but it will break terribly in the future.

I'm afraid I can't really follow you there. Might also be why I got lost in your original post.

Wayland protocol extensions work over the same single socket connection between client and server already.

The "bazaar" model etc. in your original post is already how it works (and always has).

[Sho_]

A: Yes, this is exactly how it works (aside from the "tree identifier" thing, although the ability of protocols to reference and extend each other provides what you want in another way) - aside from a few other core primitives (such as displays, outputs and surfaces), the core protocol is chiefly concerned with establishing this protocol registry and negotiation mechanism.

B: The wire format imposes a max length of 4096 bytes for each individual message, but you can chunk data across multple messages if you want. In general it doesn't prevent you from using the connection as a data channel if you want to in your protocol design. It's generally much smarter in this application domain not to do it and e.g. exchange a handle to a buffer (for example dmabuf or a file descriptor) instead so you don't do data copies (or impede your high-frequency, low-latency control channel with sending data in the first place), however, so I can't think of any protocol designers who've wanted to or have done this. Compositor and client implementations optimize more for exchanging many small messages than messages with large payloads as a result.

C: The short answer is yes. The somewhat longer answer is that message order is guaranteed, and it's part of the "best practices" mentioned earlier that protocols are generally designed for atomicity (i.e. transactional semantics). This together with the ability to write protocol extensions that e.g. reference and extend other existing interfaces gives you all that "interleaving synchronization" you're after.

From what I can tell, Wayland is more or less designed the way you want.

[Sho_]

I think I feel that the C. "synchronization" is the hardest one to comprehend. So I'll give a concrete example (this is intentionally a really simple case).

At connection time, the client and the compositor negotiate the capability of "screen-capture protocol".

SC1. During frame no.6, the client sends the request to the compositor: the client wants the frame no.10 to be captured, and he wants to receive the captured image before the start of frame no.16.
SC2. During frame no.6, the compositor replies: OK.
SC3. During frames 11-15, the compositor sends to the client the captured image data. The final packet must be sent to the client before the start of frame no.16. If this becomes impossible due to bandwidth problems or CPU time problems, the compositor must send to the client an exception before the start of frame no. 16. (the start of the frame no. 16 is an event that also gets sent by the compositor to the client)

Your example interacts badly with Wayland's security model, it's frame callback-based rendering scheme and also the async nature of windowing systems in general. For example, in Wayland clients don't know the screen coordinates of their windows and also can't set them directly. They're not allowed to introspect the scene or learn about other sibling clients, etc. They're also not allowed to know about the compositor's rendering progress or global frame ordering except for "I'm ready for a new frame from you".

The screen capture protocols usually more or less come down to the client sending a request to get the "next frame".

I think you're kind of unwittingly thinking about an interesting problem space with your example though. What you're close to touching on is from the domain of doing good "frame timing", which has been an interesting and quite active space in the last couple of years. I'm too busy to compile links atm, but I encourage taking a look at Keith Packard's XDC talk "Improving frame timing accuracy in Mesa, DRM and X", the various Vulkan extensions that have been proposed (e.g. VK_GOOGLE_display_timing vs. VK_MESA_present_period), Wayland's presentation-time protocol and posts/presentations from development teams like Unity and Croteam about frame timing in their respective game engines. Some of that will go into how that "the compositor should send an exception if it's busy" is dealt with in practice.

For an interesting development history of screen capture extension protocols for Wayland, I recommend reading a bunch of tickets on the wlroots issue tracker, as Drew, Simon etc. went forth and back quite while on a couple of interesting approaches around 2018, with frame-perfect capture across outputs also an interesting object of discussion. Of course there's also KDE's protocols in this space.

For Wayland in general, you might enjoy wayland-book.com as a quick read of the fundamentals (e.g. the wire protocol, the global objects and also the frame callback mechanism).

[Sho_]

I don't think what you propose is a good design that's workable in practice on any OS or HW in mainstream use.

First of, let's discuss "connection channel" to make sure we're talking about the same thing. Wayland is designed as a control channel for a compositing service and a client to talk to each other and coordinate rendering and window and output state. This happens over a single socket connection. It follows a server-as-authority model, the protocol between server and client is extensible, supported protocols are introspectable at runtime. Best practices for protocol design include not volunteering information about global state to the client and atomicity.

While in principle you can send any data you want over the connection in your custom protocol extension, in practice it's not a good idea to go beyond control channel applications. This is because socket connections are serial and FIFO (per connection+direction) and control channel applications are high-frequency and latency-sensitive. Sending big chunks of data will interfere with high-frequency and low-latecy requirements. The only way to mitigate those impairments is to do small data chunks so you can interleave, and then per-message overhead will hurt your data throughput instead. Trying to get clever with "scheduling data when the socket is idle" is also not going to resolve this basic conflict because it turns out often you want the data to be available fast in relation to the control channel, too.

That's why in the control you channel you reference data somewhere else by a handle, e.g. a dmabuf handle to a GPU texture, or a file descriptor to clipboard contents, or a shared memory location. Note that this doesn't mean there's another "connection channel", only that you're referencing data that didn't go through the socket. That does of course mean you need to do some resource lifetime management, but then with GPUs you have to anyway.

The other reason is HW: In many systems the relevant data is in video memory and you don't want to download it from there to push it through a socket and have the other side just re-upload it as that's disgustingly slow. Heck, even in the clipboard case you want to avoid data copies.

The design you argue for would make everything slower, basically - it's not efficient.

I have a hunch you argue for it because you want network transparency, which can be a desirable feature, but is incompatible with high-efficiency local compositing (especially over a single connection) for the stated reasons. Wayland (and also X11 via later protocol extensions) went all in on the latter.

[Sho_]

And, of course, the first issue. I almost forgot about it.

- The Wayland protocol currently doesn't have an appropriate sub-protocol for tripple buffering (with flip-time estimation). This protocol should be urgently designed, implemented by a reference implementation, and standardized. Here is a short discussion on that issue.

I recommend you follow up on the references related to frame timing in my earlier comment, as the post you referenced is a bit outdated wrt/ state of the art in this space.