[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 3/3] qemu: Improve qemuMonitorJSONSendKey function



On Wed, Nov 12, 2014 at 11:50:18AM +0100, Peter Krempa wrote:
On 11/11/14 15:54, Martin Kletzander wrote:
When using modifiers with send-key, then we cannot know with what keys
those modifiers should be pressed down.  QEMU changed the order of the
release events few times and that caused few send-key command to work
differently than expected.

We already state in virsh man page that the keys sent will be sent to
the guest simultaneously and can be received in random order.  This
patch just tries improving user experience and keeping old behaviour.

Although we state this in the virsh man page, the API reference section
on the SendKey function is pretty poor. We should improve and state a
few things there I'll point out later.


Signed-off-by: Martin Kletzander <mkletzan redhat com>
---
 src/qemu/qemu_driver.c       |   4 +-
 src/qemu/qemu_monitor.c      |   6 +-
 src/qemu/qemu_monitor.h      |   3 +-
 src/qemu/qemu_monitor_json.c | 142 ++++++++++++++++++++++++++++++++++++-------
 src/qemu/qemu_monitor_json.h |   3 +-
 tests/qemumonitorjsontest.c  |  72 ++++++++++++++++++++--
 6 files changed, 198 insertions(+), 32 deletions(-)


diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 91a7aba..cd8a38b 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c

@@ -3938,52 +3939,151 @@ int qemuMonitorJSONInjectNMI(qemuMonitorPtr mon)
     return ret;
 }

+static int
+qemuMonitorJSONAppendKey(virJSONValuePtr list,
+                         unsigned int keycode,
+                         bool use_events,
+                         bool down)
+{
+    virJSONValuePtr data = NULL;
+    virJSONValuePtr event = NULL;
+    virJSONValuePtr key = NULL;
+
+    if (!(key = virJSONValueNewObject()))
+        goto cleanup;
+
+    /* Union KeyValue has two types, use the generic one */
+    if (virJSONValueObjectAppendString(key, "type", "number") < 0)
+        goto cleanup;
+
+    /* with the keycode */
+    if (virJSONValueObjectAppendNumberInt(key, "data", keycode) < 0)
+        goto cleanup;
+
+    if (!use_events) {
+        if (virJSONValueArrayAppend(list, key) < 0)
+            goto cleanup;
+
+        /* That's all if we're not using 'input-send-event'. */
+        return 0;
+    }
+
+    if (!(event = virJSONValueNewObject()) ||
+        !(data = virJSONValueNewObject()))
+        goto cleanup;
+
+    if (virJSONValueObjectAppendBoolean(data, "down", down) < 0)
+        goto cleanup;
+
+    if (virJSONValueObjectAppend(data, "key", key) < 0)
+        goto cleanup;
+
+    key = NULL;
+
+    if (virJSONValueObjectAppendString(event, "type", "key") < 0)
+        goto cleanup;
+
+    if (virJSONValueObjectAppend(event, "data", data) < 0)
+        goto cleanup;
+
+    data = NULL;
+
+    if (virJSONValueArrayAppend(list, event) < 0)
+        goto cleanup;
+
+    event = NULL;
+
+    return 0;
+
+ cleanup:
+    virJSONValueFree(data);
+    virJSONValueFree(event);
+    virJSONValueFree(key);
+    return -1;
+}
+
 int qemuMonitorJSONSendKey(qemuMonitorPtr mon,
                            unsigned int holdtime,
                            unsigned int *keycodes,
-                           unsigned int nkeycodes)
+                           unsigned int nkeycodes,
+                           bool events)
 {
     int ret = -1;
     virJSONValuePtr cmd = NULL;
     virJSONValuePtr reply = NULL;
     virJSONValuePtr keys = NULL;
-    virJSONValuePtr key = NULL;
-    size_t i;
+    ssize_t i;
+    size_t nreverts = 0;
+    unsigned int *reverts = NULL;
+
+
+    /*
+     * We are trying to use input-send-event to control press/release
+     * events more precisely, but that API doesn't support the
+     * 'holdtime' parameter (obviously).  Due to backward
+     * compatibility, we need to keep the 'holdtime' parameter working
+     * as that is the thing that wasn't broken (yet), unlike the order
+     * of press/release events 'send-key' sends to the guest.
+     *
+     * And we cannot combine 'input-send-event' and 'send-key' because
+     * if there's any error between sending press and release events,
+     * some modifiers might be left pressed.
+     */
+    if (events && holdtime) {
+        events = false;
+        VIR_WARN("Using only send-key even though "
+                 "this QEMU binary supports input-send-event");

Using the API extensively may result in log pollution. How about adding
a bool into qemuMonitorPtr to suppress the repeated warnings for a
certain instance of a VM?

+    }

     /* create the key data array */
     if (!(keys = virJSONValueNewArray()))
         goto cleanup;

     for (i = 0; i < nkeycodes; i++) {
+        bool modifier = virKeycodeValueIsModifier(keycodes[i]);

So here you check if a specific key sent by the user is a modifier in
order as the keys were specified.

Thus sending [ctrl] s [shift] s is added as:

ctrl down,
's' down,
's' up,
shift down,
's' down,
's' up,
shift up,
ctrl up.

resulting into a ^s^S


Yes, we state that if you want '^sS' you should use multiple SendKey
calls.

The documentation should state that the modifier keys are pressed in the
order they were specified along with other keys in the input array.

Unless you need to also release some keys as part of the key combo this
should be fine for the default use case and releasing a modifier is
possible by calling the command multiple times and re-specifying the
correct modifiers. This should be documented.


It is, only in virsh man page, though.  I agree that it could be part
of the API doc.

One thing that can't be expressed is if a certain combination would
require "holding" down one modifier key, while a second one would need
to be toggled, but I don't know of any of those :)


Me neither, but anyway, this wasn't possible before using send-key and
it still doesn't forbid you to do anything like that when connected to
the domain's console.

Second issue that can happen is that a user specifies a modifier
multiple times which would generate multiple down events followed by
multiple up events. I think we shouldn't allow those.


But that worked before, and also that's what qemu does anyway with
send-key; and we can't guess what the user meant by that.

As an additional thought: With a special flag we could specify that
specifying the modifier more that once toggles it's state. (and the
state is reverted to up regardless of the number of times it was
specified) This is a future thought though.


It looks like an API abuse, new API would make more sense for this
kind of stuff, and it could also support other event types
(e.g. relative/absolute mouse movement, mouse buttons).

As said, taking parts of the virsh docs and using them in the API docs
would be an great improvement in case of this API.

Overall looks good. I'd be glad if you could document few of the nuances
of this API as a part of this patch and forbid the use of repeated
multipliers in case the event is used.


I'd love to, *but*...  There would be many ifs that would just confuse
users and developers.  Imagine a documentation that starts:

 This API does not guarantee any of the following features unless you
 are using QEMU/KVM and the binary used supports 'input-send-event'
 API.  There's also no guarantee if you are using 'holdtime'
 parameter.
 <bunch of super cool features follows>

Not mentioning that after first change in this code it would not be
true any more (again).

I was trying to just keep a bit more of backward compatibility.  What
you suggests can be exposed as a new API, which I'd be fine with, but
was out of scope of this series.  Adding features you mentioned to
SendKey API doesn't make sense for me due to the specificity of those
features.  And I guess send-key is just used for stuff like
Ctrl-Alt-Del and similar when you don't have any console connection,
anyway.

Update:  I tried to do this in the SendKey API, but just realized a
while back, that it's not needed for the use-case I wanted it to.
I'll add it as an API later on unless if there are no objections.

Martin

Attachment: signature.asc
Description: Digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]