mirror of https://github.com/xemu-project/xemu.git
![]() The printscreen/sysrq and pause/break keys currently don't work for guests using -usbdevice keyboard when accessed through vnc with a gtk-vnc based client. The reason for this is a mismatch between gtk-vnc and qemu in how these keys should be mapped to XT keycodes. On the original IBM XT these keys behaved differently than other keys. Quoting from https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html: The keys PrtSc/SysRq and Pause/Break are special. The former produces scancode e0 2a e0 37 when no modifier key is pressed simultaneously, e0 37 together with Shift or Ctrl, but 54 together with (left or right) Alt. (And one gets the expected sequences upon release. But see below.) The latter produces scancode sequence e1 1d 45 e1 9d c5 when pressed (without modifier) and nothing at all upon release. However, together with (left or right) Ctrl, one gets e0 46 e0 c6, and again nothing at release. It does not repeat. Gtk-vnc supports the 'QEMU Extended Key Event Message' RFB extension to send raw XT keycodes directly to qemu, but the specification doesn't explicitly specify how to map such long/complicated keycode sequences. From the spec (https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message) The keycode is the XT keycode that produced the keysym. An XT keycode is an XT make scancode sequence encoded to fit in a single U32 quantity. Single byte XT scancodes with a byte value less than 0x7f are encoded as is. 2-byte XT scancodes whose first byte is 0xe0 and second byte is less than 0x7f are encoded with the high bit of the first byte set hid.c currently expects the keycode sequence with shift/ctl for sysrq (e0 37 -> 0xb7 in RFB), whereas gtk-vnc uses the sequence with alt (0x54). Likewise, hid.c expects the code without modifiers (e1 1d 45 -> 0xc5 in RFB), whereas gtk-vnc sends the keycode sequence with ctrl for pause (e0 46 -> 0xc6 in RFB). See keymaps.cvs in gtk-vnc for the mapping used: https://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv#n150 Now, it isn't obvious to me which sequence is really "right", but as the 0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems like the pragmatic solution to me. The USB HID keyboard boot protocol used by hid.c doesn't have any other mapping applicable to these keys. The other guest keyboard interfaces (ps/2, virtio, ..) are not affected, because they handle these keys differently. Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Message-id: 20161028145132.1702-1-peter@korsgaard.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> |
||
---|---|---|
audio | ||
backends | ||
block | ||
bsd-user | ||
contrib | ||
crypto | ||
default-configs | ||
disas | ||
docs | ||
dtc@65cc4d2748 | ||
fpu | ||
fsdev | ||
gdb-xml | ||
hw | ||
include | ||
io | ||
libdecnumber | ||
linux-headers | ||
linux-user | ||
migration | ||
nbd | ||
net | ||
pc-bios | ||
pixman@87eea99e44 | ||
po | ||
qapi | ||
qga | ||
qobject | ||
qom | ||
replay | ||
roms | ||
scripts | ||
slirp | ||
stubs | ||
target-alpha | ||
target-arm | ||
target-cris | ||
target-i386 | ||
target-lm32 | ||
target-m68k | ||
target-microblaze | ||
target-mips | ||
target-moxie | ||
target-openrisc | ||
target-ppc | ||
target-s390x | ||
target-sh4 | ||
target-sparc | ||
target-tilegx | ||
target-tricore | ||
target-unicore32 | ||
target-xtensa | ||
tcg | ||
tests | ||
trace | ||
ui | ||
util | ||
.dir-locals.el | ||
.exrc | ||
.gitignore | ||
.gitmodules | ||
.mailmap | ||
.travis.yml | ||
CODING_STYLE | ||
COPYING | ||
COPYING.LIB | ||
Changelog | ||
HACKING | ||
LICENSE | ||
MAINTAINERS | ||
Makefile | ||
Makefile.objs | ||
Makefile.target | ||
README | ||
VERSION | ||
accel.c | ||
aio-posix.c | ||
aio-win32.c | ||
arch_init.c | ||
async.c | ||
atomic_template.h | ||
balloon.c | ||
block.c | ||
blockdev-nbd.c | ||
blockdev.c | ||
blockjob.c | ||
bootdevice.c | ||
bt-host.c | ||
bt-vhci.c | ||
configure | ||
cpu-exec-common.c | ||
cpu-exec.c | ||
cpus-common.c | ||
cpus.c | ||
cputlb.c | ||
device-hotplug.c | ||
device_tree.c | ||
disas.c | ||
dma-helpers.c | ||
dump.c | ||
exec.c | ||
gdbstub.c | ||
hmp-commands-info.hx | ||
hmp-commands.hx | ||
hmp.c | ||
hmp.h | ||
iohandler.c | ||
ioport.c | ||
iothread.c | ||
kvm-all.c | ||
kvm-stub.c | ||
main-loop.c | ||
memory.c | ||
memory_mapping.c | ||
module-common.c | ||
monitor.c | ||
numa.c | ||
os-posix.c | ||
os-win32.c | ||
page_cache.c | ||
qapi-schema.json | ||
qdev-monitor.c | ||
qdict-test-data.txt | ||
qemu-bridge-helper.c | ||
qemu-char.c | ||
qemu-doc.texi | ||
qemu-ga.texi | ||
qemu-img-cmds.hx | ||
qemu-img.c | ||
qemu-img.texi | ||
qemu-io-cmds.c | ||
qemu-io.c | ||
qemu-nbd.c | ||
qemu-nbd.texi | ||
qemu-option-trace.texi | ||
qemu-options-wrapper.h | ||
qemu-options.h | ||
qemu-options.hx | ||
qemu-seccomp.c | ||
qemu-tech.texi | ||
qemu-timer.c | ||
qemu.nsi | ||
qemu.sasl | ||
qmp.c | ||
qtest.c | ||
replication.c | ||
replication.h | ||
rules.mak | ||
softmmu_template.h | ||
spice-qemu-char.c | ||
tcg-runtime.c | ||
tci.c | ||
thread-pool.c | ||
thunk.c | ||
tpm.c | ||
trace-events | ||
translate-all.c | ||
translate-all.h | ||
translate-common.c | ||
user-exec.c | ||
version.rc | ||
vl.c | ||
xen-common-stub.c | ||
xen-common.c | ||
xen-hvm-stub.c | ||
xen-hvm.c | ||
xen-mapcache.c |
README
QEMU README =========== QEMU is a generic and open source machine & userspace emulator and virtualizer. QEMU is capable of emulating a complete machine in software without any need for hardware virtualization support. By using dynamic translation, it achieves very good performance. QEMU can also integrate with the Xen and KVM hypervisors to provide emulated hardware while allowing the hypervisor to manage the CPU. With hypervisor support, QEMU can achieve near native performance for CPUs. When QEMU emulates CPUs directly it is capable of running operating systems made for one machine (e.g. an ARMv7 board) on a different machine (e.g. an x86_64 PC board). QEMU is also capable of providing userspace API virtualization for Linux and BSD kernel interfaces. This allows binaries compiled against one architecture ABI (e.g. the Linux PPC64 ABI) to be run on a host using a different architecture ABI (e.g. the Linux x86_64 ABI). This does not involve any hardware emulation, simply CPU and syscall emulation. QEMU aims to fit into a variety of use cases. It can be invoked directly by users wishing to have full control over its behaviour and settings. It also aims to facilitate integration into higher level management layers, by providing a stable command line interface and monitor API. It is commonly invoked indirectly via the libvirt library when using open source applications such as oVirt, OpenStack and virt-manager. QEMU as a whole is released under the GNU General Public License, version 2. For full licensing details, consult the LICENSE file. Building ======== QEMU is multi-platform software intended to be buildable on all modern Linux platforms, OS-X, Win32 (via the Mingw64 toolchain) and a variety of other UNIX targets. The simple steps to build QEMU are: mkdir build cd build ../configure make Additional information can also be found online via the QEMU website: http://qemu-project.org/Hosts/Linux http://qemu-project.org/Hosts/W32 Submitting patches ================== The QEMU source code is maintained under the GIT version control system. git clone git://git.qemu-project.org/qemu.git When submitting patches, the preferred approach is to use 'git format-patch' and/or 'git send-email' to format & send the mail to the qemu-devel@nongnu.org mailing list. All patches submitted must contain a 'Signed-off-by' line from the author. Patches should follow the guidelines set out in the HACKING and CODING_STYLE files. Additional information on submitting patches can be found online via the QEMU website http://qemu-project.org/Contribute/SubmitAPatch http://qemu-project.org/Contribute/TrivialPatches Bug reporting ============= The QEMU project uses Launchpad as its primary upstream bug tracker. Bugs found when running code built from QEMU git or upstream released sources should be reported via: https://bugs.launchpad.net/qemu/ If using QEMU via an operating system vendor pre-built binary package, it is preferable to report bugs to the vendor's own bug tracker first. If the bug is also known to affect latest upstream code, it can also be reported via launchpad. For additional information on bug reporting consult: http://qemu-project.org/Contribute/ReportABug Contact ======= The QEMU community can be contacted in a number of ways, with the two main methods being email and IRC - qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel - #qemu on irc.oftc.net Information on additional methods of contacting the community can be found online via the QEMU website: http://qemu-project.org/Contribute/StartHere -- End