Re: [vbox-dev] [PATCH][resend] Fix shortcuts like alt-tab not working under [X]wayland
Hi, On 6/10/20 9:14 AM, Frank Batschulat wrote: FYI, this has been fixed in Trunk revision r138534 and has been backported to 6.1.X revision r138535 and will be included in the next releases. The fix is already included in the test builds for Trunk and 6.1.X containing above revisions: https://www.virtualbox.org/wiki/Testbuilds That is great, thank you. Regards, Hans On Tue, 09 Jun 2020 14:14:20 +0200, Frank Batschulat wrote: Thanks Hans, I have filed the following bug for tracking this and I will see I test it and merge it asap into Trunk and backport to 6.1.X Ticket #19650 XWayland: Fix shortcuts like alt-tab not working under [X]wayland https://www.virtualbox.org/ticket/19650 cheers frankB On Mon, 08 Jun 2020 17:18:57 +0200, Hans de Goede wrote: Hi, Note this is a resend since my first submission was ignored. This patch makes virtualbox work much better (things like alt+tab will work in the VM) when run inside a Wayland session. Can we please get this merged? The attached patch tackles a long-standing issue when running VirtualBox under [X]wayland. By default keyboard-grabs are denied to X11 apps under Xwayland, this causes e.g. alt-tab to not be send to the VM, but to go to the host window-environment. The attached patch modifies VirtualBox to send a special ClientMessage which lets mutter knows that VirtualBox works properly with emulated grabs and that they should be allowed. As usual, the patch is released under the MIT license. Regards, Hans ___ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev
Re: [vbox-dev] [ PATCH] Fix crash on startup under Wayland
Hi,
On 6/8/20 5:11 PM, Sérgio Basto wrote:
Hi,
On Mon, 2020-06-08 at 10:50 +0200, Frank Batschulat wrote:
This has been fixed in the new release 6.1.10
Can you please show me where is the code in SVN ?
Unfortunately seems that svn source code is not updated for 2 months (
https://www.virtualbox.org/browser/vbox/ ) so it is more difficult to
follow the modifications .
There is a new RTEnvSet call in this bit:
#ifdef VBOX_WS_X11
/* Make sure multi-threaded environment is safe: */
if (!MakeSureMultiThreadingIsSafe())
break;
/* Force using Qt platform module 'xcb', we have X11 specific code: */
RTEnvSet("QT_QPA_PLATFORM", "xcb");
#endif /* VBOX_WS_X11 */
of src/VBox/Frontends/VirtualBox/src/main.cpp
Regards,
Hans
On Wed, 20 May 2020 12:47:47 +0200, Frank Batschulat
wrote:
Testbuilds with the fix can be downloaded now:
for Trunk:
https://www.virtualbox.org/download/testcase/VirtualBox-6.1.97-138092-Linux_amd64.run
for 6.1.X:
https://www.virtualbox.org/download/testcase/VirtualBox-6.1.9-138068-Linux_amd64.run
or directly from: https://www.virtualbox.org/wiki/Testbuilds
for Trunk any Linux 64-bit .run installer with build >= r138057 and
for
6.1.X any build >= r138068
On Thu, 14 May 2020 14:43:01 +0200, Frank Batschulat
wrote:
Hans, I have filed the following bug to track this:
[Oracle VM VirtualBox] #19583: GUI crashes when using Qt on
Xwayland
sessions
https://www.virtualbox.org/ticket/19583
the possible fix for this is still being discussed internally.
On Tue, 07 Apr 2020 14:00:47 +0200, Hans de Goede <
hdego...@redhat.com>
wrote:
Hi,
I noticed that with a default Fedora 32 workstation install
(default
GNOME3 on
Wayland session) VirtualBox crashes immediately at startup.
The
problem is that
QT5 now defaults to the Wayland backend and VirtualBox assumes
the X11
backend
is used and makes a bunch of unchecked X11 calls which cause
NULL
pointer derefs.
The attached patch is a simple fix which fixes this by setting
the QT
backend
back to X11.
As usual, the patch is released under the MIT license.
Regards,
Hans
___
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
[vbox-dev] [PATCH][resend] Fix shortcuts like alt-tab not working under [X]wayland
Hi,
Note this is a resend since my first submission was ignored. This patch
makes virtualbox work much better (things like alt+tab will work in the VM)
when run inside a Wayland session. Can we please get this merged?
The attached patch tackles a long-standing issue when running VirtualBox
under [X]wayland. By default keyboard-grabs are denied to X11 apps under
Xwayland, this causes e.g. alt-tab to not be send to the VM, but to go
to the host window-environment.
The attached patch modifies VirtualBox to send a special ClientMessage
which lets mutter knows that VirtualBox works properly with emulated
grabs and that they should be allowed.
As usual, the patch is released under the MIT license.
Regards,
Hans
diff -up VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.cpp~ VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.cpp
--- VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.cpp~ 2020-02-18 18:19:59.0 +0100
+++ VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.cpp 2020-04-06 13:30:21.274027340 +0200
@@ -2203,6 +2204,17 @@ void UICommon::setWMClass(QWidget *pWidg
XSetClassHint(QX11Info::display(), pWidget->window()->winId(), );
}
+/* static */
+void UICommon::setXwaylandMayGrabKeyboardFlag(QWidget *pWidget)
+{
+/* Tell the WM we are well behaved wrt Xwayland keyboard-grabs. This will
+ * make the WM turn our grab into a Wayland shortcut inhibition request,
+ * so that e.g. alt+tab will get send to the VM instead of moving the
+ * focus away from the VM. */
+XXSendClientMessage(QX11Info::display(), pWidget->window()->winId(),
+"_XWAYLAND_MAY_GRAB_KEYBOARD", 1);
+}
+
#endif /* VBOX_WS_X11 */
/* static */
diff -up VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.h~ VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.h
--- VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.h~ 2020-02-18 18:19:59.0 +0100
+++ VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/globals/UICommon.h 2020-04-06 13:30:20.345012390 +0200
@@ -416,6 +416,8 @@ public:
/** Assigns WM_CLASS property for passed @a pWidget. */
static void setWMClass(QWidget *pWidget, const QString , const QString );
+/** Tell the WM the passed @a pWidget window is well behaved wrt XWayland keyboard-grabs. */
+static void setXwaylandMayGrabKeyboardFlag(QWidget *pWidget);
#endif /* VBOX_WS_X11 */
/** Assigns minimum @a pSpinBox to correspond to @a cCount digits. */
diff -up VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/runtime/UIMachineWindow.cpp~ VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/runtime/UIMachineWindow.cpp
--- VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/runtime/UIMachineWindow.cpp~ 2020-04-06 13:18:46.0 +0200
+++ VirtualBox-6.1.4/src/VBox/Frontends/VirtualBox/src/runtime/UIMachineWindow.cpp 2020-04-06 13:25:52.235673962 +0200
@@ -135,6 +135,8 @@ void UIMachineWindow::prepare()
strWindowName = QString("VirtualBox Machine UUID: %1").arg(uiCommon().managedVMUuid().toString());
/* Assign WM_CLASS property: */
UICommon::setWMClass(this, strWindowName, strWindowClass);
+/* Tell the WM we are well behaved wrt Xwayland keyboard-grabs: */
+UICommon::setXwaylandMayGrabKeyboardFlag(this);
#endif
}
___
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
[vbox-dev] Removing suid root bit from VBoxDRMClient
Hi All, While looking into upgrading the Fedora virtualbox-guest-additions packages to 6.0.10 I noticed that the "VBoxClient --vmsvga-x11" call in VBoxClient-all has been replaced with "VBoxClient --vmsvga" and that that one will either behave as the old --vmsvga-x11 version (when running under a X11 session) or it will start /usr/bin/VBoxDRMClient. I added /usr/bin/VBoxDRMClient to the Fedora packages, but after that resizing of a GNOME3 as Wayland-compositor session inside the guest still did not work. The issue seems to be that /usr/bin/VBoxDRMClient needs more rights, I guess that the upstream version of the guest-additions installs it suid root ? That is not necessary and since Fedora ships virtualbox-guest-additions as part of the default workstation install we would like to avoid adding another suid root binary to the default install. Instead I've written a udev rule + systemd service to replace the "VBoxClient --vmsvga" call inside VBoxClient-all. These config files will start /usr/bin/VBoxDRMClient when running inside a VBox VM with VMSVGA graphics. Note this will now run independent of the type of session (X11 or Wayland) running inside the VM. This means that X11 sessions now also use VBoxDRMClient rather then VBoxClient --vmsvga-x11 for resizing. This works fine and if upstream adopts this, then the VBoxClient --vmsvga-x11 can be dropped. The udev rule and systemd file can be found here. Feel free to use these under the MIT license: https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/VirtualBox-60-vboxguest.rules https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/vboxclient.service Regards, Hans ___ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev
Re: [vbox-dev] malinline vboxsf vs bundled vboxsf mount options differences (was Removing suid root bit from VBoxDRMClient)
Hi Frank,
On 6/8/20 7:44 PM, Frank Batschulat wrote:
Thanks Hans, but right now we have a higher priority problem with fedora 32,
that is we cannot get our vboxsf kernel module loaded anymore when we install
our GAs because the Linux vboxsf kernel module is sticking and the only one
getting loaded
even though the Fedora specific guest additions you mentioned below have been
uninstalled.
Also the Linux kernel vboxsf kernel module is incompatible with
our userland commands, our userland cannot talk to your vboxsf kernel module
anymore.
investigating and fixing these beauty currently has a higher priority for us.
I'm sorry that this is causing problems for you. When we discussed merging
a version of vboxsf modified to match the upstream kernel coding conventions
into the mainline kernel this was discussed and back then we (1) agreed that
the VirtualBox bundled version of vboxsf would also move to using the new option
string based mount parameters, which would allow you to completely drop
mount.vboxsf from the Linux guest-additions. I still think that that is the
best way forward.
Note that the mainline kernel version checks for mount.vboxsf using the
old binary options struct:
if (options && options[0] == VBSF_MOUNT_SIGNATURE_BYTE_0 &&
options[1] == VBSF_MOUNT_SIGNATURE_BYTE_1 &&
options[2] == VBSF_MOUNT_SIGNATURE_BYTE_2 &&
options[3] == VBSF_MOUNT_SIGNATURE_BYTE_3) {
vbg_err("vboxsf: Old binary mount data not supported, remove
obsolete mount.vboxsf and/or update your VBoxService.\n");
return -EINVAL;
}
(the error text is based on the agreement we had that the bundled vboxsf
would move to the new mount format too).
So you could first try the old binary options struct and if you then get
-EINVAL, try again with an options string, or you could do it the other
way around. You need to change this in both mount.vboxsf and the
VBoxService code for automatically mounting shared folders marked for
auto-marking.
In the Fedora packages we simply do not package mount.vboxsf and we have
a patch for the latter here:
https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/0001-VBoxServiceAutoMount-Change-Linux-mount-code-to-use-.patch
Note this patch blindly moves to using the new string based format,
but it should help as a start with making the utils support both
formats.
If you decide to go with trying the old binary mount options first then
I can modify the error message to make it less "scary", but ideally
the bundled vboxsf version would also move to using string based mount
options. As said that will also allow dropping your own special mount.vboxsf
binary.
1) Me and various VirtualBox devs, I need to dig into my mail archive if
you want more details.
Regards,
Hans
p.s.
Somewhat related, since the Fedora kernel now ships with all necessary kernel
modules for fully support all guest-addition features; and since Fedora
also has the guest-additions packages and we are doing a good job of keeping
those up2date with the latest upstream releases. I'm wondering why bother
with having upstream provided guest-additions for newer Fedora versions at
all? Would it not be better to have the huest-additions installer detects
this is a new enough Fedora and have it tell the user that the OS already
comes with the latest guest-additions (and maybe run a
"dnf update virtualbox-guest-additions") ?
For any guest-additions on Fedora bug-reports, which are not reproducable
on say the latest Ubuntu, you could then also simply point people to
bugzilla.redhat.com and then we can pick it up.
I think that only having one version would lower both our support
workloads ?
I would also welcome you directly contributing to the Fedora pkgs.
We use a gitforge based workflow, where you can clone the repo
containing our packaging bits:
https://src.fedoraproject.org/rpms/virtualbox-guest-additions
And then submit a pull-req with any changes. I would be happy to accept
pull-requests from you for this. And once you've shown that you
know the workflow and packaging rules I would be happy to give you
direct commit rights.
On Mon, 08 Jun 2020 17:46:58 +0200, Hans de Goede wrote:
Hi All,
While looking into upgrading the Fedora virtualbox-guest-additions packages to
6.0.10
I noticed that the "VBoxClient --vmsvga-x11" call in VBoxClient-all has been
replaced
with "VBoxClient --vmsvga" and that that one will either behave as the old
--vmsvga-x11
version (when running under a X11 session) or it will start
/usr/bin/VBoxDRMClient.
I added /usr/bin/VBoxDRMClient to the Fedora packages, but after that resizing
of
a GNOME3 as Wayland-compositor session inside the guest still did not work.
The issue seems to be that /usr/bin/VBoxDRMClient needs more rights, I guess
that
the upstream version of t
