[Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

[Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

[Dan Kenigsberg]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

Hi,

I saw that using the tablet with Linux guest is possible
http://thread.gmane.org/gmane.comp.emulators.qemu/11516
yet I fail to do that.

I managed to compile, configure and load the evtouch X module, but still
there is no movement of the mouse (after I disabled the default X
pointer). I attach my Xorg.0.log for the joy of the readership.

Where could my problem lie?

How can I tell whether Linux gets ANYTHING from the tablet device?
lsusb gives a bizarre ID that does not seem too relevant:
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd

BTW, did anyone manage to use the tablet device in Linux's console (with
gpm)?

Regads,
    Dan.

[-- Attachment #2: Xorg.0.log.gz --]
[-- Type: application/x-gzip, Size: 4788 bytes --]

Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

[Daniel P. Berrange]

On Thu, Sep 20, 2007 at 03:36:26PM +0200, Dan Kenigsberg wrote:
> Hi,
> 
> I saw that using the tablet with Linux guest is possible
> http://thread.gmane.org/gmane.comp.emulators.qemu/11516
> yet I fail to do that.
> 
> I managed to compile, configure and load the evtouch X module, but still
> there is no movement of the mouse (after I disabled the default X
> pointer). I attach my Xorg.0.log for the joy of the readership.

Don't use the evtouch X module. Use the regular 'evdev' module.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

[Dan Kenigsberg]

On Thu, Sep 20, 2007 at 02:41:32PM +0100, Daniel P. Berrange wrote:
> On Thu, Sep 20, 2007 at 03:36:26PM +0200, Dan Kenigsberg wrote:
> > Hi,
> > 
> > I saw that using the tablet with Linux guest is possible
> > http://thread.gmane.org/gmane.comp.emulators.qemu/11516
> > yet I fail to do that.
> > 
> > I managed to compile, configure and load the evtouch X module, but still
> > there is no movement of the mouse (after I disabled the default X
> > pointer). I attach my Xorg.0.log for the joy of the readership.
> 
> Don't use the evtouch X module. Use the regular 'evdev' module.
> 
> Dan.

Dan, thanks for this info. However, my problem begins earlier than in X
and using evdev instead of evtouch does not solve it.

It seems that some Linux guests have problems communicating with the
tablet device. The most reproducible behavior that I noticed is when
FC-6 starts: gpm senses the tablet, but only until haldaemon starts.
After that, I cannot obtain any mouse event (even after stopping
haldaemon).

Could you tell if this can be avoided?

Thanks,

Dan.

[Qemu-devel] vmmouse with Fedora-6 64bit guest

[Dan Kenigsberg]

Frustrated with evtouch, I wanted to try vmmouse's absolute mode, supported by
Liguori's patch http://thread.gmane.org/gmane.comp.emulators.qemu/16083 .

My guest has vmmouse_drv.so, and I configured its xorg.conf to load it.
However, for some reason I get
(EE) VMWARE(0): vmmouse enabled failed

On the host side, after define DEBUG_VMMOUSE, I see vmmouse_init and
nothing else.

Any idea what I am doing wrong?

Regards,
    Dan.

Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

[Dor Laor]

Dan Kenigsberg wrote:
> Frustrated with evtouch, I wanted to try vmmouse's absolute mode, supported by
> Liguori's patch http://thread.gmane.org/gmane.comp.emulators.qemu/16083 .
>
> My guest has vmmouse_drv.so, and I configured its xorg.conf to load it.
> However, for some reason I get
> (EE) VMWARE(0): vmmouse enabled failed
>
> On the host side, after define DEBUG_VMMOUSE, I see vmmouse_init and
> nothing else.
>
> Any idea what I am doing wrong?
>
> Regards,
>     Dan.
>
>
>
>   
Please dive further into this by debugging the emulator(qemu)/driver 
themselves.
good luck :)

Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

[Anthony Liguori]

Dor Laor wrote:
> Dan Kenigsberg wrote:
>> Frustrated with evtouch, I wanted to try vmmouse's absolute mode, 
>> supported by
>> Liguori's patch 
>> http://thread.gmane.org/gmane.comp.emulators.qemu/16083 .

Did you try it in KVM or in QEMU?

In KVM, you need an additional patch to ensure that the register state 
is synchronized.

Regards,

Anthony LIguori

>> My guest has vmmouse_drv.so, and I configured its xorg.conf to load it.
>> However, for some reason I get
>> (EE) VMWARE(0): vmmouse enabled failed
>>
>> On the host side, after define DEBUG_VMMOUSE, I see vmmouse_init and
>> nothing else.
>>
>> Any idea what I am doing wrong?
>>
>> Regards,
>>     Dan.
>>
>>
>>
>>   
> Please dive further into this by debugging the emulator(qemu)/driver 
> themselves.
> good luck :)
>
>
>

Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

[Dan Kenigsberg]

On Tue, Sep 25, 2007 at 08:47:47AM -0500, Anthony Liguori wrote:
> Dor Laor wrote:
> >Dan Kenigsberg wrote:
> >>Frustrated with evtouch, I wanted to try vmmouse's absolute mode, 
> >>supported by
> >>Liguori's patch 
> >>http://thread.gmane.org/gmane.comp.emulators.qemu/16083 .
> 
> Did you try it in KVM or in QEMU?
> 

In QEMU (cvs).

> In KVM, you need an additional patch to ensure that the register state 
> is synchronized.

Thanks, I'll make a note of that, and return to you for details before I
try to port vmmouse to KVM.

Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

[Dan Kenigsberg]

In X's vmmouse_drv, the magic number is defined as uint32_t. Therefore
the top half of the 64 bit ax register is garbage that should be
ignored. This makes fc6 guest's vmmouse work.


Index: hw/vmport.c
===================================================================
RCS file: /sources/qemu/qemu/hw/vmport.c,v
retrieving revision 1.1
diff -u -p -r1.1 vmport.c
--- hw/vmport.c	26 Aug 2007 17:48:12 -0000	1.1
+++ hw/vmport.c	8 Oct 2007 13:11:45 -0000
@@ -55,7 +55,7 @@ static uint32_t vmport_ioport_read(void 
     target_ulong eax;
 
     eax = s->env->regs[R_EAX];
-    if (eax != VMPORT_MAGIC)
+    if ((uint32_t)eax != VMPORT_MAGIC)
         return eax;
 
     command = s->env->regs[R_ECX];

Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

[Anthony Liguori]

Dan Kenigsberg wrote:
> In X's vmmouse_drv, the magic number is defined as uint32_t. Therefore
> the top half of the 64 bit ax register is garbage that should be
> ignored. This makes fc6 guest's vmmouse work.
>
>   

I think a better fix would be to change eax from target_ulong to uint32_t.

Regards,

Anthony Liguori

> Index: hw/vmport.c
> ===================================================================
> RCS file: /sources/qemu/qemu/hw/vmport.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 vmport.c
> --- hw/vmport.c	26 Aug 2007 17:48:12 -0000	1.1
> +++ hw/vmport.c	8 Oct 2007 13:11:45 -0000
> @@ -55,7 +55,7 @@ static uint32_t vmport_ioport_read(void 
>      target_ulong eax;
>  
>      eax = s->env->regs[R_EAX];
> -    if (eax != VMPORT_MAGIC)
> +    if ((uint32_t)eax != VMPORT_MAGIC)
>          return eax;
>  
>      command = s->env->regs[R_ECX];
>
>   

Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

[Dan Kenigsberg]

On Mon, Oct 08, 2007 at 09:55:37AM -0500, Anthony Liguori wrote:
> Dan Kenigsberg wrote:
> >In X's vmmouse_drv, the magic number is defined as uint32_t. Therefore
> >the top half of the 64 bit ax register is garbage that should be
> >ignored. This makes fc6 guest's vmmouse work.
> >
> >  
> 
> I think a better fix would be to change eax from target_ulong to uint32_t.
> 

I don't really mind that.

================

Index: hw/vmport.c
===================================================================
RCS file: /sources/qemu/qemu/hw/vmport.c,v
retrieving revision 1.1
diff -u -p -r1.1 vmport.c
--- hw/vmport.c	26 Aug 2007 17:48:12 -0000	1.1
+++ hw/vmport.c	8 Oct 2007 15:24:50 -0000
@@ -52,7 +52,7 @@ static uint32_t vmport_ioport_read(void 
 {
     VMPortState *s = opaque;
     unsigned char command;
-    target_ulong eax;
+    uint32_t eax;
 
     eax = s->env->regs[R_EAX];
     if (eax != VMPORT_MAGIC)

Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

[Daniel P. Berrange]

On Tue, Sep 25, 2007 at 02:03:56PM +0200, Dan Kenigsberg wrote:
> On Thu, Sep 20, 2007 at 02:41:32PM +0100, Daniel P. Berrange wrote:
> > On Thu, Sep 20, 2007 at 03:36:26PM +0200, Dan Kenigsberg wrote:
> > > Hi,
> > > 
> > > I saw that using the tablet with Linux guest is possible
> > > http://thread.gmane.org/gmane.comp.emulators.qemu/11516
> > > yet I fail to do that.
> > > 
> > > I managed to compile, configure and load the evtouch X module, but still
> > > there is no movement of the mouse (after I disabled the default X
> > > pointer). I attach my Xorg.0.log for the joy of the readership.
> > 
> > Don't use the evtouch X module. Use the regular 'evdev' module.
> > 
> > Dan.
> 
> Dan, thanks for this info. However, my problem begins earlier than in X
> and using evdev instead of evtouch does not solve it.
> 
> It seems that some Linux guests have problems communicating with the
> tablet device. The most reproducible behavior that I noticed is when
> FC-6 starts: gpm senses the tablet, but only until haldaemon starts.
> After that, I cannot obtain any mouse event (even after stopping
> haldaemon).

By an unfortunate co-incidence I've just hit a similar problem myself. It
turns out QEMU mouse handling is more complex than I realized. QEMU can
export several different input devices to a guest OS, PS/2 mouse, VMWare
mouse, USB mouse, USB EvTouch tablet, USB Wacom tablet. Only one of these
devices will be fed mouse events from the host OS though at any time. The
default is that the most recently 'activated' mouse will get the events.
This starts off being the PS/2 mouse. Certain actions in the guest OS may
cause one or more of the other input devices to activate itself, and thus
claiming control of all input events from the host.

You can see what mice are configured at any time from the QEMU monitor by
typing 'info mice'. The active one has an * next to it.  What I suspect
is happening in your case is that you've configured the USB tablet, but
during initial boot only the PS/2 mouse is activated & GPM is actually
responding to events from the PS/2 mouse no the tablet. Then during boot 
something in HAL (or perhaps X itself) causes the USB tablet to become
active & thus the PS/2 mouse stops getting events. But then it sounds
like neither GPM or X are configured to use the USB tablet either, so
you end up with no movement at all.

So I guess it is probably a matter of suitably configuring Xorg to use
the USB tablet, though I can't remember exact syntax for Fedora Core 6,
in Fedora 7 I have successfully used:

Section "InputDevice"
  Name "Mouse0"
  Driver "evdev"
  Option "Name" "QEMU 0.8.2 QEMU USB Tablet"
  Option "Mode" "Absolute"
EndSection

NB, make sure 'Mouse0' is referenced as the CorePointer in the ServerLayout
section of the config. Also the 'Name' value varies acording to what QEMU
version you have[1] - check /proc/bus/input/devices for exact name seen
by the guest OS

Dan.

[1] Really rather unfortunate - if the QEMU version number were removed 
    from the printable USB device name exposed to guests the config for
    Xorg would be stable across QEMU version.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

[Dan Kenigsberg]

On Tue, Sep 25, 2007 at 11:06:58PM +0100, Daniel P. Berrange wrote:
> 
> By an unfortunate co-incidence I've just hit a similar problem myself. It
> turns out QEMU mouse handling is more complex than I realized. QEMU can
> export several different input devices to a guest OS, PS/2 mouse, VMWare
> mouse, USB mouse, USB EvTouch tablet, USB Wacom tablet. Only one of these
> devices will be fed mouse events from the host OS though at any time. The
> default is that the most recently 'activated' mouse will get the events.
> This starts off being the PS/2 mouse. Certain actions in the guest OS may
> cause one or more of the other input devices to activate itself, and thus
> claiming control of all input events from the host.
> 
> You can see what mice are configured at any time from the QEMU monitor by
> typing 'info mice'. The active one has an * next to it.  What I suspect
> is happening in your case is that you've configured the USB tablet, but
> during initial boot only the PS/2 mouse is activated & GPM is actually
> responding to events from the PS/2 mouse no the tablet. Then during boot 
> something in HAL (or perhaps X itself) causes the USB tablet to become
> active & thus the PS/2 mouse stops getting events. But then it sounds
> like neither GPM or X are configured to use the USB tablet either, so
> you end up with no movement at all.
> 
> So I guess it is probably a matter of suitably configuring Xorg to use
> the USB tablet, though I can't remember exact syntax for Fedora Core 6,
> in Fedora 7 I have successfully used:
> 
> Section "InputDevice"
>   Name "Mouse0"
>   Driver "evdev"
>   Option "Name" "QEMU 0.8.2 QEMU USB Tablet"
>   Option "Mode" "Absolute"
> EndSection
> 
> NB, make sure 'Mouse0' is referenced as the CorePointer in the ServerLayout
> section of the config. Also the 'Name' value varies acording to what QEMU
> version you have[1] - check /proc/bus/input/devices for exact name seen
> by the guest OS
> 

Thanks for your eye-opening response! As you suspected, my guest's
haldaemon activated the USB Tablet mouse and robbed GPM of its mouse
source. And evdev's (?) by-name device selection is so nice comparing to
guessing which /dev/input/event? is used.

However, I still have a usability problem. Do you experience smooth
mouse movement with evdev? I have untolerable cursor movement, unless I
move the mouse very very very slowly. Otherwise, the cursor tends to
keep its horizontal position.

Thanks,

    Dan.