Signal padding, there happen to be empty/blank pixels sent which make things easier for display controllers when detecting timings, historically those blank pixels were there to give time for CRT electron beams to move to where the next line or frame began.

For BOE panels at 90hz, they receive frames which happen to be 858x1320 pixels in size, with an active area of 800x1280, while SDC panels use frames which are 1128x1312 in size, also with an 800x1280 active area.

So…

for BOE: 858x1320x90 = 101930400; ie a clock of ~101.93MHz; though in reality the panel runs at 102mhz so has a refresh rate of ~90.0615Hz.

and for SDC: 1128x1312x90 = 133194240; so a clock of 133.194mhz; but they run at 133.200MHz instead which gives a refresh rate of ~90.004Hz

Reducing how large of a padding area gets sent may be possible, but without having an SDC panel deck myself I’m not able to test to which degree, if any, that would be possible.

Just to confirm, neither HDR@89Hz nor HDR@91Hz work, but HDR@90Hz and HDR@65Hz do?

Also, you can disable Unified Frame Limit Management to revert to the older split slider config to be able to set sub-61hz locks without removing changes entirely.

I will likely make an update which changes things such that even values between 91 and 121 get skipped over, in order to avoid trampling over 46-60hz options from unified limiter which already work.

Colour correction should be semi-possible but darker colours will have lower fidelity / heavy banding

Have you tested with HDR yet? I do not know whether running over 90hz will work when HDR content is displayed or not and I do not know if any games I have support HDR.

I have noticed quite a large difference between 90 and 120hz on my deck, happens to be particularly noticeable within 2D rhythm games, most of which already get 8+ hours of battery life regardless.

Did you make sure to be where you downloaded things to? You can navigate there from Dolphin, right click, and do open terminal here.

I already linked my changes in another comment here :p

There’s not a whole lot of code changes, primarily adding logic for handling setting clock rates in addition to vfp rates, things were mostly manual display tuning.

But it’s below the treshold for human perception

Not exactly true, depending on which sense and , humans can perceive differences down to amounts quite small, even tiny values like 5-10 microseconds for hearing frequencies are noticeable.

For input-visual response time, differences down 0.5-1 milliseconds can be perceived by those sensitive to it and/or trained for it, 2 milliseconds happens to be well above that, though on average 4-6 milliseconds would be an expected threshold without knowing what to expect.

When using gyro-to-mouse input, difference between 60 and 70hz is perceivable, though a small change and not immediately noticeable, often it would be to enough to throw off my inputs for timing-sensitive things should I forget about increasing refresh rate.

Motion inputs often have significantly higher sensitivity to response time variation, adding say, 2msec extra latency into a VR headset and you would be far likelier to end up feeling nauseous after/during use.

I do not have a deck with a Samsung panel currently so unfortunately I can not perform manual timing tuning like I was able to do with a BOE panel deck (which was quite annoying to get given they only shipped LE ones to US&Canada, luckily I had access to an old secondary steam account and could order from that, got kinda worried with shipping but despite the box being a bit wet given it was left out in the rain briefly, everything turned out okay)

If I do end up receiving enough donations to buy a second OLED deck than I intend on ordering one so that I can hand-tune Samsung panel timings. Without one though, it looks like SDC decks will be limited to ~98hz for now.

I will likely update my code to handle SDC and BOE decks separately to avoid enabling modes SDC decks can not function at.

On OLED panels, gamma curves relate directly to how long pixels are driven, so when you increase refresh rate you end up with reduced resolution in darker colours.

I left removal instructions in another comment here, but if you do not use the higher values than your panel will not be driven at those higher values. Gamma curves being off should not in of itself cause issues for the display.

SDC at 90Hz uses ~133MHz of bandwidth while BOE at 90Hz uses ~102MHz of bandwidth; Valve’s MIPI converter seems to begin struggling at roughly ~147-148MHz which is where those numbers come from.

I do not know if SDC can be made to use narrower timings to reduce bandwidth usage or not, and given I currently only have a BOE deck I can not currently test for that.

I did change how 90Hz mode works slightly [I manually tuned all 80 modes from 40hz to 120Hz] so using this will push BOE OLED panel controllers slightly more at 90hz than stock would, but it should still be well within expected panel tolerances. I would not expect any harm to come from that.

Modes that will drive BOE panels at rates higher than stock: 46-48, 50, 53-54, 58, 60-63, 65-64, 68-69, 75-79, 82-83, 86, 89-120

All other modes will drive BOE panels at rates lower than stock.

For SDC, all modes from 45 through 90 will drive panel at stock rate, for 40-44 they’ll be lower than stock, 91-120 will be higher than stock.

For LCD decks, only 61-70 would push panel harder, but there’s very little risk comparatively there, especially given many, including myself, have run LCD decks at 70hz for extended periods without issue.

There was a comment replying here saying something like “I wouldn’t touch this until steam officially enables it” and I had typed out a response only to get a message saying that comment was deleted when I went to actually post my response, so here’s that response anyway.

I mean, aside from that being very unlikely, it would be quite silly to think Valve would enable an overclock by default :p

They might fill in those missing refresh rate options though, somewhat hoping someone from Valve contacts me to help with that so I could contribute a pgp-signed commit into gamescope’s repository.

Regardless, anyone is free to inspect what changes I have made and/or compile things for themselves, https://git.spec.cat/Nyaaori/gamescope/commit/d39000aa9f53d1bd3c6fa993fdaeb6cc99ad4ae0

Hard part was manually tuning and testing timings for BOE panels over several hours, code part only took like 5-10 minutes.

While good to point out, morning in europe also tends to be fairly active and I feel that should stuff be genuinely cared about, there would not be that high of likelihood of getting buried even should things be posted during slower times.

From everything I have heard, all LE decks have BOE panels. That being said, if you run xrandr --verbose | grep MHz from desktop mode and the first [or only] value you see is close or equal to 102.00MHz you have a BOE panel but if you see a value close or equal to 133.20MHz you have an SDC panel

In the case of embedded displays rather than external, dropping happens to be quite rare due to having increased directness of control of a panel. I have already confirmed that no dropping occurs on either my BOE OLED or LCD decks, but no clue about SDC OLED decks.

In external displays, there can be additional processing happening between receiving a signal and displaying an image, that would be where frame dropping most commonly occurs.

If it works, I expect the functional ranges, at least on my deck’s BOE panel, to be ~25-90hz, ~30-120hz, or ~35-130hz.

For now it looks like I will likely need to patch GPU drivers to enable VRR, because it still has not become available after using the older technique which typically works to enable it. That will unfortunately take a bit of time to do, maybe someone else can do so before I get time to do it.

VRR does not do anything special that has not been possible since the 1980s if not earlier, if a display signal can be fed over a line than that signal can be made VRR too. What would be difficult is coaxing a GPU/Driver to generate that signal to feed to said display.

130hz comes out to a little under 150MHz pixel clock, interface bandwidth appears to max out about there because if I push things any higher it appears distorted or I get nothing at all.