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