[PATCH v2] qapi/migration: Fix examples document wrong field name for arguments
The examples for the snapshot-* and calc-dirty-rate commands document
that arguments for the commands are passed in a 'data' field.
This is wrong, passing them in a "data" field results in
the error:
{"error": {"class": "GenericError", "desc": "QMP input member 'data'
is unexpected"}}
Arguments are expected to be passed in an field called "arguments".
Replace "data" with "arguments" in the snapshot-* and calc-dirty-rate
command examples.
Signed-off-by: Fabian Holler
---
v2:
- adapted to Markus Armbruster's suggestions:
- fix same issue in calc-dirty-rate example
- improve commit message
v1:
https://lists.nongnu.org/archive/html/qemu-devel/2022-02/msg04818.html
---
qapi/migration.json | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/qapi/migration.json b/qapi/migration.json
index 5975a0e104..18e2610e88 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1843,8 +1843,8 @@
# Since: 5.2
#
# Example:
-# {"command": "calc-dirty-rate", "data": {"calc-time": 1,
-# 'sample-pages': 512} }
+# {"command": "calc-dirty-rate", "arguments": {"calc-time": 1,
+#'sample-pages': 512} }
#
##
{ 'command': 'calc-dirty-rate', 'data': {'calc-time': 'int64',
@@ -1888,7 +1888,7 @@
# Example:
#
# -> { "execute": "snapshot-save",
-# "data": {
+# "arguments": {
# "job-id": "snapsave0",
# "tag": "my-snap",
# "vmstate": "disk0",
@@ -1949,7 +1949,7 @@
# Example:
#
# -> { "execute": "snapshot-load",
-# "data": {
+# "arguments": {
# "job-id": "snapload0",
# "tag": "my-snap",
# "vmstate": "disk0",
@@ -2002,7 +2002,7 @@
# Example:
#
# -> { "execute": "snapshot-delete",
-# "data": {
+# "arguments": {
# "job-id": "snapdelete0",
# "tag": "my-snap",
# "devices": ["disk0", "disk1"]
--
2.35.1
[PATCH] schemas: fix: wrong field name 'data' in client snapshot msg examples
The examples for the snapshot-* commands documented that arguments for
the commands must be passed in a 'data' field.
This is wrong, passing them in a "data" field results in
the error:
{"error": {"class": "GenericError", "desc": "QMP input member 'data'
is unexpected"}}
Arguments are expected to be passed in an field called "arguments".
Replace "data" with "arguments" in the snapshot-* command examples.
Signed-off-by: Fabian Holler
---
qapi/migration.json | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/qapi/migration.json b/qapi/migration.json
index 5975a0e104..1c6296897d 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1888,7 +1888,7 @@
# Example:
#
# -> { "execute": "snapshot-save",
-# "data": {
+# "arguments": {
# "job-id": "snapsave0",
# "tag": "my-snap",
# "vmstate": "disk0",
@@ -1949,7 +1949,7 @@
# Example:
#
# -> { "execute": "snapshot-load",
-# "data": {
+# "arguments": {
# "job-id": "snapload0",
# "tag": "my-snap",
# "vmstate": "disk0",
@@ -2002,7 +2002,7 @@
# Example:
#
# -> { "execute": "snapshot-delete",
-# "data": {
+# "arguments": {
# "job-id": "snapdelete0",
# "tag": "my-snap",
# "devices": ["disk0", "disk1"]
--
2.35.1
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Howdy Erik, On Tue, May 29, 2012 at 09:22:02PM +0200, Erik Rull wrote: Fabian Holler wrote: I just want to route all keypresses to the guest without interfering with the native QEMU key layout. Is that possible? Yes, if you start kvm without the -k option and use a linux VNC client that supports RFB extended key events (eg gtk-vnc, tigervnc). With the extension the keyboard layout only depends on the OS settings in the VM. I tried tigervnc and tightvnc for Windows - which both advertise the feature on their website I can't find anything on the tightvnc webpage about QEMU extended key events. My information about tigervnc was wrong. Tigervnc doesn't implemented the extended key events. Its problematic in java because you can't get the original key codes in the JVM. There is this tigervnc fork which adds extended key events: https://github.com/jakobadam/vnc But it only sends the code for that key that triggers the character on a keyboard with danish layout. :) - same issues as I have with UltraVNC - no AltGr combinations and no Umlaute available. I need a Windows VNC client that can handle that - do you know a vnc client that can do that? No, sorry :-) How does the QEMU VNC server receive the key presses? In the same manner as the direct way does by getting scancodes or via real characters? http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ http://berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/ Really interesting - Linux works, Windows doesn't :-( Also when using a Linux remote X-Windows (via SSH tunnel) on my Windows PC it works - only the plain Windows VNC client corrupts the keypresses Seems that no VNC client exists that sends the Windows virtual key code as RFB/VNC key code to the VNC server. regards Fabian
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hello Erik, I'm experiencing the same issues. When using the QEMU VNC server (which I would prefer to Remote Desktop or a VNC server installed on the guest) I get problems when pressing special character keys on the remote keyboard. QEMU reports on the console: Warning: no scancode found for keysym 180 or Warning: no scancode found for keysym 223 I just want to route all keypresses to the guest without interfering with the native QEMU key layout. Is that possible? Yes, if you start kvm without the -k option and use a linux VNC client that supports RFB extended key events (eg gtk-vnc, tigervnc). With the extension the keyboard layout only depends on the OS settings in the VM. How does the QEMU VNC server receive the key presses? In the same manner as the direct way does by getting scancodes or via real characters? http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ http://berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/ regards Fabian
Re: [Qemu-devel] Interpretation of key symbols in QEMU's VNC server
Hello Gerhard, On Thu, Mar 08, 2012 at 06:54:46AM +0100, Gerhard Wiesinger wrote: I'm having also isssues with german keymappings. E.g. Under DOS when pressing shift keys will always be uppercase. Also ALT-GR doesn't work. If I start qemu with -k de and the layout in the Client OS is also set to de layout I can freely switch the layout in the VM and it works as expected (also key presses with shift alt-gr). It also works if I'm using gtk-vnc which implements the QEMU extended keyboard events. I only tested it with Linux VMs. I already discussed such issues here: https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg02225.html https://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00138.html Thanks for the links. I think our problem is a little bit different: We provide a VNC console for our customers. The customers use different keyboard mappings and they expect that the same character in the VNC window appears like on their local editor, if they press the same key. Thats not what QEMU does, because it emulates a keyboard controller and the VNC keysymbols must be converted to scancodes. The character that shows up in the VNC window further depends on the keyboard layout in the VM. So we are trying to minimize the problems with the vnc console that a customer could have. Our currents ideas: * Let the customer choose the -k parameter value for their VMs. - Keyboard layout change needs VM restart. - Wrong characters shows up if the customer uses a different layout on their Client OS. Not even all ASCII characters work, because on different layouts different meta-keys (shift, alt-gr) presses are necessary. It could be handled if QEMUs VNC server would interpret the received Keysymbol and add/remove additional needed keypresses. But QEMU doesn't do this. It also would be an ugly hack if u expect that it should behave like a virtualized keyboard controller. (Idea from my first post) - Sometimes administrators which different Keyboard layouts have to use the same console = leads to problems * Use a VNC client which supports QEMUs extended keyboard events. - Customer didn't expect that he have to choose the keyboard layout in the VM. If he has a different layout set in the VM he wonders why different characters show up than on their local applications.. - Works with gtk-vnc, but we need an OS independent Java Applet. The JVM didn't know the keycodes so we would have to translate the java keysymbols to keycodes. For this we have to know the keyboard layout on the Client OS, which afaik we also can't detect in the JVM. We could guess the keyboard layout on the basis of the locale setting but this can also led to new problems. o Best idea currently: Let the user choose in the applet their local keyboard layout, use this for conversion and try to inform them that the layout in the VM has to been choosen. I'm glad for every hint for a good solution. BTW: Sorry for the duplicate posts. I was wondering why I didn't receive my own ML post. It turns out that gmail is moving own ML posts directly to the archive. :) regards Fabian
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hello Philipp, thanks for your answer. On Thu, Mar 08, 2012 at 09:24:13PM +0100, Philipp Hahn wrote: On Wednesday 07 March 2012 11:53:57 Fabian Holler wrote: I'm not sure if I found a bug in QEMU's VNC keyboard layout mapping or if it's a general problem in the implemented VNC server: Daniel P. Berrangé has written some very good blog entries about the VNC problem: http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ They're quiet technical, but after reading them I at least concluded that VNC is normally just broken. I already discovered Berrangès articles, helped me very lot to understand the problem. I recommend using virt-viewer, with which I have mostly no such problems. Ah, never heard of it, it seems also be gtk-vnc based. I already tried gtk-vnc and it works but we need a Web based solution for our customers. I found Java VNC (http://www.jdams.org/java-vnc), which also sends the QEMU extended key event messages (based on TigerVNC). But in the JVM is the same old problem that the scan code/key code isn't known. So our current plan is to let the customer choose his local keyboard layout in the applet and recover the key code for the key symbol (+ add/remove if needed metakey events like shift) on the client. Similar like QEMU's -k option, but on the client-side + interpretation. We will only can support a limited number of keyboard layouts but changing the layout without restarting QEMU will be possible. :-) regards Fabian
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hello Anthony, On Thu, Mar 08, 2012 at 03:30:18PM -0600, Anthony Liguori wrote: On 03/07/2012 04:53 AM, Fabian Holler wrote: Hello, I'm not sure if I found a bug in QEMU's VNC keyboard layout mapping or if it's a general problem in the implemented VNC server: Scenario: QEMU started with: -k de Keyboard layout in VM: de Keyboard layout from Client OS: us What i expect: I type the '/' character on the Client OS (key left from the right-shift-key) on US layout. Keysymbol '/' is send over VNC to the QEMU. QEMU lookup in the de keyboard mapping table for the character '/' and should find the scancodes for the keys shift+'7'. The Scancodes for shift and '7' This does not exist. There is no such thing as Scancodes for shift and '7'. Instead, what's sent to the Client OS is literally, the key at the fourth column, second row. Yes, I know. What i actually meant was: with the knowledge of the used keyboard layout and the key symbol QEMU could figure out that it has to send scan codes for the keys that are labeled SHIFT 7 on a keyboard with DE layout. Afaik QEMU does this already for the 7 labeled key. But it doesn't remove/adds additional needed metakey presses like eg Shift. Or I'm wrong? The idea was to add these interpretation to also add/remove additional metakey scancodes for the VM if needed. There's really nothing that can be done about this. The way gtk-vnc fixes this is by obtaining the actual scancode from the user's keyboard. But you can't get this in Java in an applet AFAIK. The same should work in a Java Applet but you also have to figure out the used keyboard layout and handle metakeys. regards Fabian
[Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hello, I'm not sure if I found a bug in QEMU's VNC keyboard layout mapping or if it's a general problem in the implemented VNC server: Scenario: QEMU started with: -k de Keyboard layout in VM: de Keyboard layout from Client OS: us What i expect: I type the '/' character on the Client OS (key left from the right-shift-key) on US layout. Keysymbol '/' is send over VNC to the QEMU. QEMU lookup in the de keyboard mapping table for the character '/' and should find the scancodes for the keys shift+'7'. The Scancodes for shift and '7' are send to the VM's emulated keyboard controller and the '/' appears in the VM. But what actually happens is that the '7' character shows up in the VM. It seems that QEMU misses to also generate the Shift Scancode. Is this a general problem in the VNC server implementation? So that an interpretation (http://tools.ietf.org/html/rfc6143#section-7.5.4) of the received keysymbols to add eg an additional shift keypress never happens? If yes, would a QEMU patch that adds keysymbol interpretation have a chance to be merged into upstream? Or are there reasons that it isn't a good idea to interpret the keysymbols for the scancode conversion? regards Fabian
[Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hello, I'm not sure if I found a bug in QEMU's VNC keyboard layout mapping or if it's a general problem in the implemented VNC server: Scenario: QEMU started with: -k de Keyboard layout in VM: de Keyboard layout from Client OS: us What i expect: I type the '/' character on the Client OS (key left from the right-shift-key) on US layout. Keysymbol '/' is send over VNC to the QEMU. QEMU lookup in the de keyboard mapping table for the character '/' and should find the scancodes for the keys shift+'7'. The Scancodes for shift and '7' are send to the VM's emulated keyboard controller and the '/' appears in the VM. But what actually happens is that the '7' character shows up in the VM. It seems that QEMU misses to also generate the Shift Scancode. Is this a general problem in the VNC server implementation? So that an interpretation (http://tools.ietf.org/html/rfc6143#section-7.5.4) of the received keysymbols to add eg an additional shift keypress never happens? If yes would a QEMU patch that adds keysymbol interpretation have a chance to be merged in the upstream version? Or are there reasons that it isn't a good idea to interpret the keysymbols for the scancode conversion? regards Fabian
[Qemu-devel] Interpretation of key symbols in QEMU's VNC server
Hello, I'm not sure if I found a bug in QEMU's VNC keysymbol to scancode mapping or if it is a general Problem with the implemented VNC server: Scenario: QEMU started with: -k de Keyboard layout in VM: de Keyboard layout from Client OS: us What i expect: I type the '/' character on the Client OS (key left from the right-shift-key) on US layout. key symbol '/' is send over VNC to the QEMU. QEMU lookup in the de keyboard mapping table for the character '/' and should find the scancodes for the keys shift+'7'. The Scancodes for shift and '7' are send to the VM's emulated keyboard controller and the '/' appears in the VM. But what actually happens is that the '7' character shows up in the VM. It seems that QEMU misses to generates an additional Shift Scancode/Keypress. Is this a general problem in the VNC server implementation? So that an interpretation (http://tools.ietf.org/html/rfc6143#section-7.5.4) of the received key symbols to eg add an additional shift keypress isn't implemented? If yes, would a QEMU patch that adds keysymbol interpretation have a chance to be merged into upstream? Or are there reasons that it isn't a good idea to interpret the VNC keysymbols and add/remove additional needed scancodes to get the expected character on the VM? regards Fabian
