KDE Lands Wayland Fractional Scaling Support

[Sho_]

In the end, my opinion is that I have clearly won the argument, extremely conclusively. In conclusion, the design of Wayland is sub-par, and needs to be changed.

This doesn't follow from any of your reasoning :-) For someone quick to link out to logical fallacies on Wikipedia, it's a stunning final leap.

It's quite rude to accuse me of "attempting to misrepresent your posts" and it makes me realize that you discuss on mainly combative and bad faith terms. Given that you've shown yourself as uninformed and guessing for much of the thread (and often guessing wrong, for that matter) I'd urge you to be more investigative and curious rather than hasteful and proselytizing. You will learn more.

I regret the amount of time wasted. Back to making software useful for others!

[oiaohm]

I didn't say that the compositor should provide information on just a single mouse event per frame. Compositor can provide separate info on all the 1000 mousemove events, all in a single frame. A good idea would be to use some coalescing, in order not to send 1000 data packets.

So, the compositor first collects some events, then it coalesces them, and finaly it can send those events to the clients as a separate mousemove events, if the client requested so.

coalesces to a point. You have to remember application can be working on the next 2 frames+ into the future. Event happens part rendered frames can need changing. Sooner application knows the sooner it can do that.

The compositor decides on the order. The compositor is the authority on time. The order is what the compositor says.

You need to know what order input events happened in.<<

I should have been more clear.

You move a mouse the application is a few bits of data. Location and time. Yes a clock that ms/ns is close to real world is kind important. Calculate speed of mouse movement.

Computer mouse drivers use to write this up as mickey per movement time. Mickey is after Mickey mouse but it means the smallest measurable unit of the computer mouse.(wacky historic units for you) So mouse would move so many Mickey in the x and y in the time frame defined by the polling hz.

So xfcemint now mouse movement velocity remember lots of programs use this value for different things. On direct hardware this is simple Mickey distance*hz gives you velocity in mickey per second. Now from this value to screen movement Mickey per second/ output hz. Yes modern day stuff has added dpi correction for mice and so on but the base is the same.

xfcemint you are saying you got rid of the clock where is your replacement for input. How do you the velocity. Think applications like krita and games need to be able to work out velocity because the produce different output based on the velocity of the mouse/pen movement.

You need to know the order the input happens and when and what the input is and you do need velocity somehow. Then there is a stack of math on top of that.

Input has your highest clocks historically..

[oiaohm]

Sooo happy that makes me. Kisses and love.

No this is you did not read.

"mouse movement velocity" xfcemint with you framebase thing how are you going to get this number. Wayland you have position and time. X11 you have position and time. MacOS you have position and time....

xfcemint there is a reason why the input device areas have had the highest clock-speeds. It a simple one. Input-rendering-output. At the time of input you have to guess the future for the output because of rendering time latency. Guessing the future is where mouse velocity comes in.

xfcemint with your protocol idea how are going to handle mouse or pen.

Remember you do need asynchronous parts to the protocol because not everything need to be synchronous.

Look at arcan videos not one demos using a drawing program like gimp or krita or running FPS game.

arcan still has some very serous limitations to overcome itself on input handling caused by not using globaltime.

[MorrisS.]

That makes no sense since I have already said that Wayland developers are obviously under the influence of groupthink (Wikipedia) and confirmation bias (Wikipedia).

My design is actually the proof that Wayland developers are under heavy influence of those two psychological phenomena: my design is so simple to "invent" (I did it just by talking to people here on the forum), that there can be no other reasons why they didn't already figure it out, except for the mentioned pshycological phenomena (via a proof by exhaustion, Wikipedia).

So the non sense is that you discuss about an argument for nothing.

[oiaohm]

I discuss here because I assume that not everyone here, on this forum, is under the same influence of groupthink and confirmation bias (as Wayland developers are).

I think that my reasons are quite obvious and easy to justify. I also think that what you just wrote is an obviously incorrect argument.

my design is so simple to "invent"

Maybe your design is so simple missed critical things.
1) Amdahl Law. Asynchronous is not optional thing going forwards.. Those making silicon lost the means to keep on doubling clock speed years ago. This made Parallel processing way more important.
2) ever head the thing single point of failure.

https://invent.kde.org/plasma/kwin/-/wikis/Restarting

Wayland compositor in theory can be restarted without stopping applications there is still a lot of finer points before that is reality for normal operations.

Wayland compositors should be able to be restarted in future. Now globalhotkey to restart Wayland compositor for example you don't want that to go off line just because the Wayland compositor ceases running right? So maybe locally you don't want everything though the same IPC.

3) time

https://www.x.org/releases/current/doc/xorg-server/Xinput.html#Device_Motion_Events

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setdoubleclicktime

This is the biggest problem with making everything 100 percent synced on frames. Yes historically everything milliseconds with input. Yes Windows, Mac OS, X11 all use milliseconds for when input event happened.

But there is strict difference between local and remote protocol here.

https://github.com/letoram/arcan/blob/085138e7048072156bf5b16e339ab78c295c89d3/src/wayland/shmifevmap.c#L169

Notice how arcan just goes and generates new event with new time when sending keyboard to wayland and x11 client. Same applies to mouse you can find it in that same file. arcan A12 mouse/keyboard is lacking some information.

Arcan A12 protocol simple does not have "mouse movement velocity" information this means particular applications will not work well.

Where does libinput that most Wayland compositors use get time from for keyboard and mouse events. That right the timestamp the Linux kernel put on the input event when the Linux kernel received the event. The timestamp by the Linux kernel in min effected by the Linux kernel scheduler and cpu clock speeds.

xfcemint can you see yet that there is a difference between Local and remote desktop yet. Remote due to latency and clock issue normally end up not supporting or support badly any application that needs to use "mouse movement velocity".

Local since every part can use the same clock you are not needing to build the IPC into single solution. You are not needing single point of failure. Local can use the OS kernel timestamping on everything so able to calculate mouse acceleration that will closely translate to output operations because both are using close to the same clock.

Not having a unified clock causes work around. Remote protocol there are two common workarounds
1) this is the most common. Don't support particular classes of applications and be latency sensitive due to the effects on input of not having unified clock for timestamps or some replacement. Arcan is in this camp.
2) Have a very complex system for expressing when input event happened relative to something else so that velocities of input events do exist this still end up not working in all cases but from existing remote desktop examples of this you get to 98% of the time works as expected. Remember you still have 2% of the time where something will happen the user is not expecting.

Both of these issue does remember to save/backup regularly(as in like every 5 to 10 mins or less) because at some point the application you are controlling is going to presume you did something different to what you really did with the mouse/pen due to the lost information. Both of these could presume you did something completely bad like it presume you requested to delete your complete work because that where it presumed the mouse pointer was going to end up. Simple one that shows these issues remotely quickly is trying to use applications like krita over a remote desktop connection of any form. .

Wayland and arcan comes both out of x.org X12 documentation. Wayland decided from the start it was going to be a local protocol and this gives it a lot more freedom on IPC. Arcan decide from the start it was going to be a remote protocol this means it has to be a single IPC connection. X11 protocol over its complete history could not make up it down right mind if it was a remote or local protocol. So you have sections of X11 designed as if it a remote protocol and then sections of X11 designed as if it is local protocol resulting in the worst of both worlds.

[Crion]

Yes sfwbar from sway developers support both the old X11 system tray with Xwayland and the new dbus StatusNotifierItem system tray.

I'm the author of sfwbar and this isn't quite right. sfwbar implements support for StatusNotifierItem, and doesn't support X11 tray (Freedesktop System Tray specification) directly. That said, you can use X11 tray applications with any SNI tray using XembedSNIProxy - a project originating from KDE. The proxy effectively creates an invisible X11 tray and passes through the tray icons to the SNI host. The results usually doesn't look great. X11 tray icons are small bitmaps (some are as small as 8x8 pixels) this is too small for modern HiDPI displays and there really is no good way to scale up an 8x8 pixel bitmap.

Also, while I originally wrote sfwbar as a taskbar for sway, I'm not a sway developer, and sfwbar should work with a variety of wayland compositors now.

[piotrj3]

I would say for true Wayland adaptation we need to more cover normal use cases.

Fractional scalling was for me one show stopper.

Another was allowing tearing (for gamers).

Another is proper Nvidia support (can be resolved 2 ways https://gitlab.freedesktop.org/xorg/...7#note_1694786 )

Another is HDR.

Another is high color depth (10bit+) support.

[Quackdoc]

I would say for true Wayland adaptation we need to more cover normal use cases.

Fractional scalling was for me one show stopper.

Another was allowing tearing (for gamers).

Another is proper Nvidia support (can be resolved 2 ways https://gitlab.freedesktop.org/xorg/...7#note_1694786 )

Another is HDR.

Another is high color depth (10bit+) support.

none of that is the biggest issues, the biggest issues by far are fragmentation, different compositors need different screen capture options, and even the unified options are flaky. Accsessibility tools are often specific to compositors. apps need to implement compositor specific features for valuble features (MPV's stay on top feature for instance) etc.

the large amount of fragmentation on wayland is absurd, driven by how slow it takes to get protocols adopted into wayland protocol and Portals, with developers of said projects often out right hostile to some of these features for they expose a "security risk". since I guess people can't be trusted with their own systems now.