Incorrectly warning that a mode is not available

thefotios commented 8 months ago

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

way-displays.log

github-amine-kherbouche commented 8 months ago

I have the same issue with my laptop display, I have a 4k resolution but I cannot set a 1080p

alex-courtis commented 8 months ago

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

alex-courtis commented 8 months ago

@github-amine-kherbouche I'd be grateful if you attached a log and your configuration.

thefotios commented 7 months ago

@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

alex-courtis commented 7 months ago

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.

alex-courtis commented 7 months ago

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:

sway.5.alex.log

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.

alex-courtis commented 7 months ago

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.

alex-courtis commented 7 months ago

@thefotios did WLR_DRM_NO_MODIFIERS=1 work for you?

thefotios commented 7 months ago

@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.

[^1]: I forgot where I found out about that location; not sure if that's a default for xdg-desktop-autostart or systemd in general.

alex-courtis commented 7 months ago

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.

alex-courtis commented 7 months ago

I reckon we're all done here - please do reopen the issue if you have any other questions or issues.

alex-courtis / way-displays

Incorrectly warning that a mode is not available #137