Bug 509358 - X QXL driver: Mouse movement is chaotic/not synchronized.
X QXL driver: Mouse movement is chaotic/not synchronized.
Status: CLOSED DUPLICATE of bug 558611
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-qxl (Show other bugs)
5.4
All Linux
high Severity high
: rc
: ---
Assigned To: Søren Sandmann Pedersen
desktop-bugs@redhat.com
: Reopened
Depends On:
Blocks: 5.4/TechnicalNotes
  Show dependency treegraph
 
Reported: 2009-07-02 08:47 EDT by Leonid Natapov
Modified: 2016-04-26 11:05 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-27 12:46:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leonid Natapov 2009-07-02 08:47:28 EDT
Mouse movement is chaotic/not synchronized.
Soren,pls let us know if there are any log files needed to be supplied.
Comment 1 Søren Sandmann Pedersen 2009-07-06 11:29:29 EDT
Is this about the client side mouse cursor? That is not supported by the X server.
Comment 2 Leonid Natapov 2009-07-06 11:50:09 EDT
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 ?
Comment 3 Miki Kenneth 2009-07-07 04:04:52 EDT
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.
Comment 5 Søren Sandmann Pedersen 2009-07-14 22:38:59 EDT
I can't reproduce this. The mouse works fine for me.
Comment 6 Søren Sandmann Pedersen 2009-07-14 23:37:26 EDT
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.
Comment 7 Søren Sandmann Pedersen 2009-07-15 16:14:40 EDT
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.
Comment 8 Yaniv Kamay 2009-07-15 16:46:01 EDT
(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?
Comment 9 Søren Sandmann Pedersen 2009-07-15 17:21:40 EDT
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
Comment 10 Yaniv Kamay 2009-07-15 17:42:37 EDT
(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?
Comment 11 Søren Sandmann Pedersen 2009-07-15 18:28:36 EDT
> 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.
Comment 12 Yaniv Kamay 2009-07-15 19:28:27 EDT
(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.
Comment 13 Yaniv Kaul 2009-07-16 01:27:45 EDT
(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.
Comment 14 Yaniv Kamay 2009-07-16 05:42:49 EDT
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.
Comment 16 Uri Lublin 2009-07-19 11:09:08 EDT
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.
Comment 18 Søren Sandmann Pedersen 2009-07-21 04:58:59 EDT
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.
Comment 19 Yaniv Kamay 2009-07-21 07:48:49 EDT
(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?
Comment 22 Søren Sandmann Pedersen 2009-07-27 12:53:41 EDT
Can't we just stop using the USB tablet with Linux guests?
Comment 23 Uri Lublin 2009-07-28 07:15:29 EDT
(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 ?
Comment 24 Søren Sandmann Pedersen 2009-07-29 10:05:05 EDT
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.
Comment 25 Søren Sandmann Pedersen 2009-07-29 10:41:55 EDT
Also delete the existing "Mouse" inputdevice section. The driver must be "void" for the mouse, or it won't work.
Comment 26 Uri Lublin 2009-07-29 19:38:40 EDT
(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).
Comment 29 Susan Burgess 2009-09-30 02:26:19 EDT
The info from Uri has been added to the manuals. can be closed.
Comment 30 Yaniv Kaul 2009-12-20 09:52:04 EST
Re-opening for 5.5.
Comment 33 Søren Sandmann Pedersen 2010-01-27 12:46:09 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.