Because, somewhere, somehow, the operating system probably did not allocate the slices of time for monitor refresh rates to be pushed to hardware that fast…
…
That or the code didnt give you the option as its internal enums didnt include such high refresh rates.
Take your pick, either are legit things that could have been the reason and are very normal things to come across in this scenario
Shouldn’t be enums as refresh rates can be floating-point and in practice there also is a lot of weirdness out there, like 59.94Hz.
The timing really needs to be matched to the monitor, you don’t want a 60Hz monitor using the resources of a 1000Hz monitor at any point. It should also be handled by the gpu and gpu driver more than the os.
I don’t think it’s that easy and I struggle to think of a legitimate reason. To me it seems more like an arbitrary bounds-check on monitor info received via hdmi/displayport. Bad coding for sure, but also potentially a point where people are pushed to newer more problematic versions of windows as the older ones “don’t support new hardware”.
If there are potentially buggy or broken monitors that sometimes report the wrong value, then a bounds check that enforces sane values makes sense. If the range of sane values changes decades later, then you’ll have to update things, but you’ll likely need to update other things on that timescale anyway, e.g. to support newer display connectors that support the new limits.
I’d expect any current displayport port to handle very high refreshrates when the resolution is reduced correspondingly. The limit to my knowledge is in bitrate.
I’d also expect connector support to sit in the gpu driver.
A basic sanity-check might be the answer though. Still why not improve it instead of just increasing the number? You could check if the rate is an outlier or there are many profiles offered that climb up to that rate for example.
Either you’d be accessing the internet to query which monitor parameters are sensible each time a monitor connects, or you’d be periodically updating a list of sensible monitor parameters which is exactly what this update was.
The monitor sends you a list of accepted input formats. You can sanity check among the list for any outliers, without online information and without hardcoding limits.
How do you propose you sanity check numbers beyond checking whether or not they’re within a sane range, i.e. a hardcoded limit? It’s not like you can trust a monitor that’s potentially feeding you bad values to limit the number of bad values it gives you.
it would be bad UX to start using one of the garbage profiles and declare that the monitor’s now working.
it would be better UX to notice all the profiles have nonsensical values, fall back to a basic one all monitors typically support, and display an error message.
Because, somewhere, somehow, the operating system probably did not allocate the slices of time for monitor refresh rates to be pushed to hardware that fast…
…
That or the code didnt give you the option as its internal enums didnt include such high refresh rates.
Take your pick, either are legit things that could have been the reason and are very normal things to come across in this scenario
Shouldn’t be enums as refresh rates can be floating-point and in practice there also is a lot of weirdness out there, like 59.94Hz.
The timing really needs to be matched to the monitor, you don’t want a 60Hz monitor using the resources of a 1000Hz monitor at any point. It should also be handled by the gpu and gpu driver more than the os.
I don’t think it’s that easy and I struggle to think of a legitimate reason. To me it seems more like an arbitrary bounds-check on monitor info received via hdmi/displayport. Bad coding for sure, but also potentially a point where people are pushed to newer more problematic versions of windows as the older ones “don’t support new hardware”.
If there are potentially buggy or broken monitors that sometimes report the wrong value, then a bounds check that enforces sane values makes sense. If the range of sane values changes decades later, then you’ll have to update things, but you’ll likely need to update other things on that timescale anyway, e.g. to support newer display connectors that support the new limits.
I’d expect any current displayport port to handle very high refreshrates when the resolution is reduced correspondingly. The limit to my knowledge is in bitrate.
I’d also expect connector support to sit in the gpu driver.
A basic sanity-check might be the answer though. Still why not improve it instead of just increasing the number? You could check if the rate is an outlier or there are many profiles offered that climb up to that rate for example.
Either you’d be accessing the internet to query which monitor parameters are sensible each time a monitor connects, or you’d be periodically updating a list of sensible monitor parameters which is exactly what this update was.
The monitor sends you a list of accepted input formats. You can sanity check among the list for any outliers, without online information and without hardcoding limits.
How do you propose you sanity check numbers beyond checking whether or not they’re within a sane range, i.e. a hardcoded limit? It’s not like you can trust a monitor that’s potentially feeding you bad values to limit the number of bad values it gives you.
I can though.If all the profiles are garbage it’s beyond saving anyway, a single outlier can be ignored.
If all the profiles are garbage, then: