Incorrectly warning that a mode is not available
thefotios opened this issue · 11 comments
For some reason, way-displays
is saying that a mode is not available (even though it should be) and falling back to a preferred mode.
This is currently happening with my DP-2 display (over USB-C). I tried specifying it with MODE: MAX
as well as the exact resolution with and without the HZ
(and all the different refresh rates)
This is the error
This clearly shows those modes should exist
I have the same issue with my laptop display, I have a 4k resolution but I cannot set a 1080p
It looks like DP-2 3440x1440@100Hz (99,982mHz) is immediately "skipped".
I [10:59:07] DP-2: No preferred mode, falling back to maximum available
I [10:59:07]
I [10:59:07] DP-2 Changing:
I [10:59:07] from:
I [10:59:07] scale: 0.750 (1.000)
I [10:59:07] position: 1182,0
I [10:59:07] (no mode)
I [10:59:07] VRR: off
I [10:59:07] to:
I [10:59:07] mode: 3440x1440@100Hz (99,982mHz)
I [10:59:07]
I [10:59:07] DP-2 Changing:
I [10:59:07] from:
I [10:59:07] scale: 0.750 (1.000)
I [10:59:07] position: 1182,0
I [10:59:07] (no mode)
I [10:59:07] VRR: off
I [10:59:07] to:
I [10:59:07] mode: 2560x1440@60Hz (59,951mHz)
I [10:59:07]
I [10:59:07] Changes successful
There may be a way to resolve this "safely", at the cost of speed.
Whilst I'm looking into that change, I'd be most grateful for some tests from you:
- plug in DP-2 after way-displays has started
- start with only DP-2 plugged in
- plug the Samsung display in via HDMI - that's probably not going to work due to bandwidth limitations
- start with
DP-2
MODE: MAX
- as above with the four 3440 x 1440 exactly specified
@github-amine-kherbouche I'd be grateful if you attached a log and your configuration.
@alex-courtis I tried a whole bunch of different permutations (logs attached). Setting the mode to MAX
vs explicit didn't seem to make any difference.
I did notice something interesting. My machine (a Thinkpad X1 Carbon) has 2xUSB-C/TB-3 connectors (doc). They don't appear to be differentiated in any docs I can find. However, when I plug into DP-1 (the left of the 2 ports) and then plug in the HDMI, it switches DP-1 to DP-2 (you can see in some of the logs DP-1 departed....DP-2 arrived
). You might be on to something with the limited bandwidth; I just have no idea how to figure it out.
- Attaching the USB-C monitor first
- Attaching HDMI first
This failure on the dell on HDMI-A-1 is odd. It's been successfully used or defaulted earlier. There are also no error messages before its mode-storm in dp1_first.log. Most other cases are reported correctly.
I [15:44:51] mode: 1920x1200@60Hz (59,950mHz) (preferred)
I [15:44:53]
I [15:44:53] HDMI-A-1: No preferred mode, falling back to maximum available
It's fortunate you're using the thinkpad. I have an X1 yoga that has the same connector configuration. I also have a Samsung C34J79x at work, which I connect to by thunderbolt.
Are you directly connecting to the monitor via displayport, thunderbolt or via a dock?
I think you're onto something with the switching of the DP-*
The monitors appear capable of their maximum res/refresh and can be cooperative, the issue is when multiple are involved. Is that correct?
I think this is a sequencing error, with modes not being recognised as successfully set. There are options.
Which compositor do you use? I'm usually testing on river.
Replicated a situation:
- nothing connected
- connect thunderbolt dock with HDMI monitor, appears as DP-5
- connect HDMI monitor, appears as HDMI-A-1
- DP-5 departs, reappearing as DP-6
- laptop display freeze and fail: "output commit failed for eDP-1"
river.1.alex.log
way-displays.1.alex.log
Unfortunately that occurs when way-displays is not running:
Disabling DRM modifiers resolves this behaviour, with and without way-displays: https://github.com/alex-courtis/way-displays#unusable-displays-following-mode
@thefotios please experiment with this.
The cancelled changes, retries and missing error messages are indicative that there are "transaction" synchronisation issues. More direct detection of failures and perhaps a reset of failed states following output arrive/depart may be useful.
Following an EPROTO
we can get some information on the error:
const struct wl_interface *interface = NULL; // zwlr_output_configuration_head_v1
uint32_t id = 0; // unknown
uint32_t err = wl_display_get_protocol_error(displ->display, &interface, &id); // zwlr_output_configuration_head_v1_error
log_error("\nprotocol_error err=%u", err);
log_error("\nprotocol_error interface=%p", interface);
log_error("\nprotocol_error interface->name=%s", interface->name);
log_error("\nprotocol_error interface->version=%d", interface->version);
log_error("\nprotocol_error id=%u", id);
Unfortunately that's not so useful as an EPROTO
only occurs on a failed dispatch, which currently results in a catastrophic failure. Questionable value, as a meaningful error is printed to stdout by wayland.
@thefotios did WLR_DRM_NO_MODIFIERS=1
work for you?
@alex-courtis sorry I went dark, I was in the middle of job hunting.
Setting that ENV var seems to have done the trick. I tried a few permutations of (un)plugging the displays and they all work correctly. I did not have to set any modes manually.
For posterity, I set this in ~/.config/sway/environment
1 and it was sourced correctly. I'm running sway
using systemd
(from the Fedora Sway spin) but this might work for other WMs as well.
Footnotes
-
I forgot where I found out about that location; not sure if that's a default for
xdg-desktop-autostart
orsystemd
in general. ↩
That's fantastic, thank you!
I've updated the wiki: Unusable Displays Following MODE, please do edit that page as you see fit.
The doc I linked claimed the file is env
not environment
, however I haven't verified it. I'd be most grateful if you tested.
I reckon we're all done here - please do reopen the issue if you have any other questions or issues.