pass lid close event from guest to host

[Matei David]

On Thu, 22 Sep 2016 10:17:10 +0200
René J.V. Bertin <rjvbertin at gmail.com> wrote:

> On Wednesday September 21 2016 23:14:24 Matei David wrote:
> 
> >responsible for locking the host screen (dbus??) doesn't react to
> >that event. The fact that I see the acpi event on the host leads me
> >to believe this is not a VirtualBox problem.  
> 
> I'm tempted to think that it *is* a VirtualBox issue: in fullscreen
> mode it tries to behave as much as possible as if you're not working
> on a VM guest. It doesn't surprise me that it tries to catch
> power-related events too. I'd suggest you ask on Oracle's VirtualBox
> forum if there's a way around (like a setting to let the host handle
> these events) and if not, file a ticket with a request.

At first I thought so, too, that the guest somehow traps the ACPI
events. (I don't know about enough about those to be sure that's even
possible.)

The reaction-less question on the VBox forums is here:
https://forums.virtualbox.org/viewtopic.php?f=7&t=75700
I have since upgraded VBox and the OSes, but it's still happening.

However, acpi_listen on the host sees exactly the same lid open/close
events if the guest is in full screen (and the host doesn't lock), or
if the guest is not in full screen (and the host does lock). This
suggests that the host is behaving differently, irrespective of the
guest VM.

There is also the issue of the VBox process on the host. But why would
that process have any say in whether the screen gets locked or not? For
example, if I have mpv in full screen on the host and I close the lid,
the screen gets locked as expected.

I guess a concrete KDE question would be: What software (KDE component?)
is responsible for listening and reacting to acpi events on the host?
So, what exactly is being configured through the System Settings / Power
Management interface?

> >Is there some way to fix this in KDE? Right now the hack I have in
> >place is a custom script triggered through /etc/acpi/events . The
> >problem with doing it this way is that in certain situations the
> >session is locked twice, because the systems are independent of each
> >other.  
> 
> Can you just tell VirtualBox to drop out of fullscreen mode and then
> let the host continue processing as usual?

Yes I could. If the guest VM is windowed, the host gets locked as
usual. However, the point is that closing the lid is a very convenient
way to say, "gotta go, just lock my screen already". The other way,
there would be an extra HostKey+f in there.

> Personally I usually do this manually and then pause the guest before
> I suspend the host. Enough happens on wake-from-suspend that things
> usually go smoother if there isn't also a VM guest (which typically
> has a huge memory footprint) that tries to do those same things at
> the same time.

In general I haven't had problems with the guest VM during suspend/wake.
However, the OP is only about locking the host (on lid close), I don't
want to suspend it. I guess suspending is done through the same
interface, but I didn't even try that.

Thanks,
Matei