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
Attachment:
signature.asc
Description: OpenPGP digital signature
