Technology
Which posts fit here?
Any news that are at least tangentially connected to the technology, social media platforms, informational technologies or tech policy.
Post guidelines
[Opinion] prefix
Opinion (op-ed) articles must use [Opinion] prefix before the title.
Rules
1. English only
Title and associated content has to be in English.
2. Use original link
Post URL should be the original link to the article (even if paywalled) and archived copies left in the body. It allows avoiding duplicate posts when cross-posting.
3. Respectful communication
All communication has to be respectful of differing opinions, viewpoints, and experiences.
4. Inclusivity
Everyone is welcome here regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
5. Ad hominem attacks
Any kind of personal attacks are expressly forbidden. If you can't argue your position without attacking a person's character, you already lost the argument.
6. Off-topic tangents
Stay on topic. Keep it relevant.
7. Instance rules may apply
If something is not covered by community rules, but are against lemmy.zip instance rules, they will be enforced.
Companion communities
!globalnews@lemmy.zip
!interestingshare@lemmy.zip
Icon attribution | Banner attribution
If someone is interested in moderating this community, message @brikox@lemmy.zip.
view the rest of the comments
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: