Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 16:15 UTC (Tue) by flussence (guest, #85566)
In reply to: Gräßlin: Multi-screen woes in Plasma 5.7 by niner
Parent article: Gräßlin: Multi-screen woes in Plasma 5.7

+1, Intel's Linux support is *abysmal*. My laptop has recently sprouted a "fun" little bug where if I resize an OpenGL or video window too small it begins to wrap around on itself. For the past few years it's spammed dmesg with EDID errors on startup too (I've done enough reading to learn this can't be turned off in any way), and my distro's had to disable DRI3 for everyone because there's a crash bug regarding it that's been getting the silent treatment for 3 years. There's a long list of other crap, but at least the hangcheck timer doesn't see as much use these days!

(The radeon drivers haven't been perfect either, mind. I see uninitialized VRAM contents an awful lot more than I should...)

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 19:04 UTC (Tue) by tuna (guest, #44480) [Link] (1 responses)

Where is the bug that has been getting "the silent treatment for 3 years"?

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 13, 2016 15:04 UTC (Wed) by flussence (guest, #85566) [Link]

https://bugs.freedesktop.org/show_bug.cgi?id=71759

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 19:18 UTC (Tue) by tao (subscriber, #17563) [Link] (3 responses)

You've never considered that the EDID-errors might be due to the EDID information of your display actually being invalid? Also, AFAIK the EDID-parsing isn't done by the i915-driver; it's done one layer higher up (I think you'll find that the message is along the lines of
[drm:<function> [drm]], not [drm:<function> [i915]], the latter being how it would look like if it was a bug in the i915 driver.

Of course there's a possibility that the i915-driver reads the EDID information incorrectly, but don't rule out the display having invalid data. It's rather common.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 13, 2016 15:28 UTC (Wed) by flussence (guest, #85566) [Link] (2 responses)

It probably is invalid, but what good does it do to fill my screen every boot with errors telling me a checksum isn't right? I can't just swap out the internal LCD panel with a different one to fix it. I can't reasonably mute this debug spam either, because someone in their infinite wisdom decided it should be printed at KERN_ERR severity.

</rant>

There's always a finger pointing somewhere else... maybe Intel should follow Microsoft's lead here: “stop shipping broken crap that manifests itself as a defect in our stuff, or else you can't use our name on the box to sell it”.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 13, 2016 23:46 UTC (Wed) by tao (subscriber, #17563) [Link] (1 responses)

There's usually no Intel chipsets in displays, so I cannot really see how Intel could possibly influence the display makers in the first place. If we had that kind of influence we'd be very happy though -- there are more severe issues that we have to work around that we'd love to see fixed. :)

I realise that it might annoy you (I'm experiencing EDID warnings too, when connecting my computer to the TV), but unless you can figure out a way to tell harmless cases of invalid EDID from invalid EDID that actually causes problems, I think it'll be a hard sell to convince Dave Airlie (the maintainer of the DRM subsystem) to change the severity of that message. Give it a try if you like though.

If you know that the EDID warning is harmless, you could try passing drm.edid_fixup=0 -- I believe that should silence the warning for you. It's not a fix though, it's a workaround, since you'll disable the EDID sanity checks[1].

[1] Not speaking for Intel, bla bla bla. You know the drill.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 14, 2016 19:40 UTC (Thu) by flussence (guest, #85566) [Link]

>There's usually no Intel chipsets in displays, so I cannot really see how Intel could possibly influence the display makers in the first place.

I'm probably a rare case in that I *can* accept it's someone else's anonymous component at fault. In fact almost all the times I've had hardware problems on Intel-based PCs I've owned, it's turned out to be a buggy BIOS or firmware. Serves me right for not buying coreboot-supported computers I guess.

In this case, a laptop, it's a single black box and I've no idea what the LVDS panel inside it is (other than nasty). The average end user's more likely to see problems and blame whatever they can immediately associate them with, be it the laptop maker, those pervasive “Intel inside” stickers, or the OS they're running.

Dragging this back on topic, I can sort of see why the KDE developers get easily frustrated. It's the same story of them relying on another part of the system to do its job right, but it keeps screwing up because the negative feedback processes that do exist fall far short of the root cause. Sadly this seems like such a common problem nobody's found a working solution yet.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 21:26 UTC (Tue) by barryascott (subscriber, #80640) [Link] (1 responses)

In my experience, at a digial siganage company, EDID errors are always down to monitor or cable issues.
About a year ago there was an issue, not unique to Intel, that EDID reads could be done 1 byte at a time or in bigger
blocks, The kernal code that read EDID was not covering alll the cases for the reads and my colleague contributed
code to fix this problem.

We used Intel drivers in our produces and had great support from the Intel graphics team.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 22:25 UTC (Tue) by farnz (subscriber, #17727) [Link]

Worth noting that that issue was with DisplayPort only (where you can read between 1 and 16 bytes over DP AUX, and rely on the far end converting that into appropriate I2C transactions, as opposed to HDMI, DVI or VGA where you have direct I2C access and Linux has always done the largest transfers that work), and was only an issue because buggy displays "work with Windows"; Windows always uses 16 byte reads from EDID in preference to smaller values.