Mouse support for VMs

[Andreas Bollhalder]

Hello all

FreeDOS is used more and more in virtual machines. If you
use a mouse, you get the problem when reentering into the
windows of the VM where FreeDOS is running. The mouse
cursors of the host and FreeDOS aren't synchronized.

For this, some VMs support a special type of hardware. In
QEMU and VMware, you have a virtual mouse which reports
absolute coordinates. QEMU also has a USB tablet device.

My main focus is QEMU, as it's free and widely used. I did
some test and research, but unfortunately failed on all
ways I tried :(


============================================================
  Why does I want that ?
------------------------

I'm working on a website, where you can start an instance
of QEMU, which is then accessed by the VNC protocol. It's
like FreeOSZoo or Haiku does. You can try out them without
installing anything. I think, it would be a nice service
for FreeDOS too.


============================================================
  QEMU USB tablet device
------------------------

I tried the drivers from Bret Johnson at
"http://bretjohnson.us". They don't work, because they
need USB support from the BIOS. The BIOS from Bochs which
is used in QEMU doesn't provide that interface. In the
future, SeaBIOS is used instead of the one from Bochs. But
they don't have support for USB too.

I tried the drivers from Georg Potthast at
"http://www.dosusb.net". They don't support a mouse, only
mass storage, printer and serial devices. And they are
neither open source nor free.


============================================================
  QEMU/VMware vmmouse
---------------------

This would be nice to have supported, because they also
allow copy/paste from to host.

But there can't be a real mode driver, because the device
communicates over the registers eax, ebx etc. This are
32-bit registers.

Then I remembered JEMM and its JLMs. But Japheth states in
the readme, that JEMM won't work in a VM. I think, for
QEMU in emulation mode (without KQEMU/KVM), it could work,
because the ring 0 is emulated too.


============================================================
  Legacy device to support absolute coordinates
-----------------------------------------------

Another solution would be to hack an already existing
mouse device for our needs or create our own. But this
requieres we can access the source from the
emulator/virtualizer. For QEMU, this is not a problem.

Hacking an existing mouse to report absolute coordinates
device won't help much, because they work with relative
coordinates. And the values which can be reported are
between 8 and 9 bits. For absoulte coordinates, this would
only work, if the screen resoultion is not higher then
256x256 or 512x512 pixels. Maybe, we can define a new
mouse protocol like PS/2 absolute which supports more bits
to report the position.

Creating our own device can be done. But who want to
design that ?

Does anyone have another idea, or did I overlook something
?

Would be glad to hear your thoughts.

Andreas

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Christian Masloch]

> I tried the drivers from Bret Johnson at
> "http://bretjohnson.us". They don't work, because they
> need USB support from the BIOS. The BIOS from Bochs which
> is used in QEMU doesn't provide that interface. In the
> future, SeaBIOS is used instead of the one from Bochs. But
> they don't have support for USB too.

Requiring BIOS support would defeat the point of USB drivers. Bret's  
drivers don't require any USB support from the BIOS, they only need the  
standard PCI support (Int1A.B1+) and of course an installed host  
controller. Currently, only UHCI controllers ares supported by the  
drivers, but Bret works on the OHCI controller support. (Since all  
EHCI/USB 2.0 controllers are associated with companion UHCI or OHCI  
controllers, UHCI and OHCI support is enough for virtually all host  
controllers.)

> But there can't be a real mode driver, because the device
> communicates over the registers eax, ebx etc. This are
> 32-bit registers.

Real mode allows usage of 32-bit registers. 32-bit memory addressing isn't  
possible in (usual) real mode. These are two different things.

Regards,
Christian

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Andreas Bollhalder]

Hello Christian

Thanks a lot for your reply.

> Requiring BIOS support would defeat the point of USB drivers.
> Bret's drivers don't require any USB support from the BIOS,
> they only need the standard PCI support (Int1A.B1+) and of
> course an installed host controller. Currently, only UHCI
> controllers ares supported by the drivers, but Bret works
> on the OHCI controller support. (Since all EHCI/USB 2.0
> controllers are associated with companion UHCI or OHCI
> controllers, UHCI and OHCI support is enough for virtually
> all host controllers.)

Sorry, I wasn't clear here. Bret's drivers relies on the
PCI BIOS. But I'm not sure, where this is implemented. I
thought it would be included in the Bochs BIOS.

QEMU is emulating a UHCI controller.

> Real mode allows usage of 32-bit registers. 32-bit memory
> addressing isn't possible in (usual) real mode. These are
> two different things.

Thanks for the correction. Yes, you can access the 32-bit
registers. If a TSR does this and you start a program
which does it too, then you have to make sure, that all
32-bit registers are restored. I know of some programs
doing this for faster calculations.

But still, what would be the best option to get an
absolute mouse ?

Andreas

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Christian Masloch]

> Thanks for the correction. Yes, you can access the 32-bit
> registers. If a TSR does this and you start a program
> which does it too, then you have to make sure, that all
> 32-bit registers are restored.

If you access registers from a TSR, and a program accesses them too, you  
have to make sure that all the registers are restored. This simple rule  
applies to the 32-bit registers just as well. There have been faulty TSRs  
that didn't preserve the high parts of the 32-bit registers because their  
programmers failed to understand it.

Regards,
Christian

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel