iMac 10,1 with Ubuntu 16.04: black screen after suspend
Florian Echtler
floe at butterbrot.org
Tue Jul 25 07:53:57 UTC 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170725/a1c0391d/attachment.sig>
More information about the dri-devel
mailing list