Bug 370494

This is nothing the window manager should do. Reassigning to kscreen which might be the best fitting area.

Personally I think that's a problem of virt-viewer. This used to work in the past and got broken. There is no reason why every desktop environment has to reimplement the same code instead of having one generic solution.

This could be two things:

(1) libkscreen failing to mode-set for some reason, we had a number of bugs that could lead to that and fixed them for 5.8.

(2) https://bugs.kde.org/show_bug.cgi?id=356864 which means that xrandr changes the list of modes on the fly, which libkscreen doesn't handle gracefully enough (yet). In that case, killing kscreen_backend_launcher and kded5, then restarting kded5 should allow to set the correct mode (not an acceptable workaround, of course, just a quick test to confirm this hunch).

To judge, we'd need
* confirmation if this is fixed in Plasma 5.8, or not
* xrandr -q, ~/.local/share/kscreen/kscreen.log, etc., as explained on https://community.kde.org/Solid/Projects/ScreenManagement#Debugging_Information

Unfortunately I run Debian Stable and it will be a while before 5.8 lands in the repo. I understand there is a lot going on that you have to handle but please try to prioritize this before the Debian Stretch freeze.

The thing is, I need to know if it works with 5.8, I won't spend time on it without knowing that it's still broken as I can't fix it twice. So if you ask me to prioritize this problem, that's useless unless I get the information I need to actually work on this.

Hi, it is not fixed in
plasma-desktop-5.8.1-1.fc25.x86_64

Respectively it resizes once, just after the login, after that it doesn't react on changes of window size

Created attachment 101622 [details]
~/.local/share/kscreen/kscreen.log

Created attachment 101623 [details]
xrandr -q

Preferred changed to:
1920x1080     59.96 +  60.00
but the current didn't adjust

Thanks! Could you also post the output of:

* kscreen-console (should show the same mode info as xrandr -q, but does it really?)
* and the remaining files in ~/.local/share/kscreen/

Also, if you look "tail -f ~/.local/share/kscreen/", are there any new events in kscreen.log when you resize the window?

If you kill kscreen_backend_launcher (it will be automatically restarted when needed), does kscreen-console show the information matching with xrandr -q?

I've looked into the hotplug flag that was added in GNOME to make this case work, but this is not available through XCB (I couldn't find it), but should work automatically -- that is we do monitor the relevant events for the output, this is done in libkscreen/backends/xcblistener.cpp

    xcb_randr_select_input(c, m_window,
            XCB_RANDR_NOTIFY_MASK_SCREEN_CHANGE |
            XCB_RANDR_NOTIFY_MASK_OUTPUT_CHANGE |
            XCB_RANDR_NOTIFY_MASK_CRTC_CHANGE |
            XCB_RANDR_NOTIFY_MASK_OUTPUT_PROPERTY
    );

Created attachment 101628 [details]
xrandr -q

Created attachment 101629 [details]
kscreen-console

Created attachment 101630 [details]
~/.local/share/kscreen/kscreen.log

Created attachment 101631 [details]
another file under kscreen

Created attachment 101632 [details]
tail -f ~/.local/share/kscreen/

Resized to something bigger than 1024x768

(In reply to Sebastian Kügler from comment #8)
> Thanks! Could you also post the output of:
> 
> * kscreen-console (should show the same mode info as xrandr -q, but does it
> really?)
> * and the remaining files in ~/.local/share/kscreen/
> 
> Also, if you look "tail -f ~/.local/share/kscreen/", are there any new
> events in kscreen.log when you resize the window?

yes, there is a notify but not matching newly requested size
> 
> If you kill kscreen_backend_launcher (it will be automatically restarted
> when needed), does kscreen-console show the information matching with xrandr
> -q?
yes, both provide the same info - the correct preferred size
> 
> I've looked into the hotplug flag that was added in GNOME to make this case
> work, but this is not available through XCB (I couldn't find it), but should
> work automatically -- that is we do monitor the relevant events for the
> output, this is done in libkscreen/backends/xcblistener.cpp

mutter uses drmModeGetProperty to get info about "hotplug_mode_update" (it is drm kms property - I googled for some info and found https://01.org/linuxgraphics/gfx-docs/drm/drm-kms-properties.html )

Also in mutter it is not about the value of the property, but about its presence. This comment may be useful:
https://git.gnome.org/browse/mutter/tree/src/backends/meta-monitor-config.c#n1478

> 
>     xcb_randr_select_input(c, m_window,
>             XCB_RANDR_NOTIFY_MASK_SCREEN_CHANGE |
>             XCB_RANDR_NOTIFY_MASK_OUTPUT_CHANGE |
>             XCB_RANDR_NOTIFY_MASK_CRTC_CHANGE |
>             XCB_RANDR_NOTIFY_MASK_OUTPUT_PROPERTY
>     );

Created attachment 101634 [details]
kded5 debug with timestamp

can the bug be related to this:
[20::00:58.168] unknown: Unable to get EDID for output "Virtual-1"
[20::00:58.205] unknown: Failed to register device: "device id 'xrandr-Virtual-1' already exists"
[20::00:58.207] unknown: Failed to create ICC profile on cmsCreateRGBProfile
[20::00:59.150] unknown: Config does not have at least one screen enabled, WILL NOT save this config, this is not what user wants.

Interesting. So it seems we do get an update event, but since we don't reparse the mode list, it stays static, and nothing actually changes.

Thanks a lot for the info, I'll look into coming up with a fix.

So, good news.

This bug is a duplicate of another of bug:356864. 

Here's a bit of context, before I redirect this bug's traffic to the other one, which has tracked the related changes.

libkscreen's list of modes for each output were never assumed to change at runtime, so a whole lot of components assumed it would never change and not react to changes, the list of modes was constant, as reasonable assumption given hardware. Less reasonable in vms, as we know. So the vm presents us with changing modes for outputs, but these were never re-read (in our xrandr backend), and changes never propagated through libkscreen's API to the kded module (which handles all the policy bits and initiates the actual changes at runtime). A few patches down the road, and I've now successfully (with git master) resizing Plasma inside the VM window.

In my setup (qemu with neon git unstable inside, host is a debian unstable thinkpad with intel graphics), I'm running into a bug, however. When at least one axis of the vm window shrinks, I reliably get a black screen, when I grow any or both axes, and kscreen's kded sets the new mode, it works again. I can reproduce this behavior also with using bare xrandr, so I assume that this is not a problem in kscreen. More info on that welcome, of course.

So git master has all the patches in place, and I'll look into backporting these bits to Plasma 5.8.4.

*** This bug has been marked as a duplicate of bug 356864 ***