When running plasmashell in a KVM/QXL/Spice VM, it fails to resize to the client window. spice-vdagent is running. While the GDM window still correctly follows the size/resolution changes of the outer window, plasma sticks to a fixed one that must be switched to manually. Reproducible: Always
If you type "xrandr -q" does that show the updated size?
Yes, it does. In the example down below I manually set the resolution in kscreen to 1280x720) and resized the window - the new resolution seems to be always the value appearing first in the list. In "virt-manager" the check box "View->Scale Display->Auto resize VM with window" is active. When I open the kscreen config now, 1024x768 is preselected in the dropdown and the "strange" resolution of my VM window is not selectable/shown in the list. Just to be very sure it's not a driver problem in my KDE VM, I just installed the "plasma" package group in my dedicated (working) GNOME VM (so everything is up-to-date [SDDM 0.13.0, Plasma 5.5.1, Frameworks 5.17.0 and Apps 15.12.0] without any old KDE libs/config etc.) and tried logging into Plasma via GDM as well as SDDM. The results are the same: * GDM adapts, Plasma starts in the "correct" resolution set by GDM but doesn't adapt anymore. * When booting with SDDM as display manager, it's already starting in a wrong resolution. A started GNOME session corrects the resolution and adapts, a Plasma session stays "wrong" and won't adapt either. [olaflostviking@kessel ~]$ xrandr -q Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192 Virtual-0 connected primary 1280x720+0+0 0mm x 0mm 1216x591 59.72 + 1920x1200 59.88 1920x1080 59.96 1600x1200 59.87 1680x1050 59.95 1400x1050 59.98 1280x1024 59.89 1440x900 59.89 1280x960 59.94 1280x854 59.89 1280x800 59.81 1280x720 59.86* 1152x768 59.78 1024x768 59.92 800x600 59.86 848x480 59.66 720x480 59.71 640x480 59.38 Virtual-1 disconnected Virtual-2 disconnected Virtual-3 disconnected [olaflostviking@kessel ~]$
Can I provide any more details of should I try out other things?
Still valid for 5.6.0
This affects me on Fedora 23 host/guest scenario with a F23 KDE Plasma 5 guest. GNOME guest of the same type works correctly. I can essentially confirm what @OlafLostViking has written. I am particularly interested in this because I use virt-manager/kvm/libvirt as a replacement for VMware/VirtualBox and I consider it a basic guest functionality.
Now that KDE is offering the "official" NEON packages I thought I should give them a try to rule out distribution/packaging problems. So I installed the NEON git stable image of today via ubiquity, updated it with an "apt-get update"/"apt-get upgrade" and added "spice-vdagent" to it: * neon-desktop (4+p16.04+git20160415.1334) * kwin (4:5.6.2+p16.04+git20160415.0003-0) * plasma-framework (5.21.0+p16.04+git20160416.0014-0) * sddm (0.13.0-1ubuntu5) This bug report is also valid for this installation.
two questions: 1) Can you check with qdbus org.kde.KWin /KWin supportInformation Whether KWin gets the resolution change correctly 2) Can you try changing the resolution through xrandr manually to see whether that gets applied correctly?
=== Setup === The following steps have been tried on these installations within a libvirt/KVM VM: - Neon (user): Qt 5.7.0, KWin/Plasma 5.7.0, kf5 5.24, QXL (Virtio doesn't even reach X11/SDDM) - Archlinux (kf5-only): Qt 5.7.0, KWin/Plasma 5.7.0, kf5 5.23, QXL as well as Virtio - Manjaro (KDE): Qt 5.7.0, KWin/Plasma 5.6.5, kf5 5.23, QXL - openSUSE (Tumbleweed): Qt 5.6.1, KWin/Plasma 5.6.4, kf5 5.23, QXL as well as Virtio All were updated to use the repository packages of today (2016-07-11) and rebooted while having 1280x720 set as desktop resolution. === Booting === They boot into a default sized (1024x768) SDDM, which doesn't react on VM window changes (unlike f.ex. GDM that I tested before in another VM, see comment #2). After logging in, Plasma/KSplash adjusts to the resolution of the last session. (At least most of the times... I finally gave up for now finding a pattern - I guess using xrandr vs kscreen makes a difference... But that's probably for another bug report one day ;-) ) === QDbus === Output of the qdbus command after login: ```[olaflostviking@valhalla ~]$ qdbus org.kde.KWin /KWin supportInformation | grep -A7 Screens ```Screens ```======= ```Multi-Head: no ```Active screen follows mouse: yes ```Number of Screens: 1 ``` ```Screen 0: ```--------- ```Name: Virtual-1 ### index depends on distribution ```Geometry: 0,0,1280x720 ```Refresh Rate: 60 ### exact frequency differs on distributions Changing the size of the outer VM window does _not_ alter the output of the qdbus query (`diff`ed the whole output). Using kscreen to change the resolution works as mentioned before. The output of the qdbus query changes at the "Geometry" entry only. === xrandr === With `xrandr --output Virtual-1 --mode 1280x720` I can switch to the desired resolution, too. This is correctly shown by a following `xrandr` (including * and +) as well as in the `qbus...` query on KWin (just to make it clear: the outer window size of the VM is correctly reflected by `xrandr` only but not the `qdbus` output). Thanks for having a look!
> Changing the size of the outer VM window does _not_ alter the output of the qdbus query This is very interesting. This means that we don't get an xrandr update when the window changes. Which would explain everything here. Could you (no need to do on multiple distributions) run xrandr before and after resizing the VM window and diff the change? My assumption is that the Screen 0 changes.
> Could you run xrandr before and after resizing the VM window and diff the change? Sure thing (using Neon): # after booting in a VM window with 1280x720, internal resolution 1280x720 after login $ xrandr > xrandr.before $ qdbus org.kde.KWin /KWin supportInformation > qdbus.before # increasing VM window size, no touching internal settings $ xrandr > xrandr.bigger $ qdbus org.kde.KWin /KWin supportInformation > qdbus.bigger # decreasing VM window size, no touching internal settings $ xrandr > xrandr.smaller $ qdbus org.kde.KWin /KWin supportInformation > qdbus.smaller $ diff xrandr.before xrandr.bigger 3c3 < 1280x720 59.86*+ --- > 1512x893 59.84 + 13a14 > 1280x720 59.86* $ diff xrandr.before xrandr.smaller 3c3 < 1280x720 59.86*+ --- > 1064x664 59.86 + 13a14 > 1280x720 59.86* $ diff qdbus.before qdbus.bigger $ diff qdbus.before qdbus.smaller
Not the result I expected, but also helps. It looks like the resolution changes, but our software stack does not react on it. That must be an XRandR event we don't handle yet. Well I need to create a VM for another bug anyway, so can investigate.
I now have a VM running through virtmanager. But I don't understand how I can resize the VM window. If I resize the window it does not affect xrandr at all. There are no changes. Any ideas what I do wrongly?
Are you using spice in the virt-manager and ran spice-vdagent inside of the VM? The spice protocol is the one responsible for the integration of host and guest. In Neon it is in universe/x11.
Oh, and it seems you have to select `View -> Scale Display -> Auto resize VM with window` in the virt-manager window.
I have now started spice-vdagent inside the VM (that was missing) and checked the auto resize option. But I still don't get any changes regarding the xrandr output - might be related to me running Wayland. Looks like virt-manager overall is not Wayland ready.
no dice, also with X11 it doesn't do any changes to xrandr. Does one need to do anything else? Specific GPU in kvm, or something like that?
You did check the setting in the menu mentioned in comment #14? I just tried all the GPUs available in KVM/virt-manager in Neon: * QXL: see above * Virtio: won't work with Neon, but in other distributions it behaves like QXL * Cirrus: does not report the true window resolution "to xrandr" * VGA: offers 800x600 as the only resolution available, no matter the host window size * VMVGA: lots of funny effects/flickering, locks up(!) after ksplash * Xen: doesn't come up at all To summarize: I'd say that for now QXL and in the long run Virtio are the two relevant GPUs for a Linux/KDE desktop in a KVM VM. The others are probably not that important for KWin (just my personal opinion!)?
All right that might explain it. I only tested with Cirrus so far as I had some bug reports regarding Cirrus to fix as well. Will try again with QXL.
Got it to work now, thanks. From my playing with it, I'm reassigning to kscreen. What I see is that when resizing the screen the resolution is added/removed but does not get selected. From XRandR perspective the selected resolution is still the old and removed one. Even if I restart e.g. KWin it picks the old resolution and KWin reads the information from XRandR directly. If I do an xrandr --output virtual-0 --auto everything is fine. Thus I think our kscreen daemon needs to listen to such changes in the XRandR backend and switch the resolution accordingly.
Randr events on resize of window (recorded through xev) RRScreenChangeNotify event, serial 37, synthetic NO, window 0x1200001, root 0x276, timestamp 300084, config_timestamp 801745 size_index 65535, subpixel_order SubPixelUnknown rotation RR_Rotate_0 width 1864, height 998, mwidth 492, mheight 263 RRNotify event, serial 37, synthetic NO, window 0x1200001, subtype XRROutputChangeNotifyEvent output Virtual-0, crtc 63, mode 1864x998 (1864x998) rotation RR_Rotate_0 connection RR_Connected, subpixel_order SubPixelUnknown (I'm significantly impressed that I'm able to copy from the x11 session of the guest system into the xwayland client of my host system)
Documenting some debug output from before and after resizing the VM window: /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher kscreen.xrandr: Connected output 67 to CRTC 63 !!!! Mode: 725 / QSize(1640, 871) !!!! Mode: 72 / QSize(1920, 1200) !!!! Mode: 73 / QSize(1920, 1080) !!!! Mode: 74 / QSize(1600, 1200) !!!! Mode: 75 / QSize(1680, 1050) !!!! Mode: 76 / QSize(1400, 1050) !!!! Mode: 77 / QSize(1280, 1024) !!!! Mode: 78 / QSize(1440, 900) !!!! Mode: 79 / QSize(1280, 960) !!!! Mode: 80 / QSize(1280, 854) !!!! Mode: 81 / QSize(1280, 800) !!!! Mode: 82 / QSize(1280, 720) !!!! Mode: 83 / QSize(1152, 768) !!!! Mode: 71 / QSize(1024, 768) !!!! Mode: 84 / QSize(800, 600) !!!! Mode: 85 / QSize(848, 480) !!!! Mode: 86 / QSize(720, 480) !!!! Mode: 87 / QSize(640, 480) !!!!!! Randr event listener inited kscreen.xcb.helper: Detected XRandR 1.4 kscreen.xcb.helper: Event Base: 89 kscreen.xcb.helper: Event Error: 147 kscreen.xrandr: XRandR::setConfig kscreen.xrandr: Requested screen size is QSize(1640, 871) kscreen.xrandr: Needed CRTCs: 1 kscreen.xrandr: Actions to perform: kscreen.xrandr: Primary Output: false kscreen.xrandr: Change Screen Size: true kscreen.xrandr: Old: QSize(1744, 953) kscreen.xrandr: Intermediate: QSize(1744, 953) kscreen.xrandr: New: QSize(1640, 871) kscreen.xrandr: Disable outputs: false kscreen.xrandr: Change outputs: true kscreen.xrandr: (67) kscreen.xrandr: Enable outputs: false kscreen.xrandr: RRSetCrtcConfig (change output) kscreen.xrandr: Output: 67 ( "Virtual-0" ) kscreen.xrandr: CRTC: 63 kscreen.xrandr: Pos: QPoint(0,0) kscreen.xrandr: Mode: "725" ( QSize(1640, 871) ) kscreen.xrandr: Rotation: 1 kscreen.xrandr: Result: 0 kscreen.xrandr: XRandROutput 67 update kscreen.xrandr: m_connected: 0 kscreen.xrandr: m_crtc XRandRCrtc(0x813170) kscreen.xrandr: CRTC: 63 kscreen.xrandr: MODE: 725 kscreen.xrandr: Connection: 0 kscreen.xrandr: Primary: true !!!! Mode: 725 / QSize(1640, 871) !!!! Mode: 72 / QSize(1920, 1200) !!!! Mode: 73 / QSize(1920, 1080) !!!! Mode: 74 / QSize(1600, 1200) !!!! Mode: 75 / QSize(1680, 1050) !!!! Mode: 76 / QSize(1400, 1050) !!!! Mode: 77 / QSize(1280, 1024) !!!! Mode: 78 / QSize(1440, 900) !!!! Mode: 79 / QSize(1280, 960) !!!! Mode: 80 / QSize(1280, 854) !!!! Mode: 81 / QSize(1280, 800) !!!! Mode: 82 / QSize(1280, 720) !!!! Mode: 83 / QSize(1152, 768) !!!! Mode: 71 / QSize(1024, 768) !!!! Mode: 84 / QSize(800, 600) !!!! Mode: 85 / QSize(848, 480) !!!! Mode: 86 / QSize(720, 480) !!!! Mode: 87 / QSize(640, 480) kscreen.xrandr: RRSetScreenSize kscreen.xrandr: DPI: 98.3992 kscreen.xrandr: Size: QSize(1640, 871) kscreen.xrandr: SizeMM: QSize(423, 224) kscreen.xrandr: XRandR::setConfig done! kscreen.xcb.helper: RRNotify_CrtcChange kscreen.xcb.helper: CRTC: 63 kscreen.xcb.helper: Mode: 725 kscreen.xcb.helper: Rotation: "Rotate_0" kscreen.xcb.helper: Geometry: 0 0 1640 871 kscreen.xcb.helper: RRScreenChangeNotify kscreen.xcb.helper: Window: 16777220 kscreen.xcb.helper: Root: 630 kscreen.xcb.helper: Rotation: "Rotate_0" kscreen.xcb.helper: Size ID: 65535 kscreen.xcb.helper: Size: 1744 953 kscreen.xcb.helper: SizeMM: 451 246 kscreen.xcb.helper: RRNotify_CrtcChange kscreen.xcb.helper: CRTC: 63 kscreen.xcb.helper: Mode: 725 kscreen.xcb.helper: Rotation: "Rotate_0" kscreen.xcb.helper: Geometry: 0 0 1640 871 kscreen.xcb.helper: RRScreenChangeNotify kscreen.xcb.helper: Window: 16777220 kscreen.xcb.helper: Root: 630 kscreen.xcb.helper: Rotation: "Rotate_0" kscreen.xcb.helper: Size ID: 0 kscreen.xcb.helper: Size: 1640 871 kscreen.xcb.helper: SizeMM: 423 224 kscreen.xrandr: Emitting configChanged() kscreen.xcb.helper: RRotify_OutputChange kscreen.xcb.helper: Output: 67 kscreen.xcb.helper: CRTC: 63 kscreen.xcb.helper: Mode: 725 kscreen.xcb.helper: Rotation: "Rotate_0" kscreen.xcb.helper: Connection: "Connected" kscreen.xcb.helper: Subpixel Order: 0 kscreen.xcb.helper: RRScreenChangeNotify kscreen.xcb.helper: Window: 16777220 kscreen.xcb.helper: Root: 630 kscreen.xcb.helper: Rotation: "Rotate_0" kscreen.xcb.helper: Size ID: 65535 kscreen.xcb.helper: Size: 1640 871 kscreen.xcb.helper: SizeMM: 423 224 kscreen.xcb.helper: RRotify_OutputChange kscreen.xcb.helper: Output: 67 kscreen.xcb.helper: CRTC: 63 kscreen.xcb.helper: Mode: 725 kscreen.xcb.helper: Rotation: "Rotate_0" kscreen.xcb.helper: Connection: "Connected" kscreen.xcb.helper: Subpixel Order: 0 !!!!! Have already that output !!!!! in false branch kscreen.xrandr: XRandROutput 67 update kscreen.xrandr: m_connected: 0 kscreen.xrandr: m_crtc XRandRCrtc(0x813170) kscreen.xrandr: CRTC: 63 kscreen.xrandr: MODE: 725 kscreen.xrandr: Connection: 0 kscreen.xrandr: Primary: true !!!! Mode: 732 / QSize(1680, 907) !!!! Mode: 72 / QSize(1920, 1200) !!!! Mode: 73 / QSize(1920, 1080) !!!! Mode: 74 / QSize(1600, 1200) !!!! Mode: 75 / QSize(1680, 1050) !!!! Mode: 76 / QSize(1400, 1050) !!!! Mode: 77 / QSize(1280, 1024) !!!! Mode: 78 / QSize(1440, 900) !!!! Mode: 79 / QSize(1280, 960) !!!! Mode: 80 / QSize(1280, 854) !!!! Mode: 81 / QSize(1280, 800) !!!! Mode: 82 / QSize(1280, 720) !!!! Mode: 83 / QSize(1152, 768) !!!! Mode: 71 / QSize(1024, 768) !!!! Mode: 84 / QSize(800, 600) !!!! Mode: 85 / QSize(848, 480) !!!! Mode: 86 / QSize(720, 480) !!!! Mode: 87 / QSize(640, 480) kscreen.xrandr: Output 67 : connected = true , enabled = true !!!!! Have already that output !!!!! in false branch kscreen.xrandr: XRandROutput 67 update kscreen.xrandr: m_connected: 0 kscreen.xrandr: m_crtc XRandRCrtc(0x813170) kscreen.xrandr: CRTC: 63 kscreen.xrandr: MODE: 725 kscreen.xrandr: Connection: 0 kscreen.xrandr: Primary: true !!!! Mode: 732 / QSize(1680, 907) !!!! Mode: 72 / QSize(1920, 1200) !!!! Mode: 73 / QSize(1920, 1080) !!!! Mode: 74 / QSize(1600, 1200) !!!! Mode: 75 / QSize(1680, 1050) !!!! Mode: 76 / QSize(1400, 1050) !!!! Mode: 77 / QSize(1280, 1024) !!!! Mode: 78 / QSize(1440, 900) !!!! Mode: 79 / QSize(1280, 960) !!!! Mode: 80 / QSize(1280, 854) !!!! Mode: 81 / QSize(1280, 800) !!!! Mode: 82 / QSize(1280, 720) !!!! Mode: 83 / QSize(1152, 768) !!!! Mode: 71 / QSize(1024, 768) !!!! Mode: 84 / QSize(800, 600) !!!! Mode: 85 / QSize(848, 480) !!!! Mode: 86 / QSize(720, 480) !!!! Mode: 87 / QSize(640, 480) kscreen.xrandr: Output 67 : connected = true , enabled = true kscreen.xrandr: Emitting configChanged() Explanation: when started the mode 725 is used. That one gets removed when the window resizes. Instead we get a new mode 732. KScreen tries to apply it's current config which fails: kscreen.kded: Change detected kscreen.kded: Saving current config to file kscreen: canBeApplied: The output: 67 has no mode: "725" In that case it might be an idea to go to the preferred mode (732). Overall it's rather tricky to detect that a mode got removed and one got added. We just don't have any knowledge about this. There is no event for that. So all rather meh.
A shot in the dark: https://phabricator.kde.org/D2155 This hooks into the change signal path, and "fixes up" output's current mode id. It seems that the internal list of outputs is already updated, but the output id of the output isn't.
I just setup a Neon Developer Unstable VM. So I can help trying out stuff in there! (As of today, it doesn't work.)
Great. I'm making some progress on the code side. It's a little involved, since the list of modes per output is static, so it's not actually supposed to change. That's expressed in libkscreen's API, and on top of that, modelist changes aren't handled throughout. Now I've done some work on falling back to the preferred mode if the current one is invalid, that's actually landed in 5.8.0, but the mode list is still static. We'll have to see if this can actually be merged into 5.8, or if the API change we need for this is too intrusive (I don't see a way around that). On my machine, I've made the necessary changes to make the mode list dynamic and notifyable. The problem is that I can't test this easily myself, as I'd need to have a build inside the VM to debug it properly. Bottom line, with the changes that I'll post for review shortly, this *could* actually work, but we may need other fixes here and there. Perhaps we can get these things in through Neon. *goes to finish and clean up that branch*
Git commit 6cc05cae8143bf2a1f50389f39cc7976ac7030b7 by Sebastian Kügler. Committed on 20/10/2016 at 22:07. Pushed by sebas into branch 'master'. allow changing an output's modelist at runtime This should fix running Plasma in a windowed virtual machine, when the window is resized, the mode list changes, and libksreen can't currently handle that. Summary: * make Output::modes() non CONSTANT, add modesChanged() signal * compare the mode lists and set the new one * queue an outputChanged signal when applied * autotest for modelist changes * update the mode list on RRNotify events Test Plan: * for library part, autotests are added * for xrandr backends, we can't sensibly autotest this :( Reviewers: #plasma, mart Reviewed By: mart Subscribers: graesslin, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3117 M +1 -0 autotests/CMakeLists.txt A +179 -0 autotests/testmodelistchange.cpp [License: LGPL (v2.1+)] M +9 -1 backends/xrandr/xrandroutput.cpp M +36 -1 src/output.cpp M +9 -1 src/output.h http://commits.kde.org/libkscreen/6cc05cae8143bf2a1f50389f39cc7976ac7030b7
This patch is not sufficient, I should have used CCBUG, not BUG in the commit. Sorry for the noise. (I'm working on it, though.)
I'm trying to reproduce by running a neon session in a virt-manager, using qemu. I've the driver QXL, and I've installed qemu-ga inside the vm, but it can't find a channel, so it doesn't work. The error is: critical: error opening channel: Device or resource busy critical: error opening channel critical: failed to create guest agent channel critical: failed to initialize guest agent channel (The resize "vm with window" checkbox is greyed out, complains about missing guest agent) I'm a bit lost here, anyone who can help?
Did you install and run the mentioned spice-vdagent? This is mandatory for virt-manager based VMs to communicate with the host.
(getting back to this, I haven't forgotten, just was on vacation) I think I'm being an utter muppet here. I have started spice-vdagent, qemu-ga gives the same error. Perhaps the wrong magical invocation? Would it be possible for someone to give me detailed instructions how to reproduce, if I have to spend days just to reproduce the problem, that makes coming up with a fix so much harder...
(Welcome back, I hope you are refreshed enough for all these bugs ;-) ) I'm not an expert for virt-manager. But by default my own virt-manager is just setting up a spice-channel. This channel is then used for the communication with the host and the vm guest (via space-vdagent). I never had a qemu-ga channel active (or qemu-guest-agent installed in the guests). So if you just setup a "default" KVM-VM in virt-manager and install (and autostart, obviously) spice-vdagent in the client, everything should work (without qemu-ga). Out of curiosity, I installed qemu-guest-agent into my Neon VM, created a GA channel in virt-manager and rebooted. Connecting to the channel worked, but no changes in adapting to the outer VM window. Just logs already shown by Martin in the journal.
Ok, cool. After some more fiddling, I'm getting the events now that I was looking for. On it.
Git commit b8a7cd7044fa483c2c77a4ab7f0b64c08f2c3304 by Sebastian Kügler. Committed on 17/11/2016 at 02:37. Pushed by sebas into branch 'master'. apply config change after correcing invalid mode The logic here to find and set the correct mode was OK, we just forgot to actually apply the changes. This change makes resizing plasmashell to the vm host window "kind of" work. When the window gets bigger it works, when either axis gets smaller, I'm getting a black screen (which can be corrected by making the window just a little bit bigger and triggering another modeset). This is a separate problem, however, since I can reproduce the exact same behaviour just using xrandr. This means, that we do now have all the bits and pieces in place for handling changes of modes at runtime. I'm not closing this bug just yet, since I want to give this some more testing exposure and possibly iron out some wrinks. M +1 -0 kded/daemon.cpp http://commits.kde.org/kscreen/b8a7cd7044fa483c2c77a4ab7f0b64c08f2c3304
Alright, after some more testing, I'm quite confident that this works now. To give this some context, this small patch plus the one from comment#25 makes it work for me, that's the status reflected in git master. I want to give this some more exposure. Packages are now available through Neon git unstable, so perhaps someone can test it? I'm aiming to get these fixes backported to the next Plasma 5.8 update.
*** Bug 370494 has been marked as a duplicate of this bug. ***
I updated the Neon VM during the last days (as well as just minutes ago) but my plasma desktop didn't adjust itself to the VM window. But then I opened up kscreen to check if the new "strange" resolution is finally visible in its dropdown (which it is now!) and after applying this, the desktop adjusts (with some delay)! This is great, thank you very much! There still seems to be some problems as I first had to adjust the screen manually once and the kscreen dialog is not updated with available modes when it's opened, but after this I can finally use KDE in a fullscreen VM :D BTW: Is SDDM using kscreen, too? (since it isn't using any other resolution but the default in contrast to GDM that adapts just fine)
Git commit f6bbb3782566fbac431bbdc641c55942d8643951 by Sebastian Kügler. Committed on 22/11/2016 at 13:50. Pushed by sebas into branch 'sebas/dynmodes'. apply config change after correcing invalid mode The logic here to find and set the correct mode was OK, we just forgot to actually apply the changes. This change makes resizing plasmashell to the vm host window "kind of" work. When the window gets bigger it works, when either axis gets smaller, I'm getting a black screen (which can be corrected by making the window just a little bit bigger and triggering another modeset). This is a separate problem, however, since I can reproduce the exact same behaviour just using xrandr. This means, that we do now have all the bits and pieces in place for handling changes of modes at runtime. I'm not closing this bug just yet, since I want to give this some more testing exposure and possibly iron out some wrinks. M +1 -0 kded/daemon.cpp http://commits.kde.org/kscreen/f6bbb3782566fbac431bbdc641c55942d8643951
Git commit 7367e55b7c172d54d068eb09f308e92368c294e9 by Sebastian Kügler. Committed on 22/11/2016 at 13:31. Pushed by sebas into branch 'sebas/dynmodes'. allow changing an output's modelist at runtime This should fix running Plasma in a windowed virtual machine, when the window is resized, the mode list changes, and libksreen can't currently handle that. Summary: * make Output::modes() non CONSTANT, add modesChanged() signal * compare the mode lists and set the new one * queue an outputChanged signal when applied * autotest for modelist changes * update the mode list on RRNotify events Test Plan: * for library part, autotests are added * for xrandr backends, we can't sensibly autotest this :( Reviewers: #plasma, mart Reviewed By: mart Subscribers: graesslin, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3117 M +1 -0 autotests/CMakeLists.txt A +179 -0 autotests/testmodelistchange.cpp [License: LGPL (v2.1+)] M +9 -1 backends/xrandr/xrandroutput.cpp M +36 -1 src/output.cpp M +9 -1 src/output.h http://commits.kde.org/libkscreen/7367e55b7c172d54d068eb09f308e92368c294e9
Git commit d5b9d37767adbf2a035281fbeb5f38a309160413 by Sebastian Kügler. Committed on 23/11/2016 at 15:22. Pushed by sebas into branch 'Plasma/5.8'. apply config change after correcting invalid mode The logic here to find and set the correct mode was OK, we just forgot to actually apply the changes. This change makes resizing plasmashell to the vm host window "kind of" work. When the window gets bigger it works, when either axis gets smaller, I'm getting a black screen (which can be corrected by making the window just a little bit bigger and triggering another modeset). This is a separate problem, however, since I can reproduce the exact same behaviour just using xrandr. This means, that we do now have all the bits and pieces in place for handling changes of modes at runtime. I'm not closing this bug just yet, since I want to give this some more testing exposure and possibly iron out some wrinks. M +1 -0 kded/daemon.cpp https://commits.kde.org/kscreen/d5b9d37767adbf2a035281fbeb5f38a309160413
I just updated the VM again: * The guest desktop will still only adjust to the outer window size after it has been changed at least once manually via kscreen to the exact size of a resized VM window. * The modelist in kscreen is not updated when resizing (but that's not really critical, I'd say). So you have to open it just after resizing your outer window.
I'm right now getting a stable branch set up to test with, since I want these changes in the next 5.8 update. David has given the backports another review. As to updating the dropdown in kscreen is kind of on my radar. I'm reworking the kscreen system settings module right now, so I may just make sure it works in the new version. As to the changing of initial size, here's how I imagined it would just magically work 0. you log into a new session 1. the desktop is set to the preferred mode since there's otherwise no configuration 2. when resizing the window, the current (=preferred) mode vanishes, the code now changes to the new preferred mode Number 2 is my thinko, I don't think we do actually set the preferred resolution. Currently, we don't change the screen setup when nothing is pre-configured on first login, and to be honest ... I don't think we should change that rather fundamental behavior, it bears a huge amount of potential for breakage on innocent people's systems. That means that we need to start with the correct (== preferred == current vm window size) to begin with. Thoughts?
I'm not sure if I understood you correctly. But if you suggested that, when starting a plasmashell session, you set the initial resolution to the size of the VM window (preferred resolution as shown by xrandr), independently of what the last set resolution was, I agree. So, do not try to tranfer the resolution of the last shutdown to the new startup. Always stay with the preferred mode until the user manually switches away from it. And go back to the adapting size if the user selects the window size again. To improve the user experience, I'd suggest to add a checkbox "Use preferred resolution" which is checked by default. And only when the user deactivates that, plasma uses fixed resolutions as given in kscreen. By using this approach it would even be possible for a user to always stay with a "strange" resolution even when rebooting the VM (plasma always restores the last selected resolution when the checkbox wasn't selected). This would also help people on "real" hardware that have to carry their machine from projector to projector. Plasma wouldn't switch between different resolutions if the user forced f.ex. 1024x768. Only after selecting "Use preferred mode" plasma/kscreen takes back command and adapts to the resolution of the hardware/vm window.
Let me try to clear it up then. :) Currently, we don't change the resolution if the user hasn't configured this exact combination of screens previously. That means that if you log into a fresh session, we don't do anything on login wrt screen setup. We expect the system to be set up. With the current state, we now detect if the current resolution goes away, and we react to that by modesetting the new preferred resolution. So if you log in to a fresh vm, the login manager (or X startup) has to take care of that, to avoid unnecessary mode changes. The move from projector problem, I'm not sure I understand. We only save/restore a config for a given combination of outputs connected, the edid or model + serial of all connected outputs are hashed, and used as key to find the right config. We do not apply configs to unknown hardware. The initial setup for a given projector would be the same, as that is done using heuristics, and after once changed from the ui, the config is remembered only for that combo of outputs. I like the idea of making the preferred mode more prominent, or logical in the UI, I'll give that some more consideration. Currently working on bits and pieces for an improved KCM, so that kind of input is well-timed. :)
(In reply to Sebastian Kügler from comment #42) > That means that if you log into a fresh session, we don't do anything on > login wrt screen setup. We expect the system to be set up. Oh, I'm sorry, now I understand! As I'm currently having so many problems with Plasma and multiscreen I totally forgot about that possibility of changing screens ;-D. Since I cannot remember seeing a messed up resolution with native modesetting in SDDM (poulsbo doesn't count...), I agree with you on real hardware. Getting things like rotated screens/orientation of tablets etc. over DDC or whatever tablets are using is probably too much to ask for now ;-). > With the current state, we now detect if the current resolution goes away, > and we react to that by modesetting the new preferred resolution. So if you > log in to a fresh vm, the login manager (or X startup) has to take care of > that, to avoid unnecessary mode changes. Adapting to a changing preferred resolution is basically the most important thing. I just retried it (Neon is great for this!) and it still won't adapt until I manually adapted the resolution in kscreen at least once (just as you described). To _always_ switch to the preferred resolution (as long as the setting to always use preferred mode is active [f.ex. by some administrative or /etc/skel file entry - you do not necessaryily have to had a session running to have non-default settings]) could also be an alternative in the case of VMs, where SDDM doesn't set the correct resolution for now. Just think about automatically started fullscreen VMs at some kind of kiosk. On the other hand I understand that this should be the display manager's job... :-/ I'll try to play around with it a little bit. Perhaps there's another solution. > The move from projector problem, I'm not sure I understand. Sorry, I didn't make myself very clear. And after typing up a looong paragraph explaining it, I realized this would open up pandorra's box. So for now I'd say ignore what I said at this point ;-) > I like the idea of making the preferred mode more prominent, or logical in > the UI, I'll give that some more consideration. Currently working on bits > and pieces for an improved KCM, so that kind of input is well-timed. :) Great! I'm glad you are improving kscreen more and more. And if you're redesigning, please prevent the screen "icons" jump around as soon as you enable them - setting up a huge mulit-monitor setup on a low resolution notebook screen is a horror *duck and run* ;-D
Sorry for the double post. But after talking about the display manager: What about setups without display managers? Where the plasma sessions is started directly by systemd or sth. similar?
After the VM window was in fullscreen size, kscreen/plasma no longer automatically adapts to a new (smaller or bigger) size of the VM window. It's necessary to manually adapt to the new size just like after the very first login.
Hi, Some more information since apparently the situation changed. Whonix have been updated to 14. so the plasmashell have been integrated into a debian stretch version. It's a fresh installation from whonix with the default VM. The graphic card is QXL, the graphic server is spice. Since the starting resolution is 1024*768 , I've tried to changed it to 1440*900 but apparently your kscreen_backend doesn't like it. I got, on the next login/reboot, a segmentation fault at 10 ip 00007f6eec42d568 sp 000007ffcec4bdb60 error 4 in KSC_XRandR.so[7f6eec413000+23000] I didn't test all the resolution yet but I guess some of them are buggy as well. So you might look into that and test your kscreen_backend thoroughly before put this bug as fixed. uname -a: 4.9.0.7-amd64 debian 4.9.110-3+deb9u1 kscreen: 4:5.8.5-2 libxrandr2: 2:1.5.1-1 plasma-framework: 5.20.0-2 plasma-desktop: 4:5.8.6-1 Tell me if you need something else...
It's definitely a bug. As a workaround, when the screen is resized you can execute "xrandr --output Virtual-0 --preferred" and it will just work from there From my research, a proper solution would be to follow the preferred setting if we're on preferred and the preferred mode changes. Here's a video that shows the issue: https://youtu.be/hzjATkojyV8
Still issue with Ubuntu Server 18.10 host and Kubuntu 18.10 guest. As ugly workaround, I put "sleep 10 && xrandr --output Virtual-0 --preferred" into session autostart, because simple "xrandr --output Virtual-0 --preferred" didn't work for some reason. Is anyone can look into more proper solution or at least less ugly workaround?
Yes, but not until kscreen support is in, that will be in Plasma 5.15.0.