Mouse tracking in Windows 95 environment is very poor running EaaSI on Safari on macOS mojave

Deployment: Are you using the hosted EaaSI service, or a local node?
EaaSI Version: This corresponds to the release branch/installer version used to deploy your instance. This information should be available in the Manage Node menu, if accessible

Browser: The name and version of the browser you are using to access the EaaSI UI, if applicable
Safari 14.1.1

Description: Please describe your issue in as much detail as possible, including name + ID of any relevant environments, software or content. You can also attach screenshots or relevant error report files.

Mouse control is a bit wonky. It’s overly sensitive and it is very hard to precisely control the mouse. I’m using keyboard focus a lot more to get more precise selection behavior.

The mouse is practically unusable for things like dragging icons. I’m running this in Safari, and don’t know if that makes a difference.

Are you able to reproduce the issue or did it happen once? What steps can you take to repeat the issue? What did you expect to occur and what was the actual outcome?
It’s pretty much always like this

Urgency: If possible, please give an indication of how urgently the issue needs to be addressed - is there a timeline or deadline (e.g. upcoming demo, researcher request, etc.) that EaaSI support staff should be aware of?
It’s a usability issue. I can work around it, but it makes using EaaSI very painful. Some things like dragging icons around aren’t possible though with this issue.

Hi @hhsu11, I am sorry that you are having a particularly difficult experience with the mouse input.

Generally, yes, we test EaaSI the most thoroughly with Chrome and Firefox, and recommend one of those browsers for best experience and full supported functionality. I would be interested to know if using a browser alternative improves your experience here, but we have encountered low latency in Chrome and Firefox too, so it is likely unrelated.

The EaaSI platform currently serves remote desktop audio and video (of the remote Linux container running the emulator) over HTTP via Apache Guacamole. So, performance can vary a bit depending on factors like your own wifi/ethernet connection, but even under ideal circumstances there will likely always be a degree of lag in user input delivering AV this way. We are working on alternatives to allow for more precise input, including delivering remote desktops via XPRA server rather than Guacamole by default, or even better allowing for video delivery via WebRTC.

Until these bigger, infrastructural improvements are made, mouse input can usually be improved (at least on PC/x86-based environments) by using QEMU’s emulated usb-tablet or usb-mouse device rather than its default emulated PS/2 mouse. Windows 95 unfortunately didn’t have USB capability and drivers until its very last release (Windows 95 C - OSR 2.5) though, so there is not much we can do with any OS earlier than that.

So, this is ultimately related to your other issue with our missing Windows 95 C - OSR 2.5 environment. It is usually my recommendation to use that base Environment for exactly this reason, to improve the latency on the mouse, but as you’ve noted that Environment is missing. I will attempt to address and fix that separately!

Thanks Ethan. I tried Firefox and still saw lag issues, so it was probably the lack of USB drivers in that Windows 95 image. I’ll check again when the Win95 C base environment is available again.

@hhsu11 the “Windows 95 C (OSR 2.5) - Base V2” environment should be available again for you and others to test. In fact, there are now a couple options to compare mouse tracking/input:

  • “Windows 95 C (OSR 2.5) - Base V2” has an emulated PS/2 mouse pointing device and pointer lock enabled; this experience may be similar to the Windows 95 B environment you tried, but making the option available
  • “Windows 95 C (OSR 2.5) - USB Tablet Pointer” replaces the PS/2 mouse with a USB tablet device as mentioned, and with pointer lock disabled

As I mentioned before, it is likely that we will never get the kind of precise input you see running en emulator locally until WebRTC video delivery is incorporated, but you can try both versions, or may even want to experiment with pointer lock enabled/disabled to get the experience you prefer for you and your users. Anecdotally, some folks generally report better experience with Windows 98 environments, so after trying the testing protocol you may want to experiment with the “Windows 98 SE - Base V2” environment(s).

I’m still not seeing the Windows 95 C (OSR 2.5) - Base V2 with emulated PS/2.
I did try the USB Tablet Pointer version.

With this version I was able to install Quattro Pro successfully.
However I did run into a few issues:

The virtual Windows mouse cursor doesn’t line up with my actual Mac mouse cursor. This becomes a problem trying to click something at the edges or corners, such as the C: drive, Start menu, or close box of a window that is full screen. In those cases, it can be impossible to actually click the thing, and I have to resort to keyboard equivalents.

Second, after installing Quattro, it asked me if I wanted to view the ReadMe, which brought up a full screen window. Here I couldn’t close it because of the mouse issue, and I clicked around a bit, and the whole thing froze. I had to exit the emulation completely without saving.
That meant I had to start all over again, and I couldn’t remember which Quattro Pro software I selected to add in the list. Since everyone has added their own, there are a ton of these duplicates in the pulldown.
It shouldn’t matter if they all worked, but some of them don’t.
The floppies are mounted as ISO files in the D: CD-ROM drive instead of being mounted directly in the A: Floppy drive.

I switched to Chrome and eventually was able to select a working one and save the environment.
But I couldn’t find the environment later to later add the 501 Great Games.
And the 501 Great Games I added also only loaded as ISO files and not mounted directly in the D: CD-ROM Drive.