bonw15: G-Sync Not Enabled? #592
Comments
|
Is this something to do with some GPIO needing pulled, or is it something to do with adding VRR support or configuring the dGPU vendor bit? The clevo/sager x370 models on default firmware with the 144hz LCD support it so really shouldn't it work for us too? |
|
I'd love some input. Schenker is nice enough to share the x370SNx schematics, so here's the nVidia relevant portion:
The full schems (scroll to bottom): https://download.schenker-tech.de/package/schenker-key-17-pro-e23-e24-ske17pe23-ske17pe24/ |
|
The other GPIOs on the CPU themselves don't document a g-sync enable pin explicitly like some of the other models but that doesn't necessarily mean that one of the "unused" or non defined ones might be setup for this and just not noted in the schematic? |
|
@crawfxrd I'm sorry to tag you at all, but I would love it if you or someone else familiar with all this might know a path I could investigate? |
|
The serw13 at least has it mentioned for the GPIOs, but even if the hardware all supports it they may be artificially turning it off at factory with a resistor? On both it and bonw15? That or there's something elsewhere...driver, vbios, dsdt that prevents it working? https://download.schenker-tech.de/temp/Manual_Parts-and-Schematics_XMG-PRO-15_PD50SNx.pdf |
|
Looking in the OEM UEFI modules, it may be that one of the nVidia DXEs does something to enable it? The nvdgpudxe does have a list of ceritifications for g-sync...so there may be some special sauce we lack? |
|
Unless the dxe/smm modules are specifically queried or used somehow, I'm thinking that it could potentially be something that needs to be in the DSDT as an alternative thought, though the relevant certification strings do exist in the stock firmware's nvdgpudxe file...but they look similar to the old SLI "license" entries that used to be used in DSDT if I'm not mistaken. |
|
I don't have a DSDT dump from the stock bios, and reached out to a guy to try and get one, but if you happen to have one handy feel free to share. I'm expecting there should be strings somewhere inside like these: |
|
In addition, if the platform cookie requires modification, it appears to be easily doable: |
|
I had a mostly-written out response to this, but apparently closed the tab and can't recover it. I'm too drunk at this point, but in effect: I don't know how G-SYNC (or equivalent) actually works at the hardware/firmware-level to properly response to this. I think its mostly controlled by ACPI at this point? But the notion of "mid" from that table is so fucked up to me that I don't know where to begin. For most features, we typically only have to enable it by GPIO or FSP selection in coreboot. In terms of security: I have expressly tried to avoid any kind of responsibility for its implementation. While I had a minor in mathematics, I am ultimately just a code monkey. I am just trying to make these implementation FOSS without Intel or NVIDIA bearing down on us. |
|
No sweat - it's one of those kinds of evenings. G-Sync is just another feature like SLI or virtual reality or whatever, and requires a certified LCD panel...which the bonw15 should have with the 144hz BOE panels, only over display ports (ours use eDP-1?). I think the Serval WS should also, probably others. The panels sometimes (always?) have an "nvidia module" too. Anyway, it is visually nice for gaming (no screen tearing) and also reduces input lag in general when in use. External monitors with the support would work too, but I think in that case the license still has to be there for the nVidia drivers to read and activate the feature (actually it's possibly the vbios reading it? no idea). I could be off base on the SSDT table being the key to it, but maybe not if it's just ACPI based to turn it on and off. Assuming that the default GPIO resistors have it turned on at boot we're just missing the license to turn it on, but I'm not sure if it's just expecting it in the SSDT/DSDT table or if there's more special sauce from the dxes. SLI licensing was done this way, there's examples of the nvidia SLI licenses embedded in SSDT tables around if you look for them, and the OSX86 people have done slic modding that makes me think GSync may just be a SLIC that gets shoved into SSDT at boot by the nVidia DXE for the dgpu. Security wise you've largely done well, it's just that for secureboot to actually secure anything it needs to be (optionally) as difficult as possible to disable it or clear/change the keys once they're set - so generally just a password. The other paranoid security stuff becomes increasingly higher degress of "pain in the ass" factor from my research...measured boot isn't bad, but then heads...so complicated for little gain unless you're like...a world traveling reporter that repressive regimes hate or something. |
|
All that said I still think it's the NVdGPUDxe that does whatever it is to turn on GSync, but so far ghidra isn't really showing me what I need to see just yet. I can share files and info if anyone wants to help. |
|
@crawfxrd I got further...so for one I'm not sure which model for certain corresponds to my machine but the one below is an educated guess, based on values in hex...I may be implementing it wrong for all I know but it does build and run... Anyway, in theory this should work if it is correct but it's not - so either the license is incorrect for my model (does anything in the list look familiar or could Sager give you the id for the bonw15?) or, more likely, I think g-sync may not work unless we get control of the mux (Dasharo/dasharo-issues#1024 related) so that it is direct output without the igpu in the way... Sometimes other FUNC tests are passed so this would probably be the ACPI method that talks directly to the vbios over WMI... |
|
Regarding those "cookies" - here's the best reading on it. This guy got legal threats from nVidia though... |
|
...and I can confirm that WMI device node does show up properly under Linux so I'm guessing it's the cookie or the mux |
|
Here's a more organized and concise version for your GitHub reply: @crawfxrd I got it working as a proof of concept! I included the WMI scope in my DSDT (though I'm not sure if it's required or functional yet). What did work was adding the MUX_CTRL_BIOS GPIO to the bonw15 in the EC and forcing it high at boot. This approach meant flying blind until my bootloader started, but under Linux, it allowed operation in unverified mode. However, despite having the right hardware and G-Sync enabled, I couldn't confirm much improvement in stuttering using the available Linux testing applications though the indicator does say GSYNC is on. Windows, being windows, isn't happy and probably needs additional ACPI table entries to be happy, as will brightness controls as doing it this way kills your eyes with 100% brightness. Further ACPI and GPIO work will likely be needed to refine this. My next step is to try getting the Advanced Optimus toggle working with the MUX_CTRL_BIOS GPIO. I suspect the original intent might have been for the FN+LCD key to toggle the GPU MUX. Happy to share my diffs or push if you really want to look at it or if you'd rather let me keep grinding on it a while before you comment. |
|
...so that DSDT addition may or may not be working but if it is, the nVidia cookie I'm using to attest GSync certification is incorrect for this model. |
|
I'm not really following this, but I'm not surprised if it's mostly controlled by ACPI. I'm not sure if |
|
It does appear to be mostly ACPI including the LCD brightness in nvidia mux mode; I believe that what I lack there and in the "certification cookie" department, and some other ACPI bits are what's needed to make windows happy as well... MUX_CTRL_BIOS is exposed to the EC, some of the models have it defined, some don't, but none of them bring it up or have a facility for flipping it yet...and then we'd also just need to add code somewhere in the process so that coreboot outputs to screen regardless of mux - it's a black screen if you bring that GPIO up until the bootloader starts right now. |
G-Sync does not appear to be setup anywhere in the gpio.c file as it is with the serw15 and others, but the laptop itself should have the capability - the BOE 144hz LCD supports it, the 40XX gpus support it...it's just something somewhere in firmware does not support it.
I've tried both in hybrid and in dedicated graphics mode without luck in both Linux and Windows...it makes no sense.
I'm at a loss, I can't figure it out...
Schenker is legally sharing the schematics for this particular model, under a different name, and there is information in that document relevant (see bottom of page) - I can't find any GPIO directly labeled for g-sync detection but there's an nvidia page that discusses somethign to do with vendor bits for that?
https://download.schenker-tech.de/package/schenker-key-17-pro-e23-e24-ske17pe23-ske17pe24/
Steps to reproduce
Try to use G-sync in Linux and Windows, in hybrid and dgpu only mode. It will fail.
Expected behavior
Actual behavior
Additional info
The text was updated successfully, but these errors were encountered: