DOS mouse.com implementations broken

[NattyNarwhal]

When we enable absolute positioning, it hoses the PS/2 relative packets coming out, because you need to check the VMware backdoor instead. This means that a DOS program will just get an endless stream of moving the mouse to the bottom right as the mouse moves. (This is the same behaviour I saw in Windows when I got the absolute positioning mode working but didn't change the interrupt handler yet.)

I can reproduce this running CuteMouse before starting Windows, along with its mousetst.com. (Windows doesn't seem to bother using the mouse.com implementation itself.)

There are two solutions I'm guessing:

1. Implement a VMD that switches it to relative when entering a full-screen DOS application and back to absolute when exiting full-screen DOS. Would solve VMD for enhanced mode #3.
2. Implement a VMware absolute mouse.com. I believe the mouse API actually deals with absolute mice and relative mice are implemented on top of this, but it's based on pixel coordinates IIRC. Something else entirely, and also arguably a useful project.

Not sure what I'd implement.

[t9999clint]

touch screens and stylus inputs did exist for ms-dos. They were just not very widely used.
It's definately possible, but I doubt it'd be simple

[NattyNarwhal]

FWIW: I think if I'm reading the VMD source correctly, I think it may be possible to implement a 33h provider entirely from it, instead of deferring to an installed one?