1 files changed, 61 insertions, 0 deletions
diff --git a/results/classifier/108/other/1776224 b/results/classifier/108/other/1776224
new file mode 100644
index 000000000..5ea24df88
--- /dev/null
+++ b/results/classifier/108/other/1776224
@@ -0,0 +1,61 @@
+device: 0.781
+graphic: 0.753
+performance: 0.664
+other: 0.656
+socket: 0.511
+semantic: 0.486
+network: 0.464
+permissions: 0.446
+debug: 0.430
+PID: 0.410
+boot: 0.338
+vnc: 0.294
+files: 0.113
+KVM: 0.068
+
+QEMU's SPICE server not getting leds callback when sending capslock
+
+I'm having troubles using the QEMU's SPICE server for remote views. When
+trying to sync leds from my SPICE client to QEMU, I can see that the
+caps lock keycodes are sent but the server state never gets updated
+(which leads in funny behaviours like caps lock "blinking" in the guest
+if the clients resyncs its state often).
+
+That behaviour doesn't happen at all with the numlock led which does the
+same thing but with different keycodes.
+
+Here is an example of what's happening when the client tries to resync
+with a capslock difference:
+
+> Spice received: 58
+> ps2_put_keycode: 88
+>
+> Spice received: 186
+> ps2_put_keycode: 240
+> ps2_put_keycode: 88
+> ps2_queue: 186
+
+And with numlock:
+
+> Spice received: 69
+> ps2_put_keycode: 119
+>
+> Spice received: 197
+> ps2_put_keycode: 240
+> ps2_put_keycode: 119
+> ps2_queue: 197
+> ps2_set_ledstate: 0
+> Spice new ledstate: 0
+
+
+This behaviour is consistent across SPICE clients and only appears in a linux TTY (it works fine if I start an X server and on windows). It still happens on QEMU latest commit at the time (0d2fa03dae4fbe185a082f361342b1e30aed4582)
+
+Spice registers a callback for leds via qemu_add_led_event_handler but
+it's never called for capslock. Is that a normal behaviour ? Is there
+any reasons for the capslock led not to be updated ?
+
+
+
+This is in fact https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/425704
+Sorry for the noise
+