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

[reba]

wlroots is not even a library per se. Nothing in my Fedora requires or uses it. It's a fucking pile of code Wayland developers couldn't care less about. And I've not heard of Gnome or KDE or anything else intending to use it. "Here, we have a library. It sorta could solve something. We believe so. Oh, no one actually uses it? Oh, crap."

You probably already know this, but for brevity there seem to be some that use it (from https://gitlab.freedesktop.org/wlroo...ch-use-wlroots):



Compositors


Is your compositor missing from this list? Please ping us on IRC and we'll add it!

• awc
• Cage
• Cagebreak
• ChameleonWM
• comfc
• dwl
• feathers
• fenestra
• gamescope <---
• Glass
• hikari <---
• hopalong
• inaban
• japokwm
• kiwmi
• KWinFT <---
• labwc
• Mahogany
• Marina
• Nucleus
• phoc
• pywm
• qtile
• river
• SimulaVR
• Skylight
• Sway <---
• Tabby
• tinybox
• Trinkster
• Way Cooler
• Waybox
• Wayfire <---
• Waymonad
• wio
• wio+
• wxrc
• vimway
• vivarium
• xuake

Wrapper libraries

• Chicken Scheme
• Common Lisp
• Go
• Godot
• Haskell
• OCaml
• Python
• Qt
• Rust
• Swift
• Zig

[Danny3]

Finally!
I am a bit surprised that this was not created sooner.
I find it pretty strange that a what seemed to be a one-man-only project called MadVr (for Windows) already had something like this in its control panel and it was quite good at reading the data.
Too bad that was not an open source project.
I hope this will be at least as good as that for reading the data.

[billyswong]

the DPI scaling is an issue in many places. but it is really important to be able to find the DPI of the display, which is a rather simple equation that you can figure out from EDID (a but of a hassle rn). (apply Pythagorean theorem to get diagonal pixels and diagonal res) but it would be better to query the DPI from some library such as this one IMO.

of course the user should be able to override it, but you still need a base DPI for best use. of course wayland needs to support it, and so do frameworks, but all issues are issues that need solved

Unless it is smartphone screen with 400+dpi, most display is perfectly okay to begin with 100% scale and let user to set each of them manually. A little bit less convenient but not a deal breaker as long as the setting is remembered between user sessions and plug/unplug. We don't want the scale setting hardcoded to follow the display manufacturer recommendation anyway. (And for smartphone screens, one shouldn't assume a 96 logical dpi for them so your Pythagorean theorem may be not a good solution.)

[Charlie68]

Wayland actually has an official implementation called Weston https://github.com/wayland-project/weston and they also provides libweston as a lib, but Kde and Gnome just refuses to use it, or contribute to it if it is not yet good enough.

Weston is a prototype and should not be used in production.

However I don't understand these wars of religion, Wayland is a protocol, maybe it was better to do it differently? Probably, but today we have this and there is an effort to move on to this as soon as possible. Gnome has already done this, Plasma I guess it will soon, since it works fine now, although there are some problems for some particular configurations.
So some speeches are quite useless in my opinion, fragmentation is a well-known thing in Gnu / Linux so you really don't understand the reason for the controversy. Distributions and DEs can all use the same compositor if they wanted to, but due to different ways of conceiving their DE they don't, hence the fragmentation, which is certainly not new.

[Adarion]

Oh wow, I had a Freudian mis-read. I read libsidplay and I was totally puzzled what a SID music (C64 days...) player has to do with wayland and compositing...
Must be this darn daylight savings time shift. ;-)

[Volta]

There's something horribly wrong about people who try to defend this abomination while trying to talk about fucking Wikipedia page about the crap no one cares about. This shows how horribly wrong the whole situation is.

Are you talking about the biggest piece of shit called xorg?

[Quackdoc]

Unless it is smartphone screen with 400+dpi, most display is perfectly okay to begin with 100% scale and let user to set each of them manually. A little bit less convenient but not a deal breaker as long as the setting is remembered between user sessions and plug/unplug. We don't want the scale setting hardcoded to follow the display manufacturer recommendation anyway. (And for smartphone screens, one shouldn't assume a 96 logical dpi for them so your Pythagorean theorem may be not a good solution.)

Don't think about what I said in a vacuum, apply it broadly.

Why do we need DPI UI scaling?

because the age of just monitors is gone. people are using linux phones, linux on TVs, Linux on the desktop, and even linux on their cars. we should no longer assume that the user's device is one of a few devices that fit the old paradigm. especially when we are coming into an age where mobile devices (phones) and stationary (like a desktop) are blurring the lines.

Pythagorean theorem is still important to phones, because if you have the DPI and the screen size you can do most scaling based on that, to get a good estimate on what kind of scaling you should be doing. physical DPI just being the number that represents the relationship between screen resolution and screen size. the framework should be able to find out the resolution it should be rendering at, and the default should be grounded in reality. DPI at a specific range is a good thing to target for. but of course, with intended ranges being all over the place that can be pretty hard. but you can get a general idea of the device from the size of the display. so using the size of the display, and DPI as factors you can make an educated guess on how the scaling should be done. if course it's always more complicated then that, but it's a good starting ground. and the user should always be able to change it, but like I said, it's best to have a good starting ground.


Why do we need to bypass compositor scaling?

I would consider the current method of using an integer scale, then scaling that to whatever display size you have, quite frankly shit. assume you have a 4k monitor. and compositors need to work around the issue. take gnome and kde. I have a 4k 27" monitor. 100 scale is too small, 200 scale is too big. so whats the solution? I use 150% scaling, or an effective res of 1440p. but wait, wayland doesn't support non integer scales, so what do we do? well we take 1440p multiple it by 2 so we render at 5120x2880 then downscale that to 4k. this present's some I hope obvious issues.

[billyswong]

Quackdoc Speaking of form factors, what about projectors? They don't have a fixed "physical DPI".

I agree the integer scale limit of current Wayland is ugly. They broke free of X11 with the claim of removing legacy baggage and enjoying a clean design. Then they created a short cut in the new spec immediately that bite everyone.

[Quackdoc]

Quackdoc Speaking of form factors, what about projectors? They don't have a fixed "physical DPI".

I agree the integer scale limit of current Wayland is ugly. They broke free of X11 with the claim of removing legacy baggage and enjoying a clean design. Then they created a short cut in the new spec immediately that bite everyone.

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.

[mdedetrich]

Wayland protocol does not cause fragmentation, it is the implementations that refuse to share the code.
P.S., X is also a protocol, and there are also multiple X server implementations.

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.

That is definitely true for Kde.

So I can understand that Kde and Gnome developers decide to come up with their own implementation that fits their own codebase, but duplicating everything sure isn't a good engineering practice.

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