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

[WorBlux]

https://www.kernel.org/doc/html/late...uide/edid.html
Since kernel mode setting exists EDID processing is required in the Linux and Freebsd kernel and any other kernel with kernel mode setting that attempts to deal with random screen changes. We do still have the problem of Nvidia being their own special form of different here not supporting kernel mode setting. I am not suggesting a new parser at all its more that we agree to use the EDID parser that has to be there for kernel mode setting.

Remember to show the early text output of the Linux kernel on modern hardware you have to do a mode set or can be a black screen of nothing what is not useful if you have a error. Of course to-do that mode set you must process the EDID data to know what modes can be set.

Sure, but does early boot need to know weather an audio stream is available or variable refresh is supported? That's the point of the library, exposing things the kernel doesn't care about, or doesn't see the need to expose (much less in a human readable format)

Looking further into it, it looks like a binary field format so it's not the sort of parse I feared.
The in-kernel code seems just to decode the base block, pick a default mode and exports a small part of what it figures out.

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_edid.c

I still don't think you should to de everything in-kernel though, and maintaining the structure and interface there seems like a pain.

[oiaohm]

Sure, but does early boot need to know weather an audio stream is available or variable refresh is supported? That's the point of the library, exposing things the kernel doesn't care about, or doesn't see the need to expose (much less in a human readable format)

Audio stream would in time be a yes early boot linux kernel will need to know about that for blind or vision impaired people booting the kernel. Yes it is possible to morse code error data and other things. Variable refresh rate at this stage we don't have monitors that demand it usage off the get go.

Looking further into it, it looks like a binary field format so it's not the sort of parse I feared.
The in-kernel code seems just to decode the base block, pick a default mode and exports a small part of what it figures out.

This is currently true. Is the Linux kernel really decoding everything that the kernel should out of the EDID in early boot to support those with disabilities the answer is in fact no.

Yes there is a valid question of edid process should be in kernel space or should it be a usermode helper of the kernel due to how problematic the edid data could be.

Its like why would I need HDR in early boot this is until you work out this would allow text on the monitor to be displayed at a higher contrast level . There are really very few features that kernel should not be decoding of EDID to make sure it can display early boot in the best possible way.

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_edid.c

Take a closer look at this. Think of all the VR headsets marked as non desktop so not support by Linux kernel early boot. This makes it hard to make a VR only setup that will allow user to handle errors without needing extra monitor.

WorBlux like it or not the Linux kernel for early boot to support the most number of people possible need to decode way more EDID. This extra decode for some parts could be a userspace helper able to be placed in the initramfs with a userspace library that is part of the kernel.

WorBlux I was think what should be supported by the kernel so kernel mode setting is right for as many possible as possible. You only went looking at what there. Reality is over 90% of the edid need to be decode and processed for early boot.

[microcode]

All window managers just display the same app windows as all others. So all of the code in a compositor ought to be straightforward. Why do we even use libraries at all, all code is logical, just rewrite everything every time. I don't think any competent developer would decide to write code from scratch if there was a competent common implementation available.

Well, the suitability of existing implementations of something isn't always about some general measure of "competence". There are other considerations like:

• can we adequately synchronize the release of this library to our release cycle, so that we can resolve bugs upstream and count on them being fixed when we release our next version?
• does the library fit well in our threading/process model, and can it be adapted to run in a sandbox if we elect to use one of those?
• does it copy the data into a structure or does it parse it in place?
• are the datastructures and datatypes exposed by the library well matched with our code, or is there an impedance mismatch?
• is the library written in the same language, and if not, is it easy to link against our program?
• is the language or style the library is written in sufficiently familiar or tasteful that our own developers will feel comfortable contributing to it?

You can't really justify a blanket statement like the one in your last sentence, it is not specific enough; furthermore you are implying that any developer who does not elect to use an existing implementation of something is not a "competent developer", which I think is just untrue.

[kcrudup]

Or my laptop that can under-clock the display to 48Hz on battery.

Whoa! This is a thing, huh? I just set mine to this, good to know!

Do you have a script already that'll work with tlp (etc.) to do this automatically, or should I just gin something up with xrandr?

[WorBlux]

oiaohm That makes sense, though I am skeptical of the utility of HDR for text.

[oiaohm]

oiaohm That makes sense, though I am skeptical of the utility of HDR for text.

It depends on the HDR monitor. Some HDR monitors in 8bit colour modes don't in fact use backlight dimming. So its possible to have a better black to white contrast on some monitors when they are in HDR mode instead of standard.

The ideal world the Linux kernel can process all of EDID and the the system can set the monitor mode once at boot then not do it again. This is kind of required with some highly questionable TV HDMI inputs. The idea that you can process EDID latter and change modes can turn out to be a false presume resulting in user having black screen of nothing as well.

The reality is a big bugger where you may only have one shot to see the monitor mode and to change mode may be power cycle everything. This is why I kind of see EDID as needing to be a kernel level tool that is shareable with compositor. Not a compositor level solution. With the horrible hardware EDID processing in the compositor has some serous limits that are only fixed if the kernel can do first mode set right.

[WorBlux]

It depends on the HDR monitor. Some HDR monitors in 8bit colour modes don't in fact use backlight dimming. So its possible to have a better black to white contrast on some monitors when they are in HDR mode instead of standard.

I don't think any LCD screen has enough backlight resolution to help text (near pixel contrast does not increase). The dimming will help you get a blacker black within the zone, but at the expense of bright spots within the zone. The difference in total brightness may or may not help perception of text depending on room lighting and total brightness of the screen.

And OLED is still a rare tech for monitor applications. Though weather the screen simply scales 8-bit inputs or maps it into the native color space is a per-screen and sometimes settings dependent factor.

The ideal world the Linux kernel can process all of EDID and the the system can set the monitor mode once at boot then not do it again. This is kind of required with some highly questionable TV HDMI inputs. The idea that you can process EDID latter and change modes can turn out to be a false presume resulting in user having black screen of nothing as well.

Unfortunate idiocy on the TV's part, but I guess we do have to deal with the situation as it is.

The reality is a big bugger where you may only have one shot to see the monitor mode and to change mode may be power cycle everything. This is why I kind of see EDID as needing to be a kernel level tool that is shareable with compositor. Not a compositor level solution. With the horrible hardware EDID processing in the compositor has some serous limits that are only fixed if the kernel can do first mode set right.

I am starting to agree with you, it should be in the GPU subsystem or init-level library. Looking at my setup, some of the info is exposed in sysfs, as well as the raw EDID. Though if you did have an standard way to expose it, that could help kernel integration.

As you pointed out, on close examination there's a lot of information there that's simply too useful elsewhere to ignore.

[nranger]

Whoa! This is a thing, huh? I just set mine to this, good to know!

Do you have a script already that'll work with tlp (etc.) to do this automatically, or should I just gin something up with xrandr?

Sorry, no tlp integration that I can share. I just went the dumb route and have an xrandr script I can run from my dock when I want. The same script also calls zenstates to undervolt my Ryzen 3500U, turns off turbo, sets the cpufreq governor to conservative, and runs powertop --auto-tune.

[oiaohm]

I don't think any LCD screen has enough backlight resolution to help text (near pixel contrast does not increase). The dimming will help you get a blacker black within the zone, but at the expense of bright spots within the zone. The difference in total brightness may or may not help perception of text depending on room lighting and total brightness of the screen.

I did not write it that well. I was referring to LCD HDR. There is horrible problem that the brighter the backlight the greater the light bleed with LCD so worse.

Yes with text you would want to drop all the zones equally. Some LCD HDR controller do something stupid in 8bit mode this is all zones to max brightness this is now basically shot the 8bit mode black level. Yes using the brightness control on the monitor may not be able to get your contrast back because of the zone uplift.

Unfortunate idiocy on the TV's part, but I guess we do have to deal with the situation as it is.

Be it a TV or a HDR monitor who ever designed the controller inside can be a absolute idiot of the worst kind. Yes we have to deal with those situations how every they land.

I am starting to agree with you, it should be in the GPU subsystem or init-level library. Looking at my setup, some of the info is exposed in sysfs, as well as the raw EDID. Though if you did have an standard way to expose it, that could help kernel integration.

As you pointed out, on close examination there's a lot of information there that's simply too useful elsewhere to ignore.

Really its not just that the more you look at the EDID information and think in early boot is this useful to have been processed. Its like the ignoring virtual reality headsets or audio out... The areas of the EDID the Linux kernel ignores ends up restricting the styles of systems we can create.

Yes EDID information is useful to compositors and other items latter to know what options the devices have. The kernel known those options in boot can be useful for disability access or setting up odd hardware. I would love to see a VR setup that does not need a normal monitor even when things go wrong and this is not really possible if the kernel cannot output errors on VR screens.

Another thing to consider when do you want to find out a monitor has a defective EDID. If at monitor conection(this could be boot)the Linux/Freebsd kernel proper processes the monitor EDID and detect error this could prevent a EDID device being used as a exploit to cause a buffer overflow/error else where.