Re: [Qemu-devel] [PATCH v5] cocoa.m: Add ability for user to specify mouse ungrab key

[Programmingkid]

> On Jan 31, 2018, at 4:03 AM, Gerd Hoffmann <address@hidden> wrote:
> 
>>> What about the other hotkeys?
>>> 
>>> There is fullscreen.  Ctrl-Alt-F for SDL and GTK.  Cmd-F for cocoa, but
>>> it works only if the grab is not active.
>> 
>> If has to be that way because the meta (command) key is sent to the
>> guest when the mouse grab is in effect. I actually suggest the SDL and
>> GTK interfaces send the meta (windows key on PC keyboard) key to the
>> guest when a mouse grab is in effect. This way guest operating systems
>> like Mac OS X can use keyboard shortcuts. 
> 
> Well, the modifier key changes are actually sent to the guest, but
> usually they have no effect there.
> 
> So, if you press Ctrl-Alt-F, the guest will see the keydown and keyup
> events for ctrl and alt.  It will not see the 'f', because SDL hijacks
> that.

Maybe the f could be sent to the guest directly via 
qemu_input_event_send_key_qcode().

> 
>>> Console select (Ctrl-Alt-<nr>), works for SDL and GTK.  When I read the
>>> code correctly it should work for cocoa the same way, but it doesn't
>>> work for me.  Dunno why. 
>> 
>> I know this code was broken in cocoa for a while but I made the patch
>> that fixes this problem. Console selection does work correctly using a
>> recent git version of QEMU.
> 
> Just pulled latest master and recompiled, still not working for me.
> This is sierra in a vm.

What software do you use to run the VM? It could be possible the VM software is 
interfering with the ungrab keys.

> Unrelated side note: hvf doesn't work for me too (nested on kvm).

I haven't played with this new feature yet. Maybe I will try it out one day.

> 
>>> Quit. Ctrl-Alt-Q on gtk.  Cmd-Q on cocoa, again only working without
>>> keyboard grab.  Nothing on SDL.  Just closing the window to quit works
>>> on GTK and SDL, both have a switch to turn it off.
>> 
>> I know Command-Q is the standard Macintosh keyboard short for quitting
>> an application. With GTK I would imagine it would depend on how the
>> host operating system expects applications to be built. I don't think
>> Windows and Linux have a standard keyboard shortcut for quitting an
>> application. 
> 
> On Linux Ctrl-Q seems to be common (maybe only in the gnome world).
> On Windows Alt-F4 should be standard.
> 
> Qemu picked two-modifier hot-keys (like Ctrl-Alt-Q) to avoid overlaps
> with guest hot keys, so both qemu and guest hotkeys can be used without
> having to deal with keyboard/mouse grabs all the time.
> 
>> Ok I see what you want:
>> 
>> -display 
>> gtk,hotkey-modifiers=ctrl+shift,hotkey-grab=f12,hotkey-fullscreen=f11
>> 
>> -display cocoa,hotkey-modifiers=Command,hotkey-grab=f13,hotkey-fullscreen=f14
> 
> I think that would be "super" not "Command" because that is the name for
> the key in the pc world so this is what the key got as QKeyCode name.
> 
>> I assume hotkey-modifiers is used to set the meta key.
> 
> Yes.
> 
>> Is hotkey-grab the key used to ungrab the mouse?
> 
> Yes (keyboard grab too).
> 
>> If it is shouldn't it be called hotkey-ungrab?
> 
> Good question.  On gtk/sdl Ctrl-Alt-G actually toggles the grab, i.e.
> can do *both* grab and ungrab.  But I expect most users use it for
> ungrab only, due to mouse clicks activating the grab too.
> 
>>>> Example usage:  -ungrab home
>>>>            -ungrab shift-ctrl
>>> 
>>> Modifier-only hotkeys are tricky with gtk (doable, but no support for
>>> that in the toolkit).
>>> 
>>>>            -ungrab ctrl-x
>>>>            -ungrab pgup-pgdn
>>> 
>>> Really?  Two non-modifier keys?
>> Yes. The ungrab sequence could be a-b-c and still allow these keys to be 
>> used in the guest.
>> 
>>> How is that implemented?  Do you queue
>>> up the pgup keypress, waiting to see whenever pgdn is pressed too, then
>>> only in case that didn't happen forward the queued pgup key to the guest?
>> 
>> Basically there is a array that acts as a check list. It checks off
>> keys that belong to the ungrab sequence as they are detected. Once a
>> non-ungrab key is detected, the check list is cleared. If all the
>> ungrab keys are detected the ungrab code is executed. This only
>> happens on keyup events. That way if Control-ALT were the ungrab keys,
>> sending Control-ALT-Delete to the guest is still possible because
>> these are the keys detected on the keyup event. The Delete key would
>> have cleared the check list. Daniel Berrange is the one I can thank
>> for this idea. He might be able to explain it better than me.
> 
> Hmm, ok.
> 
> Doing the same for gtk would basically imply to not use any toolkit
> support for hotkeys ...
> 
> It'll also become more difficuilt if we use that for multiple hotkeys.
> 
> But possibly we can share the code across all UIs, now that keycodemapdb
> is used by qemu.  So first translate the keycode from the UI toolkit to
> a QKeyCode, then feed that into shared hotkey detection code.

Sounds like a good idea. I will be more than happy to help. My cocoa code
uses sets to implement keeping track of key presses. A set is a collection of 
data 
that only allows for unique values. So no two items in a set can be the same
value. My patch uses cocoa's NSSet so the shared code would probably not be
able to use it. I don't currently know of an implementation of a set that is
in C and available for us to use, so we may have to implement it ourselves. 

> 
>>> I think we should limit ourself to key combinations which have one
>>> non-modifier key and optionally one or more modifier keys.  That
>>> should be supportable in all user interfaces we have.  Except
>>> curses, modifier key handling in unix terminals is a completely
>>> different world ...
>>> 
>>> When it comes to defining hotkeys I see basically two possible ways
>>> to do it:
>>> 
>>> (1) Have a fixed (set of) modifier keys for all hot keys, i.e.
>>> something like this:
>>> 
>>>        -display 
>>> gtk,hotkey-modifiers=ctrl+shift,hotkey-grab=f12,hotkey-fullscreen=f11
>>> 
>>> (2) Allow complete freedom when defining hotkeys, i.e.
>>> 
>>>        -display gtk,hotkey-grab=shift+f12,hotkey-fullscreen=ctrl+f11
>>> 
>>> Variant (1) provides a simple way to use other modifiers for all
>>> hotkeys, simliar to the existing -alt-grab switch.  I also expect it
>>> is easier to implement.
>> 
>> Choice 2 sounds really nice. It does give the user total freedom to
>> customize QEMU as seen fit.
> 
> But on the other hand switching all hotkeys from ctrl-alt-<key> to
> ctrl-shift-<key> is alot of work with choice (2) because you have to
> redefine all hotkeys.  With choice (1) it is a simple
> "hotkey-modifiers=ctrl+shift".
> 
> So both approaches have their specific advantages ...
> 
>>> Another question is whenever we want allow defining different
>>> hotkeys for the same thing.  So fullscreen could have both F11
>>> (which is a common hotkey in various apps, for example firefox) and
>>> Ctrl-Alt-F.  Might be useful, but also makes the implementation more
>>> complex.
>> 
>> Assigning two different keyboard shortcuts to the same feature might
>> be problematic.  Keeping things to one keyboard shortcut is probably
>> the simple thing to do.
> 
> Yes.  I also think the added complexity needed isn't worth the benefits.
> 
> cheers,
>  Gerd
>