Contribute
Register

SSDT GPU (Graphics Card) Injection

Status
Not open for further replies.
My GTX 980 and Titan X show the boot screen correctly on any port on either card. If there are multiple monitors, I think it defaults to the lowest port number but I don't remember for sure.

Is there a way to edit the SSDT so that the ports are properly mapped so the boot screen just works?
 
Is there a way to edit the SSDT so that the ports are properly mapped so the boot screen just works?
I don't think so but I'm not positive. I guess it either works with your card or it doesn't. I started with Fermi cards. If I remember correctly, I used to give aapl,boot-display to port A@0 and (I think) it would show the boot display on the monitor regardless of the port it's connected to. I don't remember for sure. For the maxwell HDMI audio edit to work, you have to define the ports but you don't want to give many more properties. Laying out the ports in a SSDT solved some hotswap issues I was having when I was just using the web driver but that could have been a bug with that version of the driver. With Fermi cards, you just feed them any properties you want (plus the ones they need). With GK110b and all Maxwell cards, you have to be careful what properties you try to inject because some will interfere with properties that are already provided by the web driver. You can't change a property but you can add a property if it's not already provided by the driver. I suppose one could single out the Nvidia Web Driver's injector kext and remove it. Then do a full custom properties injection similar to the old ones for Fermi and before. However, you'd probably still be in the same boat with boot screen behavior and have to assign aapl,boot-display to the appropriate port.
 
Yes, its the original Titan. Maybe you could present this as an alternate fix for those who need it. I don't see the "lock", as I do not replug my monitor all the time, and you still can change the SSDT later?
I'm happy to add it as a solution in this guide but I still have some questions as to the best method. Macs use EFI sting to inject aapl,boot-display. Example:
Code:
        <key>@2,AAPL,boot-display</key>
        <data>
        AQAAAA==
        </data>
"AQAAAA==" is the base64 equivalent of 01 00 00 00. 1 is usually = true, active, or on and 0 is usually = false, inactive, or off. By that logic, your edit is actually telling OS X that @2 is NOT the boot display and it should be:
Code:
"@2,AAPL,boot-display", 
Buffer (0x04)
{
    0x01, 0x00, 0x00, 0x00
},
or
Code:
"@2,AAPL,boot-display", 
Buffer (One)
{
    0x01
},
but it's possible that just the presence of aapl,boot-display regardless of it's data/string will flag OS X to use @2 as the boot display. If it works as is, it works but I'd like to know what else works too and maybe if it can work better.


I'm away from my hack on a long trip. Are you willing to do some testing?

If so, Please change:
Code:
"@2,AAPL,boot-display", 
Buffer (One)
{
    0x00
},
to
Code:
"@2,AAPL,boot-display", 
Buffer (Zero) {},
and see if boot display still works correctly.

EDIT: I wonder if simply this:
Code:
"@2,AAPL,boot-display",
alone will work?

Please also try both on @0 instead of @2 see if it still shows the boot screen.
 
Hi shilohh,

Just did the tests. Here are the results:

Code:
"@2,AAPL,boot-display", 
Buffer (0x04)
{
    0x01, 0x00, 0x00, 0x00
},

Works as well

Code:
"@2,AAPL,boot-display", 
Buffer (One)
{
    0x01
},

Also works

but it's possible that just the presence of aapl,boot-display regardless of it's data/string will flag OS X to use @2 as the boot display. If it works as is, it works but I'd like to know what else works too and maybe if it can work better.

This seems in fact to be the case!

Because:

Code:
"@2,AAPL,boot-display", 
Buffer (Zero) {},

This works as well!

EDIT: I wonder if simply this:
Code:
"@2,AAPL,boot-display",
alone will work?

Nope, glitches like with no patch applied.

Please also try both on @0 instead of @2 see if it still shows the boot screen.

Boot screen can still be seen, but the glitch as well.

Hope this helps!
 
...
EDIT: I wonder if simply this:
Code:
"@2,AAPL,boot-display",
alone will work?

No way... that is invalid. _DSM used for property injection is a set of key/value *pairs*.
 
No way... that is invalid. _DSM used for property injection is a set of key/value *pairs*.
Makes sense. Thanks! I always get valuable knowledge from you.
 
Boot screen can still be seen, but the glitch as well.

Hope this helps!
So if you do:
Code:
"[COLOR=#ff0000]@0[/COLOR],AAPL,boot-display", 
Buffer (Zero) {},
It works but has glitches? Can you elaborate more? Thanks
 
So if you do:
Code:
"[COLOR=#ff0000]@0[/COLOR],AAPL,boot-display", 
Buffer (Zero) {},
It works but has glitches? Can you elaborate more? Thanks

In this case the same happens like with no patch.

I.e. you see the boot screen, but with the start of the 2nd boot stage you have the glitchy progress bar in the lower left corner, no Apple Logo. At least you aren't "locked out" with a black screen, so you still can boot. Wonder what happens if you set boot-display on all ports.
 
Wonder what happens if you set boot-display on all ports.

Just tried, does not work. In this case, you still see the Apple Logo and the progress bar from stage one, and the glitchy progress bar in addition.

So you have to set this only with the connector your (main) monitor is actually attached to.
 
Is there a way to edit the SSDT so that the ports are properly mapped so the boot screen just works?

Seems you have to look (in ioReg for example) to which port your monitor is actually attached to. But shouldn't be too hard to figure that out (see screenshot in my post above)
 
Status
Not open for further replies.
Back
Top