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.
# 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) :
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
head:0x55555556bd40 wlr_mode:0x55555556a540 width:2560 height:1440 refresh:143856 preferred:false
I 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: