X.Org Server 21.1.2 Released With Security Fixes, Back To Pretending All Displays Are 96 DPI

[DanL]

Well, technically, while the wheel is a very old technology, modern car tires are not. Both are wheels in a broad sense but they are not the same wheels.

Really? The heck you say..
Way to miss the point of the joke/analogy.

[oiaohm]

Why is color management being done in the Wayland protocol then? By your definition shouldn't it be done with D-Bus instead?

The reality is color management is part wayland protocol and part dbus colord protocol and part wayland compositor.

https://www.freedesktop.org/software/colord/intro.html

Yes Weston still is using colord the dbus protocol for many color management operations.

https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/winsys_color_pipeline.rst

The montor color profiles under Wayland still come from colord that does not in fact change. The big difference is that the wayland compositor can and will do transformations to make application output align with monitor.

https://gitlab.freedesktop.org/swick/wayland-protocols/-/blob/2e4c52af07ac220a1c4544c610f7a9fd56c7b948/unstable/color-management/color-management-unstable-v1.xml

Good read do notice how to get monitor ICC profile is not there. Yes kind of appears with the create from ICC profile. Not one bit of the color-management feature being added to wayland is how to get a monitors calibration. The wayland protocol for color management all about being able to tell the compositor what the compositor needs to know.

winsys_color_pipeline.rst Figure 2.diagram is a little off with the monitor profiles by the arrows appear to come from the compositor to the application. When in reality monitor profiles come from colord to application and wayland compositor.

The wayland protocol color management protocol is really not bi-directional. The main task is to send data to the compositor. global hotkeys would be like application wanting monitor color profile right and and in color management this is colord a dbus/polkit protected service.

tildearrow so wayland protocol adding a color management protocol does not make data query or global hotkeys by wayland protocol a valid option at all. Yes its you missed that colord exists.

Like it or not color management protocol in Wayland protocol is about providing the compositor with information while fairly much leaving the application in the dark. If the application does not want to be in the dark it will interface with colord by dbus to get informed about the monitors and so on. Yes colord shares that information with the compositor and the applications. Reality this is how most wayland protocols are.

Wayland protocols can mostly be thought of as a black hole data is to go in the direction of Wayland compositor with very little having enough speed to return to the application. Dbus/polkit is for the stuff that is meant to return to the application in any major way. This is fairly much how MacOS does it as well just with the parts differently named.

[Paradigm Shifter]

To be honest, I've never really understood why manually setting information like diagonal, aspect ratio and resolution (although aspect ratio should really be worked out from this) isn't exposed more simply to the user. I don't exactly change monitors regularly - even with external displays I'm usually connecting to the same two or three (two being projectors) at different times. I've lost count the number of times (in both Windows and Linux) over the years where I've had to go digging in Xorg.conf or installing something extra to manually create a resolution which, for whatever reason, the OS just does not want to know exists.

For some reason, nVidia cards and televisions seem particularly bad at this - it's a 1080p screen, dammit, why do you insist on only offering me 1792x984 and still overscanning the edges of the screen?!

[MadeUpName]

Still waiting for SDDM 20 so I can drop X and never have to worry about Xploits ever again.

[Sonadow]

Still waiting for SDDM 20 so I can drop X and never have to worry about Xploits ever again.

What the hell.

Just make systemd boot to multi-user.target and start the compositor from the TTY. Or use GDM.

[brad0]

Maybe in 10 years I'll be able to replace X with Wayland. Until then I use what works. Typical open source community shitshow. Same kind of shitshow as BtrFS vs ZFS. We'll keep trying to hoist this alternative / replacement on you but it's not even remotely feature complete and riddled with bugs.

[oiaohm]

To be honest, I've never really understood why manually setting information like diagonal, aspect ratio and resolution (although aspect ratio should really be worked out from this) isn't exposed more simply to the user. I don't exactly change monitors regularly - even with external displays I'm usually connecting to the same two or three (two being projectors) at different times. I've lost count the number of times (in both Windows and Linux) over the years where I've had to go digging in Xorg.conf or installing something extra to manually create a resolution which, for whatever reason, the OS just does not want to know exists.

For some reason, nVidia cards and televisions seem particularly bad at this - it's a 1080p screen, dammit, why do you insist on only offering me 1792x984 and still overscanning the edges of the screen?!

The fact this problem effects Linux, Windows and Mac OS fairly equally should kind of tell you its a deeper problem.
Fairly much all these problems fall bad EDID bad news this has a lot of causes.
1) Monitor providing invalid/incorrect or no EDID
2) Monitor cable being defective on the pins/wires EDID information transfers over yes that is the Enhanced Display Data (E-DDC) that i2c system on hdmi and Auxiliary channel on display port.
3) GPU being glitched in the section of it that does the EDID transfer.
4) GPU glitching for some reason when it transfers EDID information back to host.(this can be bad ram and other things on the GPU like too far overclocked).
5) KVM/HDMI switch.... Basically some box in the middle between you and the monitor decides to be defective and destroy or replace the EDID information resulting in invalid information..
6) Vendors not being willing to work with each other to solve the common problem of invalid EDID information in operating systems..

Notice 1 to 5 of cause of the problem has nothing to-do with the operating system or the vendors drivers but are all hardware side. Most of these are problems that will happen to someone.

Number 1 having to buy a Edid emulator/inserter box is annoying and having to have extra box with monitor/tv so it works right is annoying but at least this one is fixable for a price tag in a OS neutral way.. Yes problem number 5 can be solved by the same box but you can start running into transfer loss problems..

Number 2 the monitor cables is particular problematic because people cannot afford to own decent cable test tools. Yes a basic conductivity testers for less than 20 dollars but they will not tell you if data transfer over the cable is going to be inside specification for noise or if the wire resistance is inside specification. Yes cables can degrade with age. Please note having conductivity tester for you monitor cables will still save you a hell load issues over the time noticing cables that don't have all their pins connected correctly. Please note when I say decent cable test tools I am talking about tools that have a 15 thousand dollar price tag that truly test if a cable is up to specification or not. If someone could make a tool like this for 100-500 dollars that worked they would have lots of sales. Heck even 1000 dollars could work due to the number of hours people waste with dud cables.

3 and 4 these are when having display emulators in your toolbox that you can plug straight into the graphics card and notice you are being reported garbage. Yes this allows you to return a defective card before living with the nightmare.

Now on to the real headache.

Yes 6 is the same pulling teeth problem we have had with Nvidia with KMS/DMA Buf and so on. Yes this effects windows and Linux and macos there is no common system that all graphics driver vendor universally accept to record a monitors last EDID. Or a common system to say to user hang on I don't have a valid EDID for this monitor maybe you have a hardware problem.

Something that would be useful is if the gpu could report if all pins that should be connected are. Yes GPU hardware from since ever has had no cable diagnostics. Network cards in the last decade or so have started adding cable diagnostics into the card.

[caligula]

A friendly CVE reminder that in most cases you can and should run your X rootless

Not all login managers support rootless X yet. For instance the last time I tried with novideo and sddm, it refused to launch X.

[caligula]

1) Monitor providing invalid/incorrect or no EDID
5) KVM/HDMI switch.... Basically some box in the middle between you and the monitor decides to be defective and destroy or replace the EDID information resulting in invalid information..

My monitor has built-in KVM switch, kind of, in the form of 3 different inputs (one DP, two HDMIs). When connected to an inactive port, the monitor advertises 640x480 resolution. When active, the resolution grows to native 2560x1440. This is particularly annoying because the Linux login managers don't switch the resolution after the display input switch. I've tried GDM, SDDM, LightDM. Some login managers clone the login prompt but some render it only on this 640x480 screen. The output will be garbled when you try to log in. Usually the login prompt won't even fit in a 640x480 screen.

[oiaohm]

Not all login managers support rootless X yet. For instance the last time I tried with novideo and sddm, it refused to launch X.

https://github.com/sddm/sddm/blob/develop/data/man/sddm.conf.rst.in

sddm should be able to get half way to rootless some time soon. Yes a patch has been merged in to allow sddm to launch the logged in X11 as user but the sddm X11 is still root.

Its puling teeth to get display managers and other bits of software to not run with more privilege than what is really required.