refresh rate selection not considered

[jampe]

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 emersion/kanshi#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?

[emersion]

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->refresh correct in the function that applies the config?

[jampe]

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 [email protected]:

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? 😕