On 25.07.2017 07:14, Mario Kleiner wrote:
> On 07/24/2017 03:45 PM, Florian Echtler wrote:
> 
> That's the same here with my patch applied. After a suspend -> resume, the
> internal panel stays black, the patch doesn't help for that. Somethig i didn't
> notice btw., apparently i never suspend->resumed it.

OK - I'm guessing if the panel/connector mess gets properly sorted out in
general, then it will probably also start working after suspend/resume...

> The internal panel always works during boot, until the radeon kms driver loads
> and modesetting gets initialized, then the panel goes dark.

Weirdly enough, this is now the behaviour I'm getting, too, no matter if I use
the patched driver or the original one. So there's definitely some bit of
persistent state somewhere that got flipped during experimentation, probably
inside that stupid SMC.

> Without my patch the internal panel stays dark, but plugging in an external
> hdmi/dvi display gets both internal+external to light up.
> 
> Another way i was able to force the internal panel to stay on without my patch
> and without an external display connected is to use the kernel cmdline option
> "video=DP-1:2560x1440D" to force the external output on, although nothing is
> connected.

None of the video options, either with "DP" or "eDP", made a difference in my
case. The one scenario where I suddenly got the internal panel to turn on was
when I plugged in a DP _source_ (my laptop). Also caused the same DP link train
error messages to appear in dmesg.

> So the same machine model behaves differently with the same patch, and worse in
> your case than without it? Maybe different hardware or firmware?
> 
> Apples website lists two models of late 2009 iMac10,1 and Radeon HD 4670, to
> which the patch should apply. One 21.5 inch model without TDM and a 27 inch
> model with TDM. Mine is the 27 inch one. I assume yours as well due to TDM?
> Attached is the output of dmidecode on mine, not sure what to look for for
> differences?

Yes, also 27 inch. I've compared the dmidecode output, only notable differences
are data from RAM modules, so it's the same machine and same FW versions.

> Also attached a dmesg snippet for comparison wrt. SMBIOS version etc.

Nearly everything identical, except my dmesg doesn't show the following lines:

-[    0.000000] efi: EFI v1.10 by Apple
-[    0.000000] efi:  ACPI=0xbfeee000  ACPI 2.0=0xbfeee014  SMBIOS=0xbfec4000

I'm booting Linux via rEFIt, so I would have assumed that it's a "regular" EFI
boot, but apparently not. What's your boot configuration?

> Lukas idea that some hardware mux gets switched into the wrong position on
> models with TDM sounds pretty appealing to me, but how to test?

I'm using TDM regularly; interestingly enough, this works completely reliably,
even if the panel was dark before. My code is at
https://github.com/floe/smc_util if you want to give it a try, but apparently
there's more to it than just the two keys (MVMR/MVHR) which I'm currently using.

Maybe you can run smc_dump_linux.sh on your machine (should be safe, only reads
keys) and see if there's some difference between keys depending on what state
the panel is in?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL