libdisplay-info Started To Address The Wayland Fragmentation Around EDID/DisplayID

[billyswong]

I think you are too hung up on the physical DPI part, it;s just a guideline like anything else, though I suppose a sophisticated projector could measure distance then calculate DPI based on that, but again, it's a guideline to bring us to the point where we can have sensible defaults and finally migrate away from the current scaling. to a scaling system that doesn't suck.

I was just trying to say this lib is irrelevant to the current mess caused by defect in Wayland protocol. And no, what scaling a projected display should use depends on both (i) how large the screen is projected and (ii) how far away the viewer sit. A "sophisticated" projector can detect (i) but not (ii).

[NobodyXu]

You are talking about Linux here, this is scapeboating the problem onto an ecosystem that will always have this problem by design. In the linux landscape, people code things in different languages, in different paradigms and in different ways.

So actually in practice, Wayland did cause fragmentation and yes X is strictly a protocol but it actually has a usable central implementation. Wayland did not, it had a reference implementation which wasn't actually usable by any real compositor.

Wayland should have been released with an actual usable implementation, something like wlroots. It would have actually sped up the adoption of Wayland because creating a protocol out of thin air without any use cases creates havoc and chaos which is actually what happened.



Thats what happens when you only release a protocol, doing so creates this situation exactly. Throwing the "this is not good engineering" catchphrase completely trivializes the structural/organization aspects of doing actual engineering.

Remember that Linux is decentralized by design which means that if you only release a protocol then don't expect the Linux ecosystem to suddenly come together and create a central implementation to share code any time soon especially when your protocol has no real proof that it actually works (which by definition it doesn't because you only released a protocol). Wayland should have released an implementation when they released the protocol. This is open source after all, and resources are already stretched (and yeah, good luck getting the 10+ different DE's/compositors together to come up with some central implementation).

That's true, but KDE and Gnome also need to take some of the blame there.

Being the two most popular desktop environments, if they refuse to participate in developing a de facto implementation, then you know it is unlikely to have one.
And that is exactly what happened here, they refused to cooperate to create one usuable implementation shared by KDE and Gnome and go on to develop their own in-house implementation.

As for the other 10+ different DEs/compositors, xfce is going to use either mutter or wlroots implementation https://wiki.xfce.org/releng/wayland...der_discussion.

Lxqt is also going down the same path, reusing mutter/kde/wlroots/qtwayland implementation https://github.com/lxqt/lxqt/issues/10.

For other niche compositors, it is likely they will take the same path to reuse mutter/kde/wlroots or maybe Qt's wayland implementation, or they will get rewritten into using these libraries.

https://github.com/solarkraft/awesom...ts#compositors shows a list of compositors, some of them reimplement dwm, xfwm, openbux/fluxbox, i3 using wlroots.

So while there is fragmentation, looks like most other compositors/DEs will just use mutter/kde/wlroots/qtwayland instead of rolling out their own wayland implementation.

Edit:

It seems that Enlightment is using Weston for their wayland implementation https://www.enlightenment.org/about-wayland

[Quackdoc]

I was just trying to say this lib is irrelevant to the current mess caused by defect in Wayland protocol. And no, what scaling a projected display should use depends on both (i) how large the screen is projected and (ii) how far away the viewer sit. A "sophisticated" projector can detect (i) but not (ii).

well, i've stated my points that I think physical DPI is a needed factor and this lib will help that a lot. also you can make an educated guess on how far away the user is from the screen. sure the guess might not be right all the time, but it doesn't need to, it needs to be right most of the time. and using an educated guess is generally good enough. even on android you can override logical dpi. but having a good enough most of the time default is important too.

[pdbecid]

I hope this helps with custom resolutions. I have an ultra wide monitor and for whatever reason on Linux it just goes up to 1920x1080. This also happens with my 4k TV. On X.Org at least I can use use xrandr and create a custom profile but with Wayland you have to use kernel parameters and they can be hit or miss. Hopefully by next year this is a thing of the past.