Wayland Is Driving Fragmentation Around EDID Parsing - A Call To Fix That

[tildearrow]

Ah, here we go again, Wayland doesn't provide a standard(ized) WM/WC out of the box or is Wayland = Gnome?

Wayland is just a protocol, which explains this.

[szymon_g]

wayland is a gift that keeps giving, for sure

[bug77]

Wayland is just a protocol, which explains this.

That is not actually true.

From wikipedia (https://en.wikipedia.org/wiki/Communication_protocol):

A communication protocol is a system of rules that allows two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. The protocol defines the rules, syntax, semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.

Wayland is more than a protocol, because it doesn't stop at defining how some parties must talk to each other, it also defines which parties talk. That's the part that's giving everyone a hard time. Implementing Wayland is not like implementing IPv6 where you already have IPv4, it's a freaking rewrite of everything you already have.

[Zan Lynx]

My feeling is Wayland set out to improve security, developed a set of specs, broke a lot of functionality and called it date.
They had the best intentions and are still improving the protocol to add back some of the missing pieces, but my feeling is if you wanted to divide the existing ecosystem, you could hardly have done a better job.

There's nothing broken about EDID here. All of the compositors handle EDID exactly as well as X.org ever did.

But are you aware that EDID keeps being extended? For example, what do you think X.org would do with variable refresh rate, HDR EDID data, and some of the more interesting HDR colorspaces? Pretty much nothing. There's no point to extending X.org EDID because X cannot do anything useful with it.

Before all of the various compositors start to extend their EDID handling in all directions it will be good to lock it in to one authoritative library now.

[bug77]

There's nothing broken about EDID here. All of the compositors handle EDID exactly as well as X.org ever did.

But are you aware that EDID keeps being extended? For example, what do you think X.org would do with variable refresh rate, HDR EDID data, and some of the more interesting HDR colorspaces? Pretty much nothing. There's no point to extending X.org EDID because X cannot do anything useful with it.

Before all of the various compositors start to extend their EDID handling in all directions it will be good to lock it in to one authoritative library now.

Well, it doesn't really matter what X would do. Whatever X does, it has one implementation and that is by definition consistent. Wayland had this great idea everybody should reinvent their own wheels, now it deals with the fallout.

[Zan Lynx]

Well, it doesn't really matter what X would do. Whatever X does, it has one implementation and that is by definition consistent. Wayland had this great idea everybody should reinvent their own wheels, now it deals with the fallout.

No, there's like six X implementation that run on x86 hardware. Most of them are obsolete and haven't been maintained for ages but they're there.

XFree86
XSun
X386
DESQview/X
Accelerated-X by Xi Graphics
Metro-X

[Myownfriend]

Wayland is more than a protocol, because it doesn't stop at defining how some parties must talk to each other, it also defines which parties talk. That's the part that's giving everyone a hard time. Implementing Wayland is not like implementing IPv6 where you already have IPv4, it's a freaking rewrite of everything you already have.

The thing you to decided to compare it to a was a protocol and it's successor. Wayland is not X's successor nor was it ever intended to be. Wayland not having built-in backwards compatibility with X does not mean it oversteps the bounds of what a protocol should be.

[RomuloP]

What a lovely community we have ha?

[oiaohm]

No, there's like six X implementation that run on x86 hardware. Most of them are obsolete and haven't been maintained for ages but they're there.

XFree86
XSun
X386
DESQview/X
Accelerated-X by Xi Graphics
Metro-X

There is quite a few more than that. http://www.jcraft.com/weirdx/ has to be one of the most wacky you missed.

https://github.com/idunham/tinyxserver is more something normish.
For x11 servers you could use in x86 hardware over the time of X11 there is about 150 of them. Forks to the X11 display server was a lot more common that lot would think and yes most of them died out.

[Alexmitter]

There is quite a few more than that. http://www.jcraft.com/weirdx/ has to be one of the most wacky you missed.

https://github.com/idunham/tinyxserver is more something normish.
For x11 servers you could use in x86 hardware over the time of X11 there is about 150 of them. Forks to the X11 display server was a lot more common that lot would think and yes most of them died out.

There is also this X server in JS.