Summary
Variable Refresh Rate (VRR/Adaptive Sync/FreeSync) is not functional on the Framework Laptop 13 with the 2.8K display (BOE NE135A1M-NY1) under Linux. The kernel driver does not recognize VRR capability of the panel, despite the panel being marketed as VRR-capable (60-120Hz range).
System Information
- Laptop: Framework Laptop 13 (AMD Ryzen 7040 Series)
- Display: BOE NE135A1M-NY1 (2880x1920, 120Hz, 2.8K)
- OS: Fedora Kinoite 43
- Kernel: 6.17.8-300.fc43.x86_64
- Desktop: KDE Plasma 6.x (Wayland)
- GPU Driver: amdgpu
- Bios Version: 3.0.5 (updated with Fedora updates)
Problem Description
-
vrr_capable sysfs file is missing:
$ find /sys/class/drm -name "vrr_capable"
(empty output)
-
No VRR information in DRM state:
$ sudo cat /sys/kernel/debug/dri/1/state | grep -i "vrr"
(empty output)
-
No VRR/FreeSync/Adaptive keywords in kernel logs:
$ sudo dmesg | grep -i "vrr\|freesync\|adaptive"
(empty output)
-
EDID does not expose VRR range:
$ sudo cat /sys/kernel/debug/dri/*/eDP-1/vrr_range
(file does not exist)
Expected Behavior
vrr_capable should be 1 in sysfs- VRR range (60-120Hz) should be visible in DRM debug
- KDE/GNOME Adaptive Sync settings should actually control panel refresh rate dynamically
Actual Behavior
- KDE “Adaptive Sync” setting has no effect on actual panel refresh rate
- Panel stays at fixed refresh rate (60Hz or 120Hz depending on setting)
- No dynamic refresh rate adjustment on idle/activity
- VRR works in Windows on the same hardware (according to marketing materials)
EDID Information
Panel identification from EDID:
- Manufacturer: BOE
- Model: NE135A1M-NY1
- EDID shows modes for 60Hz and 120Hz but no VRR/Adaptive Sync capability flags
Raw EDID (base64):
AP///////wAJ5bQMAAAAADQhAQSlHRN4Bwqlp1VLnyUMUFQAAAABAQEBAQEBAQEBAQEBAQEBEZFA
oLCAdHAwIDYAHb4QAAAaAAAA/QAeePT0SgEKICAgICAgAAAA/gBCT0UgTkoKICAgICAgAAAA/ABO
RTEzNUExTS1OWTEKAjFwIHkCACAAE5oOALQMAAAAADQXB05FMTNOWTEhAB0iC2wHQAuAB4hu+lS4
dJ9WggwCNVTQX9BfSDUSeCIAFExVC4g/C58ALwAfAH8HcwACAAUAJQAJTFULTFULHniAgQATchoA
AAMBHngAAGpCakJ4AAAAAAAAAAAAAAAAAABPkHAgeQAAJgAJAgAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADaQ
Comparison with Framework 16
Framework 16 had a similar issue where VRR was not recognized due to EDID mismatch:
- DisplayID 2.0 block advertised VRR, but EDID 1.4 block did not
- This was fixed with a kernel patch in Linux 6.8.3+ / 6.6.24+
Reference: [ANNOUNCEMENT] Adaptive Sync / Freesync / VRR not working
The Framework 13 2.8K panel (NE135A1M-NY1) may have the same or similar issue requiring a kernel patch.
Impact
- Higher power consumption on laptops (panel always at fixed refresh rate)
- No power savings from VRR on idle desktop
- Inconsistent experience between Linux and Windows
Requested Action
- Confirm whether BOE NE135A1M-NY1 panel supports VRR at hardware level
- If yes, investigate why Linux kernel/amdgpu does not recognize VRR capability
- Provide EDID fix or kernel patch similar to Framework 16 solution
Additional Notes
Workaround found: While VRR doesn’t work, KDE Plasma with “Prefer efficiency” color accuracy setting allows the compositor to skip rendering on idle (damage-based rendering). This reduces CPU/GPU usage but does not reduce panel refresh rate.
Reporter: Andrew
Date: 2025-11-29
What is the output of kscreen-doctor -o?
On my machine, it’s
hurricane@TheCloutBook /sys/class/drm/card1-eDP-1 $ kscreen-doctor -o
Output: 1 eDP-1 1cadfddc-2045-4203-bbdf-167136be7bf6
enabled
connected
priority 1
Panel
replication source:0
Modes: 1:2880x1920@120.00*! 2:2880x1920@60.00 3:1920x1200@120.00 4:1920x1080@120.00 5:1600x1200@120.00 6:1680x1050@120.00 7:1280x1024@120.00 8:1440x900@120.00 9:1280x800@120.00 10:1280x720@120.00 11:1024x768@120.00 12:800x600@120.00 13:640x480@120.00 14:1600x1200@59.87 15:1280x1024@59.90 16:1024x768@59.92 17:2560x1600@59.99 18:2560x1600@119.93 19:1920x1200@59.88 20:1280x800@59.81 21:2880x1620@59.96 22:2880x1620@119.95 23:2560x1440@59.96 24:2560x1440@119.95 25:1920x1080@59.96 26:1600x900@59.95 27:1600x900@119.95 28:1368x768@59.88 29:1368x768@119.83 30:1280x720@59.85
Geometry: 0,0 1440x960
Scale: 2
Rotation: 1
Overscan: 0
Vrr: Always
RgbRange: unknown
HDR: incapable
Wide Color Gamut: incapable
ICC profile: /home/hurricane/Documents/ICM/BOE0CB4.icm
Color profile source: sRGB
Color power preference: prefer accuracy
Brightness control: supported, set to 25% and dimming to 100%
Color resolution: automatic (16), range: [8; 16] bits per color
Allow EDR: always
Sharpness control: unsupported
As you can see, VRR is enabled and shows up.
Where did you come up with all these sysfs files? They don’t exist. There is a debugfs file for range and a drm property for capable, but no such files for sysfs.
To me this looks like you made them up by copying and pasting LLM output.
Of course, it shows that it’s enabled. But it doesn’t work at all. If you enable FPS output in the system, I use Fedora Kinoite, you’ll see a very simple picture. If you setip 120 Hz in settings, it will constantly render at 120 FPS, no matter what you do on the screen. But if you set it to 60 Hz, it will always render at 60 Hz. In rare cases, if you switch to full-screen mode using F11, it might go to 120 Hz for a few seconds and then permanently revert to 60 Hz. This isn’t working VRR by the right way, it’s just a simulation.
I believe what you are seeing is a KDE bug. Can you please report it to their bug tracker?
If you enable FPS output in the system, I use Fedora Kinoite, you’ll see a very simple picture
What does this mean? Is this a dispaly FPS overlay or a software FPS overlay? For VRR to work, in general, you need to have your game be rendering within a certain VRR range.
Looking at EDID by doing di-edid-decode /sys/class/drm/card1-eDP-1/edid, I can see the following:
Display Range Limits:
Monitor ranges (Range Limits Only): 30-120 Hz V, 244-244 kHz H, max dotclock 740 MHz
This means that for VRR to work, you need to be rendering anywhere between 30-120 FPS. Also, VRR clearly is available in the EDID. I don’t know why you’re checking in the sys filesystem, but there are EDID decoders. I have the same panel as you, and its EDID does state it is VRR capable.
Maybe I’m wrong, I admit it. But I’m using these commands:
$ qdbus-qt6 org.kde.KWin /Effects loadEffect showfps
$ qdbus-qt6 org.kde.KWin /Effects unloadEffect showfps
I’m looking at it, and it seems reliable to me, the frame rate at which kwin renders frames.
I noticed that if I set the monitor to 120 in the KDE settings, the fps never drop below 120, even when nothing is happening on the screen. Moreover, I see that frames are generated constantly, even when idle. This is confirmed by the power consumption dynamics use command “upower -i /org/freedesktop/UPower/devices/battery_BAT1”. And GPU load in System Settings.
Next, I set the frame rate to 60 and see changes in power consumption and GPU temperature. I also look at the FPS graphs. And here’s what I see: when idle, frames are not rendered, or rendered minimally. When switching to full-screen mode, there’s a brief (about 1 second) jump to 120 fps and then a fallback to 60 (it doesn’t change again, it stays at 60).
From this, I draw a very simple conclusion: the system is working correctly with a refresh rate locks 60. It’s completely different from what you’d expect with a refresh rate of 120.
Perhaps I used the wrong commands. Perhaps there are special settings somewhere. I’d be grateful if you could help. However, from the perspective of how I expect the panel to work in VRR mode, the situation doesn’t seem correct.
This is how VRR works. KWin will render at your display’s set refresh rate. The display going down to 1 Hz when nothing is happening is something that is done on phones and mobile operating systems, not desktop operating systems. You’re thinking of LTPO-like displays.
Basically, I don’t think anything wrong is happening. Kwin, due to Wyaland’s nature, will always been synced and be rendering at the displays framerate. You’ll get variable rates whenever playing fullscreen games. I know this behavior is right based on me using KDE Wayland on my monitor that has a built in refresh rate OSD, not relying on the compositor.