12 ms·

1. This is impressive debugging work by the author. No individual step is rocket science - especially when the story is the success path and not the forking pat

1. This is impressive debugging work by the author. No individual step is rocket science - especially when the story is the success path and not the forking paths of possible failures - but they kept their eyes on the prize and figured it out. 2. This reminds me why I no longer use linux on the desktop

deleted 3y ago
[deleted]
jauntywundrkind 3y ago
Huh. This reminds me of why the world so needs Linux. That they could just take off the shelf tools & plug around for a bit, learning & understanding a complex situation with crude & fast debugging, knowing only a little of the internals, and in the end improve their own situation clearly. And then they could share that knowledge with others in such a clear manner. Nothing else in computing is like this. We just cannot help ourselves & each other in most realms of computing: we must be content with what we are given, as it is. In almost all probability the linux system either doesn't have a GPU capable of running this high pixel clock or the cable/connector can't handle it. I'd love to know what the Mac & windows machines do; do they run 60Hz too or are they pushing all 144Hz here successfully? This seems very likely to be a cable issue, one I don't expect windows nor Mac deal with particularly excellently.
- nyanpasu64 3y ago
  I have experienced pixel clock errors on Linux, but can't say in this case if the monitor, cable, or GPU is unable to handle full resolution at 144hz. The CTA-861 (HDMI metadata) block contains a mode "3440x1440 99.990 Hz", or 1440p100 with a pixel clock of 543.5 MHz. I don't know if this 100hz mode functions on Windows or not. The DIsplayID block instead contains a 144hz mode with a pixel clock of 799.750 MHz. Both of these modes may be within DisplayPort bandwidth limits or not, depending on the link rate and bits per pixel (this EDID says "Bits per primary color channel: 10"), and may also be supported by the display or not. I do know that Linux X11 (amdgpu kernel driver, modesetting X11 driver) tends to drive my DVI 1080p display with too high of a pixel clock (too large blanking intervals) when connected over a HDMI-to-DVI cable from my GPU. I believe this is because there's actually a duplication of mode selection logic between the amdgpu kernel driver and X11. I've reported another (system hang) amdgpu/X11 resolution bug at https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/68 https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu... with no progress towards being resolved so far. Neither bug appears on Wayland, but mainstream Wayland desktop environments (KDE/GNOME) do not allow adding custom resolutions through xrandr without overriding EDID files and either rebooting for the kernel to see it, or touching files in /proc/ (untested).
- pajko 3y ago
  Not sure about Mac, but you can do the same on Windows. It's a bit different world and sometimes overly complicated, but works. https://learn.microsoft.com/en-us/windows-hardware/drivers/display/overriding-monitor-edids https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
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. :)
whalesalad 3y ago
Funny... I am trying to learn how to patch my own debian stable kernel with an (incomplete) kernel patch submitted for adjusting the backlight on an Apple Studio Display. The monitor - to my surprise - works really great with my Debian 12 workstation via a displayport->usb-c converter cable. But (in typical Apple fashion) there is not a single button on the display to adjust brightness and the kernel doesn't support this monitor. The patch is quite simple: https://lore.kernel.org/lkml/20230701120806.11812-1-julius@zint.sh/ https://lore.kernel.org/lkml/20230701120806.11812-1-julius@z... But I haven't been able to make the time to sit down and 1. respond to the feedback (original author hasn't yet) and 2. try and apply it to the otherwise standard Debian kernel. Aside from this issue linux on the desktop has been quite pleasant, and of course this issue is not the fault of Linux per say. Deb12/KDE/Wayland/AMDGPU
- nomel 3y ago
  > and the kernel doesn't support this monitor I find it so immensely "WTF!?" that a kernel needs to know about a monitor, to change its brightness.
  - whalesalad 3y ago
    > The Apple Studio Display does not have any physical buttons and the only > way to get or set the brightness is by sending USB control transfers to a > HID device exposed by the display.
  - BenjiWiebe 3y ago
    It's hardware, and usually userspace can't talk directly to hardware.
    - nomel 3y ago
      Sounds like an abstraction is appropriate. We could call it a "device driver". Is there a reason so many things get baked into the kernel, rather than using, say, kernel modules?
      - 3y ago
deleted 3y ago
[deleted]
Tee3993 3y ago
This debuging and hacking kind of remind me of Windows, and dealing with various versions of drivers, service packs, and so on. Normal sane Linux user would just force resolution into bootloader, and create global xorg.conf. There are like 10 far easier ways to solve this problem.
- cheeze 3y ago
  Point is - I don't want to do any of this on my personal computer after work. I just want to plug a monitor in and... It works. Don't care why, don't care if windows/Mac has some quirks table. I debug enough stuff at work.
Jka9rhnDJos 3y ago
If you’re on a Mac and using a Dell monitor (I know it does it for the Dell Ultrasharp, not sure if it’s for all Dells), check your monitor settings to see if the computer is actually sending RGB to the monitor. Chances are, even over HDMI, it’s using YPbPr. Every mac I’ve ever used (20 or more over the past 10 years), and every Dell monitor (at least 5), the mac is sending the the display signal as YPbPr instead of RGB. Just Google, “Macos Dell YPbPr” and you can find complaints going back 10+ years. I get a lot of computers to use for a brief period of time (consultant), and fixing that on Macbooks every couple months is non-trivial. Sometimes it’s impossible if it’s an older version of MacOS because older versions required overriding system files and booting into single-user mode.

deleted 3y ago

[deleted]

jauntywundrkind 3y ago

Huh. This reminds me of why the world so needs Linux. That they could just take off the shelf tools & plug around for a bit, learning & understanding a complex situation with crude & fast debugging, knowing only a little of the internals, and in the end improve their own situation clearly. And then they could share that knowledge with others in such a clear manner. Nothing else in computing is like this. We just cannot help ourselves & each other in most realms of computing: we must be content with what we are given, as it is. In almost all probability the linux system either doesn't have a GPU capable of running this high pixel clock or the cable/connector can't handle it. I'd love to know what the Mac & windows machines do; do they run 60Hz too or are they pushing all 144Hz here successfully? This seems very likely to be a cable issue, one I don't expect windows nor Mac deal with particularly excellently.

nyanpasu64 3y ago
I have experienced pixel clock errors on Linux, but can't say in this case if the monitor, cable, or GPU is unable to handle full resolution at 144hz. The CTA-861 (HDMI metadata) block contains a mode "3440x1440 99.990 Hz", or 1440p100 with a pixel clock of 543.5 MHz. I don't know if this 100hz mode functions on Windows or not. The DIsplayID block instead contains a 144hz mode with a pixel clock of 799.750 MHz. Both of these modes may be within DisplayPort bandwidth limits or not, depending on the link rate and bits per pixel (this EDID says "Bits per primary color channel: 10"), and may also be supported by the display or not. I do know that Linux X11 (amdgpu kernel driver, modesetting X11 driver) tends to drive my DVI 1080p display with too high of a pixel clock (too large blanking intervals) when connected over a HDMI-to-DVI cable from my GPU. I believe this is because there's actually a duplication of mode selection logic between the amdgpu kernel driver and X11. I've reported another (system hang) amdgpu/X11 resolution bug at https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/68 https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu... with no progress towards being resolved so far. Neither bug appears on Wayland, but mainstream Wayland desktop environments (KDE/GNOME) do not allow adding custom resolutions through xrandr without overriding EDID files and either rebooting for the kernel to see it, or touching files in /proc/ (untested).
pajko 3y ago
Not sure about Mac, but you can do the same on Windows. It's a bit different world and sometimes overly complicated, but works. https://learn.microsoft.com/en-us/windows-hardware/drivers/display/overriding-monitor-edids https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

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

whalesalad 3y ago

Funny... I am trying to learn how to patch my own debian stable kernel with an (incomplete) kernel patch submitted for adjusting the backlight on an Apple Studio Display. The monitor - to my surprise - works really great with my Debian 12 workstation via a displayport->usb-c converter cable. But (in typical Apple fashion) there is not a single button on the display to adjust brightness and the kernel doesn't support this monitor. The patch is quite simple: https://lore.kernel.org/lkml/20230701120806.11812-1-julius@zint.sh/ https://lore.kernel.org/lkml/20230701120806.11812-1-julius@z... But I haven't been able to make the time to sit down and 1. respond to the feedback (original author hasn't yet) and 2. try and apply it to the otherwise standard Debian kernel. Aside from this issue linux on the desktop has been quite pleasant, and of course this issue is not the fault of Linux per say. Deb12/KDE/Wayland/AMDGPU

nomel 3y ago
> and the kernel doesn't support this monitor I find it so immensely "WTF!?" that a kernel needs to know about a monitor, to change its brightness.
- whalesalad 3y ago
  > The Apple Studio Display does not have any physical buttons and the only > way to get or set the brightness is by sending USB control transfers to a > HID device exposed by the display.
- BenjiWiebe 3y ago
  It's hardware, and usually userspace can't talk directly to hardware.
  - nomel 3y ago
    Sounds like an abstraction is appropriate. We could call it a "device driver". Is there a reason so many things get baked into the kernel, rather than using, say, kernel modules?
    - 3y ago

deleted 3y ago

[deleted]

Tee3993 3y ago

This debuging and hacking kind of remind me of Windows, and dealing with various versions of drivers, service packs, and so on. Normal sane Linux user would just force resolution into bootloader, and create global xorg.conf. There are like 10 far easier ways to solve this problem.

cheeze 3y ago
Point is - I don't want to do any of this on my personal computer after work. I just want to plug a monitor in and... It works. Don't care why, don't care if windows/Mac has some quirks table. I debug enough stuff at work.

Jka9rhnDJos 3y ago

If you’re on a Mac and using a Dell monitor (I know it does it for the Dell Ultrasharp, not sure if it’s for all Dells), check your monitor settings to see if the computer is actually sending RGB to the monitor. Chances are, even over HDMI, it’s using YPbPr. Every mac I’ve ever used (20 or more over the past 10 years), and every Dell monitor (at least 5), the mac is sending the the display signal as YPbPr instead of RGB. Just Google, “Macos Dell YPbPr” and you can find complaints going back 10+ years. I get a lot of computers to use for a brief period of time (consultant), and fixing that on Macbooks every couple months is non-trivial. Sometimes it’s impossible if it’s an older version of MacOS because older versions required overriding system files and booting into single-user mode.