Created attachment 141855 [details] Photo with both screens SUMMARY When attaching an external monitor with lower resolution (laptop internal: 2560x1440, external/HDMI: 1920x1080) and using "Unify outputs" on Wayland, outputs don't get unified but the external monitor's contents are shown in a kind-of window in the upper left corner of the internal monitor's screen. Note this works fine with Xorg; I can only reproduce this with Wayland. STEPS TO REPRODUCE 1. Run KDE in Wayland. Attach external monitor with FHD resolution. 2. Invoke kscreen, "Unify outputs". OBSERVED RESULT Internal monitor stays at original resolution, external monitor lights up. External monitor's display contents are shown in a subarea of the internal monitor. See attached screenshot(s). EXPECTED RESULT Both screens go to the same resolution and show the same content. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
What does "kscreen-doctor -o" command return ? Alternatively, can you post a screenshot of your screen settings ? (command is "kcmshell5 kscreen")
I tested with my laptop which has 3840x2160 at scale 1.75 setting with a 2560x1440 monitor. Upon plugging the HDMI cable I was prompted with the OSD (over the screen display) for when screens are plugged, I selected "Unify" (in french "Synchroniser") and the screens were unified. In Kscreen I could see both screens started at position (0,0), one being bigger that the other.
Created attachment 141942 [details] output of kscreen-doctor -o
Created attachment 141943 [details] screen shot of the kscreen dialog (page 1)
Created attachment 141944 [details] screen shot of the kscreen dialog (page 2)
Two screens may not be able to render at the same resolution. Here kscreen-doctor shows your laptop screens can only handle 2560*1440 resolution. One could tweak the scale of the laptop screen so that its resolution matches the smaller screen logical size. In this case, you'd need a 1.333333333 on the biggest screen which is not a valid scale factor. You'd need to scale down the external screen as well to find a matching resolutions which is most likely not a satisfying solution. So your situation and the attachment https://bugsfiles.kde.org/attachment.cgi?id=141944 shows the expected result in this case. You will see that kwin still maximizes windows in the shared area between screens. Just to make sure what is the output of `drm_info` ?
(In reply to Méven Car from comment #6) > Two screens may not be able to render at the same resolution. > Here kscreen-doctor shows your laptop screens can only handle 2560*1440 > resolution. This is a regression in Ubuntu 21.10. It worked perfectly before. xrandr shows a very long list of possible resolutions of the laptop screen, including 1920x1200 and 1920x1080 (the native resolution of the external screen). > One could tweak the scale of the laptop screen so that its resolution > matches the smaller screen logical size. > In this case, you'd need a 1.333333333 on the biggest screen which is not a > valid scale factor. > > You'd need to scale down the external screen as well to find a matching > resolutions which is most likely not a satisfying solution. > > So your situation and the attachment > https://bugsfiles.kde.org/attachment.cgi?id=141944 shows the expected result > in this case. > > You will see that kwin still maximizes windows in the shared area between > screens. I disagree; this worked before, and should continue to work; and the hardware isn't the limiting factor here. > Just to make sure what is the output of `drm_info` ? I'll add an attachment.
Created attachment 142310 [details] output of drm_info I concur that drm_info shows only one single possible resolution for the internal screen -- 2560x1440. However, cloning does work correctly when using X11.
Created attachment 142311 [details] output of xrandr drm_info ran from an X11 session also claims the internal screen can only do 2560x1440. However, xrandr clearly shows the internal screen can run at many resolutions, including 1920x1008, and can 1:1 mirror an external FHD screen.
> Created attachment 142310 [details] > output of drm_info > > I concur that drm_info shows only one single possible resolution for the > internal screen -- 2560x1440. However, cloning does work correctly when > using X11. `kscreen-doctor -o` to uses Xrandr as backend under X11, which would explain the difference. (In reply to Horst Schirmeier from comment #9) > Created attachment 142311 [details] > output of xrandr > > drm_info ran from an X11 session also claims the internal screen can only do > 2560x1440. However, xrandr clearly shows the internal screen can run at > many resolutions, including 1920x1080, and can 1:1 mirror an external FHD > screen. It seems like it is an upstream issue, if libdrm can't give us the information to act on, we can't do much. Thank you for doing this comparison. This seems like something you can report to libdrm as a bug. They will need to know your hardware (GPU in particular), I presume, you xrandr and drm_info output and this origin bug. https://gitlab.freedesktop.org/mesa/drm/-/issues?scope=all&state=opened
mesa/drm bug report: https://gitlab.freedesktop.org/mesa/drm/-/issues/69
The DRM people are directing me back here: > drm_info [...] just reports whatever the kernel advertises. IIRC xrandr adds > a bunch of "default" modes even if the monitor doesn't support them. > > Seems like what you're looking for is custom modes in KWin. Please fill a > feature request there. How should I proceed?
There's three things I think we can do: - fake standard modes with KMS or OpenGl scaling. Is guaranteed to work - ask the kernel people if they'd add a default modelist for misbehaving displays like yours - add common modes to the modelist if the kernel doesn't advertise them. These modes are not guaranteed to work but effectively always do work - as long as our default mode is what the monitor actually advertises we should be fine I want to add support for KMS scaling and custom modes anyways, adding common modes shouldn't be a problem either way.
KWin supports common modes now