-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom video modes using wlr-randr don't work correctly #2379
Comments
Have you tried configuring the custom mode in your config file? |
Yes, latest GIT Wayfire it won't even try to set the video mode if it's a custom video mode. |
Have you tried setting custom_mode_N or just mode? |
@soreau Adding custom modelines on the .ini and then setting them on the same file works. Also, setting them via I added this in
But still, something like |
If you run wayfire with |
If I do this: I see this on the console that I used to launch
Everytime I run the aforementioned wlr-randr command with those parameters, the same messages appear. |
In my case with the latest GIT Wayfire setting wlr-randr --output eDP-1 --custom-mode 1920x1080@60, works. Before After |
Does wlr-randr show 1920x1080@60 among the supported modes if you run it on a fresh boot without any parameters? |
Describe the bug
In other wlroots-based compositors (Sway, Labwc), I can do for example:
wlr-randr --output HDMI-A-1 --custom-mode 1920x1080@70
...and a new ~70Hz video mode is created and used succesfully, which can be confirmed by simply looking at 70Hz content (DOS games in my case) and looking at subsequent
wlr-randr
runs where 1920x1080@70.0000 appears as the mode in use.Even 40Hz, 54Hz, 58Hz... every custom refresh rate I want is correctly used on a custom video mode in these compositors.
However, this fails in Wayfire: apparently, wlr-randr succeeds, but then it's always using a 143.766006Hz mode.
It doesn't seem to matter if I try to create and use a 70Hz mode, a 40Hz mode... it always ends up using a 1920x1080@143.766006Hz mode, which is the second non-custom mode supported by my monitor.
That's not right: custom modes should be supported, no matter how crazy they are, because they are truly useful for legacy content.
To Reproduce
Steps to reproduce the behavior:
Try to define a custom mode using wlr-randr. For example:
wlr-randr --output HDMI-A-1 --custom-mode 1920x1080@70
Run wlr-randr again without any parameters, and observe the mode in use does not match the mode we just tried to enforce, but one of the EDID-reported modes of the monitor is used instead.
Expected behavior
The custom mode should be in use.
Wayfire version
0.8.1 and git both show this behavior. Other WLRoots-based compositors (Sway, Labwc) work as expected in this regard.
The text was updated successfully, but these errors were encountered: