6 ms·

> 2. This reminds me why I no longer use linux on the desktop Lest anyone read this and nodded along: This was a defect in the LG monitor the OP worked around,

by sho_hn 3y ago

> 2. This reminds me why I no longer use linux on the desktop Lest anyone read this and nodded along: This was a defect in the LG monitor the OP worked around, not anything to do with Linux.

Arnavion 3y ago
It would be nice to figure out why Windows and MacOS evidently didn't have the problem. If there's some additional probing that they're doing to catch the monitor out on its lies, Linux could do that too.
- sho_hn 3y ago
  Good question indeed. One thing I could imagine is that Linux is giving preference to using the values in the DisplayID block as it's the newer standard, and since EDID/DisplayID compliance has improved over time the logic may be "the newer one is more likely to be correct". In the meantime perhaps Win/Mac continue to look at the classic EDID data, and if they do, it likely gets less test coverage from manufacturers. Pure speculation. Edit: From https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/display https://learn.microsoft.com/en-us/windows-hardware/design/co... > Windows does not support DisplayID 1.x blocks, and always ignores them. No explanation is given. The LG display sends a DisplayID 1.2 block.
  - Arnavion 3y ago
    If that's also true of MacOS, that would mean LG made the effort of adding extra data that their tested systems didn't actually use and then got it wrong anyway, which would be funny.
    - sho_hn 3y ago
      Random anecdote: I work in the automotive industry, where we often use fancy unusual screen hardware a couple of years before it turns up in home consumer electronics or phones. For example special multi-axis curved stuff, dynamic angular privacy filters, or haptic feedback using electrostatic modulation of resistance instead of vibration motors (that allows you to make the screen feel rough and scaly or glidy, give UI elements a feel-able shape, etc.). One time, we were told to use earplugs at work for a few days, because of a pre-release firmware bug that could in theory, if other safety mechanisms also failed, cause the haptics to potentially emit an ear-piercing low-frequency tone ... Temporary EDID bugs, otoh, I've seen so many times. :)
      - hkgjjgjfjfjfjf 3y ago
        [dead]
      - Arrath 3y ago
        > One time, we were told to use earplugs at work for a few days, because of a pre-release firmware bug that could in theory, if other safety mechanisms also failed, cause the haptics to potentially emit an ear-piercing low-frequency tone ... Wow, on-demand tinnitus is one hell of a failure mode.
    - planede 3y ago
      What I imagine is that the engineers assigned to it started off from an EDID from some other display they have, made changes to it, tested on Mac and Windows, never tested on Linux.
  - nyanpasu64 3y ago
    That's odd, I was definitely able to add a DisplayID 1.3 extension block (128 extra bytes appended) to a CRT monitor's 128-byte EDID data using CRU, then have Windows 11 see those extra resolutions (when the CRT was plugged into a DP-to-VGA adapter). Though I ended up switching to CTA-861 (HDMI extension blocks) with all the HDMI YCbCr/audio nonsense turned off, because 010Editor and edid2json could understand CTA-861 but not DisplayID (though I learned from this article that git://linuxtv.org/edid-decode.git, or https://git.linuxtv.org/edid-decode.git https://git.linuxtv.org/edid-decode.git, has better support for EDID standards than the other tools). Another oddity is that when I run edid-decode on the DisplayID 1.3 file created by CRU, edid-decode reports the block as "Version: 1.2" instead. Wonder what's up with that.
- 10000truths 3y ago
  Mere speculation on my part, since I have no familiarity with the HDMI or DisplayPort protocols: 1. Windows/macOS might have a "quirks table" that hardcodes fixes for spec-violating devices. 2. Windows/macOS might ignore some reported EDID values and derive their own when they determine that the display behaves differently from what is reported (e.g. by recording response packet timings).
  - wtallis 3y ago
    > (e.g. by recording response packet timings) Even modern packetized display interfaces like DisplayPort are still fundamentally a one-way firehose for the pixel data. There's no provision for acknowledging or retransmitting data packets, and forward error correction is optional. The bidirectional sideband channels used for stuff like EDID are not timing-sensitive like the pixel data stream.
- Guvante 3y ago
  It could be the failure mode is identifiable on the OS and Linux didn't add detection and fallback support. Honestly though it could also be workarounds. Windows is king at making stuff like this work by hard coding overrides. E.g. a custom driver for this display.
InitialLastName 3y ago
A defect that was not in evidence for MacOs or Windows.
- sho_hn 3y ago
  Sure, but this is exactly equivalent to saying "This is why I stopped using Firefox for web browsing" in 2005 and sticking to MSIE 4/5 and its take on standards, because the websites always work. Reasonable and practical, but which direction did get us more progress for the web? EDID exists for a reason and is a good thing; monitors providing reliable, useful EDID data is something to strive for. It's gotten a lot better over the years as the result of operating systems using and enforcing it more. Monitors with bogus/garbage EDID used to be a lot more common 10+ years ago.
- hyperman1 3y ago
  Basically, they tested it on these 2 and then shipped it. If it would fail on win or osx, LG would not ship it. At first, this seems a reason not to use Linux, but a future upgrade of win/osx will break your hardware. Tons of hardware gets obsoleted this way. Meanwhile, Linux will just keep on working.
  - trelane 3y ago
    > Basically, they tested it on these 2 and then shipped it. If it would fail on win or osx, LG would not ship it. Yep. I first and foremost look fir Linux support explicitly called out in the system requirements. If I can't find it, I look for reviews mentioning Linux. But explicitly supported is always the best, ideally backed by reviews that confirm it.
- wtallis 3y ago
  It's not at all hard to find EDID bugs that affect Windows and macOS, especially where variable refresh rate or HDR or 10-bit color or DSC are involved. And in those situations, working around the monitor bug tends to be just as hard (Windows) or impossible (Mac).
  - 3y ago
sokoloff 3y ago
This is mostly true* and beyond irrelevant to the point GP was making (that they no longer use Linux on the desktop because of annoyances like this). From the original article "It works great on both Mac and Windows, but on Linux it displays just a black panel" and, amusingly, after the fix: "One issue is that now my second monitor isn't displaying anything. When I go into Display Settings, it seems like my computer thinks that both monitors are sending this EDID so it's put the second monitor into the wrong mode." Seems like 2023 isn't the Year of the Linux Desktop either. * I say "mostly" because to 99+% of the people, telling them "this monitor works great on both Mac and Windows and shows nothing but a black screen on Linux, but don't worry; it has nothing to do with Linux" will get you some pretty quizzical looks.
- nyanpasu64 3y ago
  If you tell Linux to replace the EDID firmware with a custom binary, without telling it which output to override, I'm not surprised Linux acts the way it does. I can confirm on my machine that overriding EDID for a specific connector works as expected. https://wiki.archlinux.org/title/kernel_mode_setting#Forcing_modes_and_EDID https://wiki.archlinux.org/title/kernel_mode_setting#Forcing... says that you can do it for multiple connectors using commas to separate values, though I have not tried. Though one gotcha is that on my RX 570, `ls -ld /sys/class/drm/*/edid` prints HDMI-A-1 and -2, which is also the name of the display outputs on Wayland, but on X11 xrandr identifies these outputs as HDMI-1 and HDMI-2. (I think you have to use HDMI-A-1 in the kernel command line, but I have not tried.)
- npunt 3y ago
  Yep, as much as we want hardware and software to be conformant to whatever standards exist, in practice an important part of the job of a production OS is to work around the myriad quirks of hw/sw users will likely encounter. Standards are the input, experience is the output, and users judge on output. Related is yesterday's post about ensuring DOS app compatibility in Win95 [1] [1]: https://news.ycombinator.com/item?id=37311508 https://news.ycombinator.com/item?id=37311508
  - sho_hn 3y ago
teawrecks 3y ago
We don't know that though. The fact that it presumably works everywhere except Linux makes me think there's still a bug in that `edid-decode` path. And as far as I can tell from the article, OP just assumed the display supported 60hz because it happened to show an image when they set it to that.
Moto7451 3y ago
I don’t think that’s actually correct either. The monitor is advertising Freesync/GSync variable refresh rate. The Ultragear monitors are high end gaming monitors so they come with 48-240Hz VRR on some monitors. That’s the 48-144hz extension in the EDID of this monitor. Based on debugging some issues I was having in macOS, I discovered from various Reddit and forums that Linux doesn’t handle that well depending on your driver stack/how you connect. If you’re on very modern hardware, kernels, and the OEM drivers it’s a better situation. macOS also has partially broken support for Freesync (or ProMotion as Apple brands it) at the moment on Intel machines. I have an Asus GSync monitor with 48-144hz compatibility. This works over DisplayPort on my M2 Pro MacBook. On my RX6800 equipped Intel Mac I get 100Hz over DisplayPort 1.4 and 120Hz over HDMI 2.0 due to a DSC bug affecting Intel Macs. Even without that bug, 120Hz sometimes presents the OP’s issues between startup and login so I use 100Hz. The betas for the next macOS apparently fix this. Either way, it’s a fun patch

by sho_hn 3y ago

> 2. This reminds me why I no longer use linux on the desktop Lest anyone read this and nodded along: This was a defect in the LG monitor the OP worked around, not anything to do with Linux.

Arnavion 3y ago

It would be nice to figure out why Windows and MacOS evidently didn't have the problem. If there's some additional probing that they're doing to catch the monitor out on its lies, Linux could do that too.

sho_hn 3y ago
Good question indeed. One thing I could imagine is that Linux is giving preference to using the values in the DisplayID block as it's the newer standard, and since EDID/DisplayID compliance has improved over time the logic may be "the newer one is more likely to be correct". In the meantime perhaps Win/Mac continue to look at the classic EDID data, and if they do, it likely gets less test coverage from manufacturers. Pure speculation. Edit: From https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/display https://learn.microsoft.com/en-us/windows-hardware/design/co... > Windows does not support DisplayID 1.x blocks, and always ignores them. No explanation is given. The LG display sends a DisplayID 1.2 block.
- Arnavion 3y ago
  If that's also true of MacOS, that would mean LG made the effort of adding extra data that their tested systems didn't actually use and then got it wrong anyway, which would be funny.
  - sho_hn 3y ago
    Random anecdote: I work in the automotive industry, where we often use fancy unusual screen hardware a couple of years before it turns up in home consumer electronics or phones. For example special multi-axis curved stuff, dynamic angular privacy filters, or haptic feedback using electrostatic modulation of resistance instead of vibration motors (that allows you to make the screen feel rough and scaly or glidy, give UI elements a feel-able shape, etc.). One time, we were told to use earplugs at work for a few days, because of a pre-release firmware bug that could in theory, if other safety mechanisms also failed, cause the haptics to potentially emit an ear-piercing low-frequency tone ... Temporary EDID bugs, otoh, I've seen so many times. :)
    - hkgjjgjfjfjfjf 3y ago
      [dead]
    - Arrath 3y ago
      > One time, we were told to use earplugs at work for a few days, because of a pre-release firmware bug that could in theory, if other safety mechanisms also failed, cause the haptics to potentially emit an ear-piercing low-frequency tone ... Wow, on-demand tinnitus is one hell of a failure mode.
  - planede 3y ago
    What I imagine is that the engineers assigned to it started off from an EDID from some other display they have, made changes to it, tested on Mac and Windows, never tested on Linux.
- nyanpasu64 3y ago
  That's odd, I was definitely able to add a DisplayID 1.3 extension block (128 extra bytes appended) to a CRT monitor's 128-byte EDID data using CRU, then have Windows 11 see those extra resolutions (when the CRT was plugged into a DP-to-VGA adapter). Though I ended up switching to CTA-861 (HDMI extension blocks) with all the HDMI YCbCr/audio nonsense turned off, because 010Editor and edid2json could understand CTA-861 but not DisplayID (though I learned from this article that git://linuxtv.org/edid-decode.git, or https://git.linuxtv.org/edid-decode.git https://git.linuxtv.org/edid-decode.git, has better support for EDID standards than the other tools). Another oddity is that when I run edid-decode on the DisplayID 1.3 file created by CRU, edid-decode reports the block as "Version: 1.2" instead. Wonder what's up with that.
10000truths 3y ago
Mere speculation on my part, since I have no familiarity with the HDMI or DisplayPort protocols: 1. Windows/macOS might have a "quirks table" that hardcodes fixes for spec-violating devices. 2. Windows/macOS might ignore some reported EDID values and derive their own when they determine that the display behaves differently from what is reported (e.g. by recording response packet timings).
- wtallis 3y ago
  > (e.g. by recording response packet timings) Even modern packetized display interfaces like DisplayPort are still fundamentally a one-way firehose for the pixel data. There's no provision for acknowledging or retransmitting data packets, and forward error correction is optional. The bidirectional sideband channels used for stuff like EDID are not timing-sensitive like the pixel data stream.
Guvante 3y ago
It could be the failure mode is identifiable on the OS and Linux didn't add detection and fallback support. Honestly though it could also be workarounds. Windows is king at making stuff like this work by hard coding overrides. E.g. a custom driver for this display.

InitialLastName 3y ago

A defect that was not in evidence for MacOs or Windows.

sho_hn 3y ago
Sure, but this is exactly equivalent to saying "This is why I stopped using Firefox for web browsing" in 2005 and sticking to MSIE 4/5 and its take on standards, because the websites always work. Reasonable and practical, but which direction did get us more progress for the web? EDID exists for a reason and is a good thing; monitors providing reliable, useful EDID data is something to strive for. It's gotten a lot better over the years as the result of operating systems using and enforcing it more. Monitors with bogus/garbage EDID used to be a lot more common 10+ years ago.
hyperman1 3y ago
Basically, they tested it on these 2 and then shipped it. If it would fail on win or osx, LG would not ship it. At first, this seems a reason not to use Linux, but a future upgrade of win/osx will break your hardware. Tons of hardware gets obsoleted this way. Meanwhile, Linux will just keep on working.
- trelane 3y ago
  > Basically, they tested it on these 2 and then shipped it. If it would fail on win or osx, LG would not ship it. Yep. I first and foremost look fir Linux support explicitly called out in the system requirements. If I can't find it, I look for reviews mentioning Linux. But explicitly supported is always the best, ideally backed by reviews that confirm it.
wtallis 3y ago
It's not at all hard to find EDID bugs that affect Windows and macOS, especially where variable refresh rate or HDR or 10-bit color or DSC are involved. And in those situations, working around the monitor bug tends to be just as hard (Windows) or impossible (Mac).
- 3y ago

sokoloff 3y ago

This is mostly true* and beyond irrelevant to the point GP was making (that they no longer use Linux on the desktop because of annoyances like this). From the original article "It works great on both Mac and Windows, but on Linux it displays just a black panel" and, amusingly, after the fix: "One issue is that now my second monitor isn't displaying anything. When I go into Display Settings, it seems like my computer thinks that both monitors are sending this EDID so it's put the second monitor into the wrong mode." Seems like 2023 isn't the Year of the Linux Desktop either. * I say "mostly" because to 99+% of the people, telling them "this monitor works great on both Mac and Windows and shows nothing but a black screen on Linux, but don't worry; it has nothing to do with Linux" will get you some pretty quizzical looks.

nyanpasu64 3y ago
If you tell Linux to replace the EDID firmware with a custom binary, without telling it which output to override, I'm not surprised Linux acts the way it does. I can confirm on my machine that overriding EDID for a specific connector works as expected. https://wiki.archlinux.org/title/kernel_mode_setting#Forcing_modes_and_EDID https://wiki.archlinux.org/title/kernel_mode_setting#Forcing... says that you can do it for multiple connectors using commas to separate values, though I have not tried. Though one gotcha is that on my RX 570, `ls -ld /sys/class/drm/*/edid` prints HDMI-A-1 and -2, which is also the name of the display outputs on Wayland, but on X11 xrandr identifies these outputs as HDMI-1 and HDMI-2. (I think you have to use HDMI-A-1 in the kernel command line, but I have not tried.)
npunt 3y ago
Yep, as much as we want hardware and software to be conformant to whatever standards exist, in practice an important part of the job of a production OS is to work around the myriad quirks of hw/sw users will likely encounter. Standards are the input, experience is the output, and users judge on output. Related is yesterday's post about ensuring DOS app compatibility in Win95 [1] [1]: https://news.ycombinator.com/item?id=37311508 https://news.ycombinator.com/item?id=37311508
- sho_hn 3y ago

teawrecks 3y ago

We don't know that though. The fact that it presumably works everywhere except Linux makes me think there's still a bug in that `edid-decode` path. And as far as I can tell from the article, OP just assumed the display supported 60hz because it happened to show an image when they set it to that.

Moto7451 3y ago

I don’t think that’s actually correct either. The monitor is advertising Freesync/GSync variable refresh rate. The Ultragear monitors are high end gaming monitors so they come with 48-240Hz VRR on some monitors. That’s the 48-144hz extension in the EDID of this monitor. Based on debugging some issues I was having in macOS, I discovered from various Reddit and forums that Linux doesn’t handle that well depending on your driver stack/how you connect. If you’re on very modern hardware, kernels, and the OEM drivers it’s a better situation. macOS also has partially broken support for Freesync (or ProMotion as Apple brands it) at the moment on Intel machines. I have an Asus GSync monitor with 48-144hz compatibility. This works over DisplayPort on my M2 Pro MacBook. On my RX6800 equipped Intel Mac I get 100Hz over DisplayPort 1.4 and 120Hz over HDMI 2.0 due to a DSC bug affecting Intel Macs. Even without that bug, 120Hz sometimes presents the OP’s issues between startup and login so I use 100Hz. The betas for the next macOS apparently fix this. Either way, it’s a fun patch