graphic: 0.933
device: 0.875
performance: 0.822
boot: 0.636
architecture: 0.590
semantic: 0.589
mistranslation: 0.566
arm: 0.559
assembly: 0.553
permissions: 0.550
peripherals: 0.488
vnc: 0.468
debug: 0.465
risc-v: 0.462
socket: 0.455
PID: 0.455
ppc: 0.421
kernel: 0.399
register: 0.357
i386: 0.255
user-level: 0.243
hypervisor: 0.235
KVM: 0.165
VMM: 0.163
virtual: 0.132
TCG: 0.130
x86: 0.129
files: 0.116
network: 0.105

GTK accelerators (including releasing input grab) don't work in keyboard layouts that utilize AltGr on Windows
Description of problem:
With a non-QWERTY (in my case, Colemak) layout active, it's not possible to ungrab input from the window using the Ctrl-Alt-G. The key combination is simply ignored, whether the G is typed using the physical key G on the keyboard or the one where it would be mapped by the keyboard layout (physical T key for Colemak). Thankfully, because of #2225, the mouse cursor isn't actually captured, which allows me to move the mouse outside the window and close QEMU from the taskbar instead.

Temporarily switching back to a QWERTY layout before the grab happens allows input to be released using the key combo. However this needs to be done before the capture as otherwise QEMU will simply intercept any shortcuts to toggle the layout.

I suspect there's some mismatch between the input grabbing code and the GTK UI, where one is using the keyboard scancode to determine when to forward the key, but the GTK UI then uses the mapped letter from the layout and fails to activate the shortcut.
Steps to reproduce:
1. Configure a non-QWERTY layout (such as Dvorak or Colemak) in the system settings
1. Launch QEMU (it's not necessary to load any guest, booting the BIOS is fine)
2. Click on the window which will automatically capture input
3. Try to release using the Ctrl-Shift-G shortcut (in either layout), which should be ignored
Additional information: