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.
DacoTaco@lemmy.world 7 hours ago
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
Redjard@reddthat.com 4 hours ago
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”.
AnyOldName3@lemmy.world 1 hour ago
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.
Redjard@reddthat.com 1 hour ago
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.