Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.
Small update here, through this Arch Wiki-Add support for 165Hz monitor
maybe similar to #6323 (comment 1452584), I managed to change/edit EDID to lower the refresh rate to be within the allowed limit of the Pixel clock rate ( I'm a regular user and I don't have the knowledge to know the what and why here) and succeeded in partially getting high refresh rate in my case 240Hz instead the 300Hz,now 60Hzis not available on kernel 5.19, and three refresh rates on 5.15 recognized, with some issues but all of them are working. I don't know if this is an acceptable solution, I'll keep this as it is for now, please tell your opinion, thanks.
Also here's `xrandr --props` output after editing the EDID
The VBT LFP power conservation block claims to not support DRRS/DMRRS on this one.
Panel 2 * Dynamic Refresh Rate Switching (DRRS): no Dynamic Media Refresh Rate Switching (DMRRS): no
Not sure there's anything sensible we can do to escape is one. IIRC it did look to me like Windows wouldn't allow any refresh rate switching stuff in this case either, but I might have also gotten lost in the byzantine maze.
Have you used Windows on this machine and checked whether it allows other refresh rates?
Have you used Windows on this machine and checked whether it allows other refresh rates?
Yes, this laptop was shipped with "Windows 10 21H1 - Home Edition" already preinstalled from GIGABYTE Aorus 17G specs on thier website, and it used to have the both "60Hz" & "300Hz" available, and working.
The VBT is too old to claim VRR support, but the Windows behaviour for that was to assume that VRR is possible, which I replicated in commit fba99b1ab7bd ("drm/i915: Parse VRR capability from VBT").
Please re-test with latest drm-tip and attach the dmesg from booting with drm.debug=0xe log_buf_len=4M if it still doesn't work.
Ah right. This is some gen9 GPU which doesn't support VRR. Quite possibly we should just always add all the reported fixed modes and only use the platform/VBT capabilities when making decisions about actually enabling VRR/DRRS downclocking/etc. Though that begs the question why the "static DRRS" crap even exists in the VBT. I suppose it's possible that was only used by windows to do some kind of battery vs. AC adapter mode static refresh rate switch for power saving purposes...
commit c7943bb324e503baeeba3df2bc5ca8a377111bfaAuthor: Ville Syrjälä <ville.syrjala@linux.intel.com>Date: Sat Aug 27 00:34:51 2022 +0300 drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets
Need to still ponder a bit more what to do about the lack of VRR support on the GPU side...
Sorry for taking so long, and yes indeed those 3 patches fixed the issue for me, here are the logs drm-tip-fix-patch.log. thanks you very much, and I think you can close it now.
Edit: never mind, it's already closed.
Need to still ponder a bit more what to do about the lack of VRR support on the GPU side...
You can close this issue whenever you feel it's not the case anymore, and if you need any logs about those fixes, I'll happily post them, thank you again.