Created attachment 443394 [details] rhe6_hvm Description of problem: After installation latest rhel6 (0901.0) hvm guest, I use "sdl" display method to show guest, then I find that keyboard function is well in guest,but I can not see mouse and can not use it in guest. Version-Release number of selected component (if applicable): xen-3.0.3-116.el5 kernel-xen-2.6.18-215.el5 How reproducible: Always Steps to Reproduce: 1.Install rhel6 (0901.0) hvm guest with Desktop 2.After installation, use "sdl" display method to show guest. 3.Use keyboard to input username and password to login 4.Use mouse to click some icon Actual results: After step4, I can not see mount in guest and can not use it in guest. Expected results: I can use keyboard and mouse in hvm guest. Additional info: When I use "vnc" display method, I can use mouse successfully. Please see attachment: config file: rhel6-hvm
Testing shows that this problem is affecting rhel5 guest too. Mouse is emulated in sdl mode, button clicks are working correctly. There's problem with moving the cursor - move coordinate do not corresponded to actual move.
Ok, I've been working on this one and I found out what's most likely going on. The issue is with the SDL_ShowCursor() function since the GetRelativeMouseState() is not providing the correct values when ShowCursor has been called with parameter 0 to disable showing the cursor. I've created a debugging that helped me find this out and since there are 2 cursors if the window grab is done which makes the confusion I rewrote the sdl_hide_cursor() and sdl_show_cursor() functions of QEMU SDL layer to just set hidden cursor or normal cursor always, i.e. for both absolute position enabled and disabled. I tested the patch to use virtual PS/2 Mouse in the SDL window and everything was working fine. After all, the patch is pretty easy and working fine according to my testing. Honestly I don't follow how the cursor could have been shown once hidden when using absolute positioning since the cursor was set to hidden but it was never set back to normal. Michal Here's the patch: --- a/tools/ioemu/sdl.c +++ b/tools/ioemu/sdl.c @@ -285,19 +285,12 @@ static void sdl_update_caption(void) static void sdl_hide_cursor(void) { - if (kbd_mouse_is_absolute()) { - SDL_ShowCursor(1); - SDL_SetCursor(sdl_cursor_hidden); - } else { - SDL_ShowCursor(0); - } + SDL_SetCursor(sdl_cursor_hidden); } static void sdl_show_cursor(void) { - if (!kbd_mouse_is_absolute()) { - SDL_ShowCursor(1); - } + SDL_SetCursor(sdl_cursor_normal); } static void sdl_grab_start(void)
Packages with this test applied are available at http://people.redhat.com/minovotn/xen as virttest35.gf099a75 test packages. Could you please test them? Thanks, Michal
(In reply to comment #4) > Packages with this test applied are available at > http://people.redhat.com/minovotn/xen as virttest35.gf099a75 test packages. > > Could you please test them? > > Thanks, > Michal Sorry, I meant packages with this patch. Michal
yufang, please help to provide the info for this bug, thanks.
I did the comparison of Xen SDL with this patch applied to QEMU-0.13 that's present in Fedora 14 (both using SDL window) and the results are the same for me but the strange thing is that QEMU code is the same like it was in Xen QEMU-DM but there it's working fine so there *may* be a bug in SDL present in RHEL-5 because the values returned by SDL_GetRelativeMouseState() are invalid when showing the SDL cursor is disabled. QEMU Version: qemu-0.13.0-1.fc14 QEMU Command: /usr/bin/qemu-kvm -m 512 -boot c -drive file=/path/to/image.img,if=none,id=drive-ide0-0-0,boot=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -sdl Michal
This should be fixed by the upstream patch 4c44bdcb ("SDL mouse events smoothness") which I was planning to backport as part of bug 665017. That patch can be moved to this bug.
(In reply to comment #9) > This should be fixed by the upstream patch 4c44bdcb ("SDL mouse events > smoothness") which I was planning to backport as part of bug 665017. That > patch can be moved to this bug. Unfortunately, this patch does not solve the problem. Cursor is still in right bottom corner of screen.
(In reply to comment #10) > (In reply to comment #9) > > This should be fixed by the upstream patch 4c44bdcb ("SDL mouse events > > smoothness") which I was planning to backport as part of bug 665017. That > > patch can be moved to this bug. > > Unfortunately, this patch does not solve the problem. Cursor is still in right > bottom corner of screen. Could you please retest with virttest35.gf099a75 test packages from http://people.redhat.com/minovotn/xen ? It was working fine for me but no upstream changeset I tried did. Michal
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
I could reproduce it with Windows 7 without the USB tablet, and patch 4c44bdcb fixes it for me. With the USB tablet it worked always.
(In reply to comment #14) > I could reproduce it with Windows 7 without the USB tablet, and patch 4c44bdcb > fixes it for me. With the USB tablet it worked always. Interesting, it was not working with just patch 4c44bdcb when trying to run it on the RHEL-5 HVM guest. That's kind of strange. I was not using USB tablet device at all but without my patch (even with 4c44bdcb applied) I was unable to see the mouse pointer and no mouse movement helped with this one. If this is working fine for you with just patch 4c44bdcb I'll try it once again and provide the output of package I applied the patch to etc. Michal
Fix built into xen-3.0.3-126.el5
Failed to verify this bug on xen-3.0.3-126.el5 steps to verify on xen-3.0.3-126.el5: 1. create a rhel6 hvm guest use "sdl" display method to show guest 2. SDL display should be open after create the guest. 3. Use keyboard to click some icon. 4. use mouse to click some icon. Actual Result: In step4, I can click mouse but not move mouse. I can't see the mouse icon, but it seems that the mouse stay in the lower right corner, right on the trash icon. Expect Result: The mouse can be functionally works well in HVM guest.
Created attachment 486739 [details] xend log(xen126)
Created attachment 486740 [details] guest_dmesg log(xen126)
Created attachment 486741 [details] dmesg log(xen126)
rechecking...sorry for the inconvenience this fix works well on ssh -X login the test machine and steps as comment 28. but doesn't work when right create a guest on the test machine. Try to dig deeper on this.
Tested this bug with PS/2 mouse and USB mouse with xen130. Most of the scenarios work fine. But the mouse doesn't work for one machine. When start a HVM guest(RHEL6.1 and Win7 tested) on the local host of DELL 780(USB mouse), the mouse stay in the lower right corner, just as comment 28 said. But it works fine when ssh -X login DELL 780 and start a "sdl" guest. It also works fine both local and remote on DELL 760(USB Mouse) and HP Z400(PS2 Mouse). Version-Release number of selected component (if applicable): xen-3.0.3-130.el5 kernel-xen-2.6.18-259.el5
I tested this bug with xen-3.0.3-130.el5 and kernel-xen-2.6.18-259.el5. On DELL 760(USB mouse) and HPZ400(PS2 mouse), the mouse works well in hvm guest using "sdl" display method. But on DELL780(USB mouse), the mouse only works well when you login the guest using "ssh -X" method and using "sdl" display method. The mouse stay in the lower right corner when you login the guest on local host. Both RHEL6.1 guest and Win7 guest has the same problem. Is this problem related to this bug? Can I closed this bug as VERIFIED according the test result?
I suppose "USB mouse" and "PS2 mouse" refers to the mouse you have in the host? That should not matter. Can you set up an Xvnc server on DELL780 and try to reproduce the bug that way? So we can look at it and see what's wrong there.
Verified on xen-3.0.3-131.el5 and kernel-xen-2.6.18-261.el5 Create a guest using "sdl" display method, the mouse can be seen and used in the guest now. The cursor no longer stay in right bottom corner of screen. The problem in comment 34 can be solved by adding 'usbdevice="tablet"' in guest configure file. since this bug is only about 'usbdevice="tablet"', so change the status into VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the mouse cursor could not be moved in an HVM guest when the SDL (Simple DirectMedia Layer) display method was used. With this update, a patch has been provided that fixes this incorrect behavior of the PS/2 mouse with the SDL interface, and the mouse cursor now works as expected.
Changed HVM->fully-virtualized, which is the name used in the virtualization guide. I think SDL should be left unexpanded because it appears in the user interface; I changed the text to include the name of the user interface option that activates SDL.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Previously, the mouse cursor could not be moved in an HVM guest when the SDL (Simple DirectMedia Layer) display method was used. With this update, a patch has been provided that fixes this incorrect behavior of the PS/2 mouse with the SDL interface, and the mouse cursor now works as expected.+Previously, the mouse cursor could not be moved in an fully-virtualized guest when the emulate PS/2 mouse was chosen together with the "Local SDL Window" display method. With this update, a patch has been provided that fixes this incorrect behavior of the PS/2 mouse in an SDL window, and the mouse cursor now works as expected.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Previously, the mouse cursor could not be moved in an fully-virtualized guest when the emulate PS/2 mouse was chosen together with the "Local SDL Window" display method. With this update, a patch has been provided that fixes this incorrect behavior of the PS/2 mouse in an SDL window, and the mouse cursor now works as expected.+Previously, the mouse cursor could not be moved in an fully-virtualized guest when the emulated PS/2 mouse was chosen together with the "Local SDL Window" display method. With this update, a patch has been provided that fixes this incorrect behavior of the PS/2 mouse in an SDL (Simple DirectMedia Layer) window, and the mouse cursor now works as expected.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Previously, the mouse cursor could not be moved in an fully-virtualized guest when the emulated PS/2 mouse was chosen together with the "Local SDL Window" display method. With this update, a patch has been provided that fixes this incorrect behavior of the PS/2 mouse in an SDL (Simple DirectMedia Layer) window, and the mouse cursor now works as expected.+Previously, the mouse cursor could not be moved in an fully-virtualized guest when the emulated PS/2 mouse was chosen together with the "Local SDL Window" display method. With this update, a patch has been provided that fixes this incorrect behavior of the "Local SDL Window" display method, and the mouse cursor now works as expected.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1070.html