[libvirt] [PATCH 3/3] qemu: Improve qemuMonitorJSONSendKey function
Martin Kletzander
mkletzan at redhat.com
Wed Nov 12 16:46:17 UTC 2014
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141112/c40a0b3e/attachment-0001.sig>
More information about the libvir-list
mailing list