I have an annoying situation on my TW KDE system. I use a KVM switch to allow me to switch between this system and another small PC. Sometimes when it is switched to the other PC the TW system alters the screen resolution but with no action or input by me. So when I switch back the display is 1024x768 and not 1920x1080 which is how it is set up. Also when I try to use System Settings Display & Monitor I am unable to increase the resolution as the maximum available shows as 1024x768. The only way Iāve been able to reset it is to logout and login again which is intensely annoying. Incidentally the other PC which is running Windows 7 does not change resolution at all no matter how long the monitor is switched away from it.
So something is doing this while the monitor is switched away from the TW system. Is there any way I can prevent this or perhaps at a push at least reset it by command rather than having to logout/in?
Hi, your initial post is from 2018, no answer, but maybe now
I have exactly the same behaviour with Leap 15.5, KDE/Plasma on Wayland, āMesa IntelĀ® HD Graphicsā
My Monitor (Dell 2720D) is connected to the Leap 15.5 box via DisplayPort, screen resolution 2560*1440, as it should be.
Also connected to this Monitor, but via HDMI, is an NVR. When I change input source of Monitor to HDMI, NVR works fine, but when I then switch back to DisplayPort, screen resolution is reduced to FullHD, and settings show this as available maximum resolution.
Workaround, as you said, logout/login, or reboot. A little annoying as I often have pretty much stuff opened in parallelā¦
QUESTION: Is there any chance to trigger a ārereadā of max. screen resolution in a runnning Wayland / Plasma session, via bash? Or set it āhardā via bash?
Does the NVR support and use 2560x1440? Is a firmware update available for the 2720D?
Possible workarounds for Xorg/X11 use:
xrandr --auto (simply xrandr might be enough)
xrandr --output DP-1-8 --auto (use appropriate output name supplied from #1 output or name found in Xorg.0.log or its Wayland equivalent)
xrandr --output DP-1-8 --mode 2560x1440 (use appropriate output name supplied from #1 output)
Switch to any of vttys not in use by X (e.g. Ctrl-Alt-F4), then switch back (Alt-F7, Alt-F1, Alt-F2 - whichever works)
Create configuration logically connecting the two outputs in use to the respective displays, and include monitor HorizSync and VertRefresh values for the problem display in āSection āMonitorāā, via /etc/X11/xorg.conf.d/. As alternative to the H & V specs, providing a 2560x1440 modeline might work. The sax3 utility might be able to do all this, much easier than manually, if it works at all.
Create an xrandr script that creates and applies a 2560x1440 modeline.
I suspect if #1 fails, so would #2 & #3, resulting in a mode not found error. I suppose in Wayland #4 should work and #5 might work. My personal experience using Wayland remains null.
@mrmazda Thanks for your answer!! Iāve the strong feeling that this issue is related to my DELLās āautoā input mode feature, as not 100%, but somewhat reproducible:
When I have input mode set to āautoā, means DP or HDMI, and plug in NVRās HMDI cable, DELL monitor switches to the NVR, (which, youāve asked, supports and is set to 2K/2560*1440) automatically. When I then switch back manually to PC/OpenSUSE, I have the ālost resolution issueā. NOT always, but quite often. When Iāve set the input mode to DP or HDMI instead of auto, AFAIK until now the modes are staying stable. Writing now from 1280*1024, as current max, funny on a 27ā monitor
To your suggestions:
xrandr --auto does nothing.
(xrandr without params shows āXWAYLAND0ā as output name)
ā¦ does nothing
ā¦ says āxrandr: cannot find mode 2560x1440ā
ā¦ is interesting: Even the vttys are āsqueezedā, other (much bigger characters) resolutionā¦ But: Switch to and switch back (to Wayland) does not change anything
$> xrandr --output XWAYLAND0 --mode 2560x1440_60.00
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 141 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x0
Serial number of failed request: 22
Current serial number in output stream: 22
No idea what this means, will have to reboot to get my 2560x1440 back now
I have no idea to what extent xrandr may be supported, if it is at all, when Wayland is involved. To achieve any benefit from any of my xrandr suggestions probably requires you be running a plasma-x11 session.
Note that personally I have never achieved success by supplying CVT or GTF-generated modelines that I was not able to achieve otherwise. Iām sure itās been well over a decade since I last tried solving problems by supplying modelines via xorg.con*. I offered the suggestion because I often see others make the suggestion, and wanted my suggestions to be as complete as I could make them.
Auto input selection from Dell displays for me has been somewhat hit or miss going back more than two decades. The last one I had that kind of trouble with went stone dead at about age 5. The two in current use mostly only get used with DVI input from one PC on one and DVI input on the other from a large collection of test PCs variously using or not a HDMI/DVI adapter.
