undefined | Better HN

0 pointssokoloff2y ago0 comments

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.

0 comments

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

npunt2y 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

sho_hn2y ago

Linux contains lots of code to work around a myriad of EDID quirks (and loads of other HW quirks), too:

https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

There certainly isn't any big philosophical point to make here, Linux doesn't take a hard stance of expecting correct HW.

Ultimately this is a symptom of (1) bugs happen (here, at LG) and (2) Linux has a lower market share and therefore sees less testing. It's certainly fine to say "then I will use Windows to run into statistically fewer problems", so long as you're aware the same argument applies to any entrenched incumbent. As mentioned earlier, it'd have applied to MSIE in 2005 as well.

llimllib2y ago

> As mentioned earlier, it'd have applied to MSIE in 2005 as well.

What's funny is, I was around in 2005 and had already adopted Firefox well before it was called Firefox. (I was also around for the release of IE 4, and spent half a day downloading it on our 56k modem on release day! Exciting times.)

That's because the web is what I work on, and I am OK taking on buggy/beta stuff in the web domain because I learn useful things.

In the OS space, I was a linux user for a decade before I realized that I was wasting tremendous amounts of time and energy debugging stuff very like this monitor issue, and getting no transferable benefit out of it.

I switched to mac at the time, and have experienced vastly less of this sort of configuration nightmare since.

I love linux and I root for it, and occasionally I still try to switch again, before I end up having to figure out this sort of issue that just empirically doesn't exist on my mac, then I get sad and switch back.

1 more reply

wzdd2y ago

Linux* actually does have a tendency towards more hardline stances, simply because it's not answerable to market forces in quite the same way. For example, say 0.5% of monitors out there have dodgy edid values like this. For a commercial OS, that's a lot of unhappy people, many of whom have social media accounts, so "When displaying a new resolution, always start at max(60Hz, lowest available refresh rate) so if something's wrong people can at least see what's going on" might be a good rule of thumb for a commercial OS.

For Linux, however, the equivalent might be "report the bug so an exception can be made for this specific monitor". In other words, it's less important that everybody be immediately happy, as long as bugs can be reported and eventually fixed.

* Shorthand for any OSS kernel and its associated ecosystem

1 more reply

TillE2y ago

This reminds me of a recent complaint about some software which didn't work properly with a certain sync service, and the developer response was that the third-party service was buggy so it wasn't their problem.

Ok, but personally quite a lot of my job involves working around the bugs and quirks of old unmaintained Windows OSes. The customer rightly doesn't care, they just want your software to work. It is almost always possible to at least mitigate the problems of whatever buggy garbage hardware/software you have to deal with.

j / k navigate · click thread line to collapse

0 comments

nyanpasu642y ago

npunt2y ago

[1]: https://news.ycombinator.com/item?id=37311508

sho_hn2y ago

Linux contains lots of code to work around a myriad of EDID quirks (and loads of other HW quirks), too:

https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

There certainly isn't any big philosophical point to make here, Linux doesn't take a hard stance of expecting correct HW.

llimllib2y ago

> As mentioned earlier, it'd have applied to MSIE in 2005 as well.

That's because the web is what I work on, and I am OK taking on buggy/beta stuff in the web domain because I learn useful things.

I switched to mac at the time, and have experienced vastly less of this sort of configuration nightmare since.

1 more reply

wzdd2y ago

* Shorthand for any OSS kernel and its associated ecosystem

1 more reply

TillE2y ago

j / k navigate · click thread line to collapse