Hi,
There seems to be a problem when selecting a mode with a specific refresh rate. No matter what refresh rate I choose, the last entry of the "Available modes" list returned by swaymsg -t get_outputs where the resolution itself is the same will be chosen. If you set the mode via sway config, it works without problems.
For example:
# waymsg -t get_outputs
Output DP-3 'Unknown ZOWIE XL LCD W8G01644SL0' (focused)
Current mode: 2560x1440 @ 59.951000 Hz
Position: 0,0
Scale factor: 1.000000
Subpixel hinting: unknown
Transform: normal
Workspace: 2
Available modes:
720x400 @ 70.082001 Hz
640x480 @ 59.939999 Hz
640x480 @ 59.939999 Hz
640x480 @ 60.000000 Hz
640x480 @ 75.000000 Hz
720x480 @ 59.939999 Hz
720x480 @ 59.939999 Hz
720x480 @ 60.000000 Hz
720x480 @ 60.000000 Hz
720x576 @ 50.000000 Hz
720x576 @ 50.000000 Hz
800x600 @ 60.317001 Hz
800x600 @ 75.000000 Hz
832x624 @ 74.551003 Hz
1024x768 @ 60.004002 Hz
1024x768 @ 75.028999 Hz
1280x720 @ 50.000000 Hz
1280x720 @ 59.939999 Hz
1280x720 @ 60.000000 Hz
1280x720 @ 60.000000 Hz
1152x864 @ 75.000000 Hz
1280x800 @ 59.810001 Hz
1280x1024 @ 60.020000 Hz
1280x1024 @ 75.025002 Hz
1600x900 @ 60.000000 Hz
1680x1050 @ 59.953999 Hz
1920x1080 @ 50.000000 Hz
1920x1080 @ 59.939999 Hz
1920x1080 @ 60.000000 Hz
1920x1080 @ 60.000000 Hz
1920x1080 @ 120.040001 Hz
1920x1080 @ 143.841995 Hz
2560x1440 @ 99.897003 Hz
2560x1440 @ 119.880997 Hz
2560x1440 @ 144.003006 Hz
2560x1440 @ 143.856003 Hz
2560x1440 @ 59.951000 Hz
If I try select any entry of 1920x1080, It'll set the mode to 1920x1080 @ 143.841995 Hz. If 2560x1440, it'll choose 2560x1440 @ 59.951000 Hz etc.
I've noticed this as I was using kanshi and tried to set a specific refresh rate. The refresh rate matching problem described in https://github.com/emersion/kanshi/issues/40 can be fixed by converting the parsed value from Hz to mHz before storing it to output->mode.refresh in parser.c:195. I'd create a pull request for the small fix, however the same problem as described above happens there as well. No matter what rate you choose, the last "refresh" rate on the list is selected.
I've noticed that you pass the wlr_mode struct to the zwlr_output_configuration_head_v1_set_mode function to actually set the mode. The mode->wlr_mode pointer points to different locations for each resolution. I did however ran out of time figuring out what this struct actually represents / contains to debug further.
Any idea how to fix this?
I'd create a pull request for the small fix, however the same problem as described above happens there as well.
Please do, thanks for investigating!
Any idea how to fix this?
Hmm, not sure. Is
mode->refreshcorrect in the function that applies the config?
Hmm, not sure. Is mode->refresh correct in the function that applies the config?
Thanks for your response. So I just checked and the part of the code which sets the new mode looks like this (wlr-randr, kanshi) :
zwlr_output_configuration_head_v1_set_mode(config_head, mode->wlr_mode);mode->refresh is not passed to this function. I stepped through tho and mode->refresh has the correct value. The mode struct looks like this for
2560x1440@143.856003Hz:head:0x55555556bd40 wlr_mode:0x55555556a540 width:2560 height:1440 refresh:143856 preferred:falseI then tried to set the correct mode using the set_custom_mode function and the values above but that didn't work either.
The working version as implemented in sway probably uses the set_mode function in output.c here. Sway uses wlr_output_set_mode from wlr_output.h to set the mode. wlr-randr/kanshi uses the zwlr_output_configuration_head_v1_set_mode function passes the data to the wl_proxy_marshal function. Maybe the data is handled incorrectly on the other end? Any ideas? :confused: