> On Jan 31, 2018, at 4:03 AM, Gerd Hoffmann <kra...@redhat.com> 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 >
