Mouse movement is chaotic/not synchronized. Soren,pls let us know if there are any log files needed to be supplied.
Is this about the client side mouse cursor? That is not supported by the X server.
Soren,if I select QXL driver as a driver that I want to work with and restart the X server,the mouse wouldn't work properley. Are you saying that this is a normal behaviour ? What should I do to be able to work with QXL driver and mouse ?
I play with it as well - we need to make yet at least like the VNC one (i prefer better - of course). In the current state it is unusable.
I can't reproduce this. The mouse works fine for me.
From reading the libspice source code, this function: static void update_client_mouse_allowed() { static int allowed = FALSE; int x_res = 0; int y_res = 0; int allow_now = FALSE; if (num_active_workers) { RedDispatcher *now = dispatchers; while (now) { if (now->active) { if (now->use_hardware_cursor) { allow_now = TRUE; x_res = now->x_res; y_res = now->y_res; } break; } now = now->next; } } if (allow_now || allow_now != allowed) { allowed = allow_now; reds_set_client_mouse_allowed(allowed, x_res, y_res); } } in red_dispatcher.c seems to turn on client mouse if the server supports a hardware cursor. This is incorrect for the X driver - it supports a hardware cursor, but not client cursor. I don't know why my spice client does not do that. Maybe I have an old version of it. Please let me know where I can find the latest one.
I need some input from libspice authors. If libspice turns on client mouse as a result of the driver, then that's the issue. If so, either libspice should stop doing that, or we can add an option to the qxl X driver to disable hardware cursors. The first is preferable, obviously.
(In reply to comment #6) > From reading the libspice source code, this function: > > static void update_client_mouse_allowed() > { > if (allow_now || allow_now != allowed) { > allowed = allow_now; > reds_set_client_mouse_allowed(allowed, x_res, y_res); > } > } > > in red_dispatcher.c seems to turn on client mouse if the server supports a > hardware cursor. This is incorrect for the X driver - it supports a hardware > cursor, but not client cursor. > > I don't know why my spice client does not do that. Maybe I have an old version > of it. Please let me know where I can find the latest one. Client mouse activation depend on additional state, please send qemu stdout?
Here is what I get (the mouse works fine for me): dhcp-100-3-19:~% ./start-kvm open /dev/kvm: Permission denied Could not initialize KVM, will disable KVM support interface_change_notifier: VD_INTERFACE_MIGRATION migration_notify_register: record=0x5ad5310 opaque=(nil) key=spice_mig_ext mstarted=0x3428e1789a mfinished=0x3428e17d9d mig_recv=0x3428e181ad interface_change_notifier: VD_INTERFACE_QTERM init_qxl_ram: npages 6165 qxl_init: rom(0x2b0d4dcf9000, 0x43040000, 0x2000) ram(0x2b0d4bcf9000, 0x41040000, 0x2000000) vram(0x2b0d4dcfb000, 0x43042000, 0x1000) interface_change_notifier: VD_INTERFACE_QXL red_worker_main: begin 0: qxl_enter_vga_mode handle_dev_input: attach create_cairo_context: using cairo canvas QEMU 0.9.1 monitor - type 'help' for more information (qemu) interface_change_notifier: VD_INTERFACE_KEYBOARD interface_change_notifier: VD_INTERFACE_MOUSE QXL: qxl_vm_change_state_handler: running=1 handle_dev_input: start qxl_display_resize qxl_reset handle_dev_input: detach handle_dev_input: attach create_cairo_context: using cairo canvas vdi_port_io_map: base 0xc010 size 0x10 vdi_port_ram_map: addr 0xc1000000 size 0x10000 ram_map: addr 0xc2000000 size 0x2000000 vram_map: addr 0xc4000000 size 0x1000 rom_map: addr 0xc4002000 size 0x2000 ioport_map: base 0xc020 size 0x8 qxl_display_resize qxl_reset handle_dev_input: detach handle_dev_input: attach create_cairo_context: using cairo canvas qxl_display_resize qxl_reset handle_dev_input: detach handle_dev_input: attach create_cairo_context: using cairo canvas vdi_port_io_map: base 0xc010 size 0x10 vdi_port_ram_map: addr 0xc1000000 size 0x10000 ram_map: addr 0xc2000000 size 0x2000000 vram_map: addr 0xc4000000 size 0x1000 rom_map: addr 0xc4002000 size 0x2000 ioport_map: base 0xc020 size 0x8 reds_handle_main_link: reds_show_new_channel: channel 1:0, connected sucessfully, over Non Secure link reds_show_new_channel: channel 3:0, connected sucessfully, over Non Secure link inputs_link: reds_show_new_channel: channel 4:0, connected sucessfully, over Non Secure link red_dispatcher_set_cursor_peer: handle_dev_input: cursor connect reds_show_new_channel: channel 2:0, connected sucessfully, over Non Secure link red_dispatcher_set_peer: handle_dev_input: connect ram_map: addr 0xc2000000 size 0x2000000 vram_map: addr 0xc4000000 size 0x1000 rom_map: addr 0xc4002000 size 0x2000 ioport_map: base 0xc020 size 0x8 0: QXL_IO_SET_MODE qxl_set_mode: 129 handle_dev_input: detach qxl_exit_vga_mode handle_dev_input: attach create_cairo_context: using cairo canvas The start-kvm script contains this: /usr/libexec/qemu-kvm -m 1024 -hda RHEL5.qcow2 -boot c -monitor stdio -qxl 1,ram=32 -spice port=3000,ic=on,sv=on,disable-ticketing
(In reply to comment #9) > Here is what I get (the mouse works fine for me): > I don't understand, how did you decided that it have to do with client mouse? To test with client mouse you can add "-usbdevice tablet" to QEMU command args. Leonid do we have client mouse on Linux guest?
> I don't understand, how did you decided that it have to do with client mouse? Just a guess, based on the symptoms and on the source code I pasted above, and on the fact that I can't reproduce the problem. With -usbdevice-tablet I get wrong mouse behavior, as expected, so that should not be turned on for Linux guests.
(In reply to comment #11) > > I don't understand, how did you decided that it have to do with client mouse? > > Just a guess, based on the symptoms and on the source code I pasted above, and > on the fact that I can't reproduce the problem. I don't think they run VM with USB tablet so client mouse should be off. I will verify it tomorrow. > > With -usbdevice-tablet I get wrong mouse behavior, as expected, so that should > not be turned on for Linux guests. You only need to support hardware mouse in order to support it (using one monitor) so it suppose to work fine. What is wrong mouse behaviour? Maybe this is the bug.
(In reply to comment #9) > Here is what I get (the mouse works fine for me): > > dhcp-100-3-19:~% ./start-kvm > open /dev/kvm: Permission denied > Could not initialize KVM, will disable KVM support You are running QEMU, not KVM <snip > > > The start-kvm script contains this: > > /usr/libexec/qemu-kvm -m 1024 -hda RHEL5.qcow2 -boot c -monitor stdio -qxl > 1,ram=32 -spice port=3000,ic=on,sv=on,disable-ticketing We have a few additional parameters to run the VMs in RHEVM: -no-hpet, -usbdevice tablet, etc. Not sure they are all important for Spice dev., but perhaps you should use the same.
VM with one monitor use USB tablet, in this scenario we have out of sync mouse position. The BUG is probably wrong mapping of pointer position in USB tablet. We need to have release note about it. For fast work around we can lunch Linux guest with two QXL devices.
The problem happens with SDL and VNC too (RHEL 5.3 x86_64 guest). It looks like the mapping between tablet coordinates to display coordinates is incorrect. We did not modify X configuration file, but used the default. Soren, do we need to change X configuration file to support tablet ? How ? p.s. Note, Connecting a usb-tablet device on a physical machine running RHEL 5.3 (and RHEL 5.4) does not work. But on Fedora it works.
I am under the impression that client mouse relies on a special daemon running in the guest and that this daemon is not available for Linux; hence client side mouse cannot work there.
(In reply to comment #18) > I am under the impression that client mouse relies on a special daemon running > in the guest and that this daemon is not available for Linux; hence client side > mouse cannot work there. On windows guest daemon is only required in multi monitors configuration. In single monitors configuration we can use USB tablet so I suppose it can also work on X11 using correct configuration. Can you ask someone in your team with the relevant knowledge to look into it?
Can't we just stop using the USB tablet with Linux guests?
(In reply to comment #22) 1. I was under the impression that for a remote mouse, an absolute pointer is better (especially for network with large latency and busy hosts). 2. RHEV-M is the component that knows the guest OS (assuming the user has provided this information, which we can assume). To support 'no USB tablet for Linux guest', RHEV-M would be required to pass guest-os to VDSM which would not add USB tablet to qemu-kvm command line (or pass 'use usb tablet' flag for other guests). I think by now it's too late for RHEV-M VDSM protocol changes. 3. How hard would it be to configure X to support USB tablet ?
Peter Hutterer came up with a way to get the USB tablet to work with X. Add this to xorg.conf: Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Tablet" "SendCoreEvents" InputDevice "Mouse" "CorePointer" EndSection Section "InputDevice" Identifier "Mouse" Driver "void" #Option "Device" "/dev/input/mice" #Option "Emulate3Buttons" "yes" EndSection Section "InputDevice" Identifier "Tablet" Driver "evdev" Option "Device" "/dev/input/event2" Option "CorePointer" "true" EndSection and delete the existing Serverlayout section.
Also delete the existing "Mouse" inputdevice section. The driver must be "void" for the mouse, or it won't work.
(In reply to comment #24) Thanks Soren (and Peter Hutterer), that configuration works. I've ran RHEL 5.4 x86_64 guest with SDL, VNC (with default cirrus vga) and with SPICE (with x11-xorg-drv-qxl package installed). All work. We need to add this to the documentation (I'm sure it is already mentioned that users need to install the x11-xorg-drv-qxl package and modify xorg.conf to use qxl driver). Maybe also mention that if users want to use "vesa" videocard driver (when running with qxl device), they may want to delete those above lines added to xorg.conf (as mouse may stop working otherwise).
The info from Uri has been added to the manuals. can be closed.
Re-opening for 5.5.
I'll make the X server autodetect the QXL device, but the tablet will still have to be manually added to xorg.conf. The QXL device detection is bug 558611 . Closing this bug. *** This bug has been marked as a duplicate of bug 558611 ***