I recently found out that an issue I was experiencing with VMs did not occur on X11, but was 100% reproducable on Wayland. As long as I avoid full-screen, they tolerate Wayland, but when I do go to full-screen, they instantly lock up both the VM and its host.
Description
Description
Event Timeline
Comment Actions
I just realized I typed HOME+F when I meant to type HOST+F. I hope I caused no confusion with that, but couldn't find a way to edit it.
Comment Actions
Now that Solus 4.4 has been released, and I still cannot take a VM to full-screen while in a Wayland session, I thought I'd ask about it again here.
The issue still exists -- as originally described -- in a Wayland session on Solus Plasma. I cannot reproduce it in an X11 session. If it cannot be be resolved here, it would be very helpful if it can at least be determined for sure that it 's an upstream KDE problem, OR it can be determined for sure that it's an upstream VirtualBox problem. Then I can focus my efforts there, instead of here.
Comment Actions
I don't know whether I've mentioned this before, but in a Wayland session, I can successfully maximize a VM within the host window's client area. This does not lock up the VM or the host, but it's still not full-screen. And some distros/DEs do not automatically resize to fit within that client area, but display scroll bars instead, making it very difficult to use both OSs without a lot of manual scrolling.. Solus MATE is an example of that.
Comment Actions
After the update that was released on 4 August, this is still unresolved, but it has changed, indicating that Oracle may be working on it. Whereas before, when a VM went to full screen during a Wayland session, it would immediately lock up, and be unresponsive. Since, at full screen, it then covered the host's display, the host was also locked up, for all practical purposes.
After this update, things are different. When I take the VM to full screen, it becomes unresponsive to the mouse, however a second HOME+F keypress now returns it to its former, smaller size, exposing the host's image. So it can be toggled between full screen and smaller with the HOME+F keypress. That's different than before.
However, once it's been to full screen, any apps become unresponsive to the mouse. The windows "decorations" on the VM's VBox frame window can be clicked, and they respond, but nothing inside the client areas does. If the [X] is clicked to exit the VM, the exit dialog appears. But nothing inside the dialog has any effect, so it can't be closed that way.
Back in the host, the mouse works to change from one workspace to another, but not to do anything within the client area of any application. I could change to the workspace with Thunderbird, for example, but that app was totally unresponsive to the mouse.
Meanwhile, inside the VirtualBox manager, in the list of VMs, that one is listed as "Paused." I've never seen that before. And the manager is locked up, like all the other applications.
I've tried changing to a Logitech wireless mouse by inserting its dongle, but it works just the same as my usual Bluetooth mouse. And the Bluetooth manager shows that the mouse and keyboard are connected, so I went back to using that mouse.
To check on the keyboard, I moved to the workspace containing Terminology and was able to use it normally. I typed the command reboot, and when the system reappeared, everything was working normally.
Note that some of these nonresponsive symptoms may have been present originally, but with the VM's full screen image preventing access to anything beneith it, it would have been impossible to know that. The big difference today is that the VM can now be toggled between full screen and not, allowing access to other areas of the host's screen. Perhaps there, it's revealing sympoms that actually existed before, but couldn't be seen.