| Message ID | 1460962415.21910.3.camel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 18.04.16 08:53, Gerd Hoffmann wrote: > Hi, > >> Vnc already uses qemu_input_event_send_key_delay today, so I'm not sure >> where things fall apart. > > Well, not everywhere. Try the attached patch. > > Also worth trying: > * use xhci instead of ohci (current slof should handle > kbd-via-xhci fine) > * use virtio-keyboard (no slof driver yet as far I know, also needs > a recent linux kernel). Ideally I would really like to switch to virtio-input and virtio-gpu for AArch64, but there are no drivers at all in OVMF. Do you have any plans to write them? IIRC xhci "solved" the problem for PPC, but not on AArch64. I'll have to double-check with Dirk and Dinar though. The attached patch also looks sensible. Dinar, Dirk, could you give that a spin please? Thanks, Alex
On Mo, 2016-04-18 at 09:26 +0200, Alexander Graf wrote: > > On 18.04.16 08:53, Gerd Hoffmann wrote: > > Hi, > > > >> Vnc already uses qemu_input_event_send_key_delay today, so I'm not sure > >> where things fall apart. > > > > Well, not everywhere. Try the attached patch. > > > > Also worth trying: > > * use xhci instead of ohci (current slof should handle > > kbd-via-xhci fine) > > * use virtio-keyboard (no slof driver yet as far I know, also needs > > a recent linux kernel). > > Ideally I would really like to switch to virtio-input and virtio-gpu for > AArch64, but there are no drivers at all in OVMF. Do you have any plans > to write them? Not investigated yet. There are virtio 1.0 patches in flight for edk2, once they are landed it should be alot simpler (virtio 1.0 is mandatory for virtio-gpu and virtio-input). Keyboard should be easy, it's a simple device. GPU is tricky. Guest is expected to explicitly request display updates. So simply setting up a dump framebuffer, then depending on dirty page tracking for screen updates isn't going to fly. Not sure EFI can handle that. The virtio-vga device has a vga compatibility mode additionally to native virtio. SLOF uses that IIRC. But I think on aarch64 that isn't going to fly either due to the cache coherency issues there. cheers, Gerd
On 18.04.16 11:21, Gerd Hoffmann wrote: > On Mo, 2016-04-18 at 09:26 +0200, Alexander Graf wrote: >> >> On 18.04.16 08:53, Gerd Hoffmann wrote: >>> Hi, >>> >>>> Vnc already uses qemu_input_event_send_key_delay today, so I'm not sure >>>> where things fall apart. >>> >>> Well, not everywhere. Try the attached patch. >>> >>> Also worth trying: >>> * use xhci instead of ohci (current slof should handle >>> kbd-via-xhci fine) >>> * use virtio-keyboard (no slof driver yet as far I know, also needs >>> a recent linux kernel). >> >> Ideally I would really like to switch to virtio-input and virtio-gpu for >> AArch64, but there are no drivers at all in OVMF. Do you have any plans >> to write them? > > Not investigated yet. There are virtio 1.0 patches in flight for edk2, > once they are landed it should be alot simpler (virtio 1.0 is mandatory > for virtio-gpu and virtio-input). > > Keyboard should be easy, it's a simple device. > > GPU is tricky. Guest is expected to explicitly request display updates. > So simply setting up a dump framebuffer, then depending on dirty page > tracking for screen updates isn't going to fly. Not sure EFI can handle > that. It should. The GOP interface usually gets invoked with special BLT callbacks that copy gfx data from the payload to the frame buffer. Of course we would need to make sure we don't set the magical "this is where the frame buffer is, please use it" bit, as otherwise Linux would try to access it as efifb. > The virtio-vga device has a vga compatibility mode additionally to > native virtio. SLOF uses that IIRC. But I think on aarch64 that isn't > going to fly either due to the cache coherency issues there. Exactly, so a native virtio-gpu driver would be the best option for us here. Once Linux takes over, it can just switch to its own virtio-gpu driver. Alex
From 870daf1865430b5107cfad25142d30d006a0ec2a Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann <kraxel@redhat.com> Date: Mon, 18 Apr 2016 08:49:00 +0200 Subject: [PATCH] vnc: add configurable keyboard delay --- ui/vnc.c | 13 +++++++++++-- ui/vnc.h | 1 + 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/ui/vnc.c b/ui/vnc.c index d2ebf1f..ea3b3d4 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -1629,6 +1629,7 @@ static void reset_keys(VncState *vs) for(i = 0; i < 256; i++) { if (vs->modifiers_state[i]) { qemu_input_event_send_key_number(vs->vd->dcl.con, i, false); + qemu_input_event_send_key_delay(vs->vd->key_delay_ms); vs->modifiers_state[i] = 0; } } @@ -1638,9 +1639,9 @@ static void press_key(VncState *vs, int keysym) { int keycode = keysym2scancode(vs->vd->kbd_layout, keysym) & SCANCODE_KEYMASK; qemu_input_event_send_key_number(vs->vd->dcl.con, keycode, true); - qemu_input_event_send_key_delay(0); + qemu_input_event_send_key_delay(vs->vd->key_delay_ms); qemu_input_event_send_key_number(vs->vd->dcl.con, keycode, false); - qemu_input_event_send_key_delay(0); + qemu_input_event_send_key_delay(vs->vd->key_delay_ms); } static int current_led_state(VncState *vs) @@ -1792,6 +1793,7 @@ static void do_key_event(VncState *vs, int down, int keycode, int sym) if (qemu_console_is_graphic(NULL)) { qemu_input_event_send_key_number(vs->vd->dcl.con, keycode, down); + qemu_input_event_send_key_delay(vs->vd->key_delay_ms); } else { bool numlock = vs->modifiers_state[0x45]; bool control = (vs->modifiers_state[0x1d] || @@ -1913,6 +1915,7 @@ static void vnc_release_modifiers(VncState *vs) continue; } qemu_input_event_send_key_number(vs->vd->dcl.con, keycode, false); + qemu_input_event_send_key_delay(vs->vd->key_delay_ms); } } @@ -3249,6 +3252,9 @@ static QemuOptsList qemu_vnc_opts = { .name = "lock-key-sync", .type = QEMU_OPT_BOOL, },{ + .name = "key-delay-ms", + .type = QEMU_OPT_NUMBER, + },{ .name = "sasl", .type = QEMU_OPT_BOOL, },{ @@ -3486,6 +3492,7 @@ void vnc_display_open(const char *id, Error **errp) #endif int acl = 0; int lock_key_sync = 1; + int key_delay_ms; if (!vs) { error_setg(errp, "VNC display not active"); @@ -3604,6 +3611,7 @@ void vnc_display_open(const char *id, Error **errp) reverse = qemu_opt_get_bool(opts, "reverse", false); lock_key_sync = qemu_opt_get_bool(opts, "lock-key-sync", true); + key_delay_ms = qemu_opt_get_number(opts, "key-delay-ms", 1); sasl = qemu_opt_get_bool(opts, "sasl", false); #ifndef CONFIG_VNC_SASL if (sasl) { @@ -3735,6 +3743,7 @@ void vnc_display_open(const char *id, Error **errp) } #endif vs->lock_key_sync = lock_key_sync; + vs->key_delay_ms = key_delay_ms; device_id = qemu_opt_get(opts, "display"); if (device_id) { diff --git a/ui/vnc.h b/ui/vnc.h index 81a3261..6568bca 100644 --- a/ui/vnc.h +++ b/ui/vnc.h @@ -155,6 +155,7 @@ struct VncDisplay DisplayChangeListener dcl; kbd_layout_t *kbd_layout; int lock_key_sync; + int key_delay_ms; QemuMutex mutex; QEMUCursor *cursor; -- 1.8.3.1