Hello to the community. I did a search through the virtualization board, and didn't see any posts about this. So, probably this means I'm doing something wrong.
With Previous 4.1 (and whatever version I had before, installed around Nov. 2025), I've found mouse control to feel very odd as I move the mouse a little faster. Very slow movements track precisely, but the faster I move the more the cursor feels like its on ice, or skipping, almost teleporting, by a short distance. It makes for a jerky, hard to visually track mouse cursor.
I assume this has something to do with the "motion speed adjustment" but I have no idea what those numbers mean in relation to mouse movement. I could use advice on setting those values.
I tried many times to improve mouse movement but it is still not perfect. I can't fix this without detailed information on mouse data on real hardware.
If slow movement is OK and acceleration is too aggressive you can try setting the exponential adjustment to some value below 1. I use 0.9.
Hi, Chris! Welcome to NeXTcommunity! I'm a big fan of Stone Tools. Awesome to see you here. :)
The problem is not purely a matter of emulation. Probably the single best help for fixing NeXT mouse acceleration under emulation is GKMouseScaler, which you can get from here (http://archive.nextcommunity.net/peak/apps/preferences/). It adds a control panel that you can use to redefine the operating system's mouse acceleration curve. The default ROC is an ascending line; I find a flatter line works better:
(https://i.imgur.com/7yxiu9q.png)
A flat horizontal line is also pretty effective. This even improves mouse behavior when emulating white hardware, allowing whatever mouse behavior the host OS is using to shine through without any modification; in VirtualBox I actually use a totally flat line for best results.
FWIW the web version of Previous at infinitemac.org completely overrides the mouse coordinates with host system input values. This is probably
very hacky and most likely only works if the addresses used by the OS to store this information are hardcoded in advance, but it's such a huge QoL improvement that
@andreas_g should definitely consider implementing it (and the requisite guest OS version sniffing) as an experimental option anyway, even if just for fully-patched NS3.3 and OS4.2. ;)
@andreas_g Yes, I saw in the release notes over the years that "improved mouse" was a recurring theme. I do appreciate your efforts toward that end and I'll give your recommendation a shot. Slow is fine with me. Well, you know, within reason. ;D
@Rhetorica A fan of Stone Tools in the wild?! I'm humbled, thank you. That control panel looks like a great addition, thanks for the tip. A flat line sounds like the curve, or lack thereof, that I'd hope for, personally. I'll get that installed, pronto!
Quote from: Rhetorica on Mar 19, 2026, 09:07 PMFWIW the web version of Previous at infinitemac.org completely overrides the mouse coordinates with host system input values. This is probably very hacky and most likely only works if the addresses used by the OS to store this information are hardcoded in advance, but it's such a huge QoL improvement that @andreas_g should definitely consider implementing it (and the requisite guest OS version sniffing) as an experimental option anyway, even if just for fully-patched NS3.3 and OS4.2. ;)
This sounds very interesting! Can you point me to the code that handles this?
Quote from: andreas_g on Mar 20, 2026, 05:15 AMThis sounds very interesting! Can you point me to the code that handles this?
The Previous tree for infinitemac.org is here: https://github.com/mihaip/previous/tree/829b8627316985762556720cb0996a4a573cecb7
I'm afraid I don't know the codebase nearly well enough to identify where it is, and my remarks about how it works are purely speculative! Maybe if you do a mass diff against a revision from the same era? Seems like it's from the softfloat branch around a year before you started work on SDL3.
I checked the code and it seems to use the original mouse handling. There is no code to input absolute mouse coordinates.
Hmm. OK, alternate theory: perhaps mouse input on Windows + SDL3 is actually not very performant and I was so accustomed to it that seeing SDL2 Previous running on WebAssembly was like black magic to me. :)
Still, maybe there's a way to do this without disassembling half the operating system. From what I can tell the kernel never actually handles absolute mouse coordinates; that part is left up to some other part of the OS, presumably DPS.
If you were to clone the mouse acceleration function in the emulator, it would be possible to guess how the guest OS believes the cursor has moved, compare it to where the host expects it to be, and to send corrections the next time the mouse device is polled for updates, a bit like how latency compensation code (https://www.ra.is/unlagged/intro.html) code works in multiplayer games. (Though notably the corrections themselves would have to be adjusted for acceleration—basically we'd need an inverse version of the acceleration function, too.)
Of course, it would ideally be a GPL-friendly clean-room (https://en.wikipedia.org/wiki/Clean-room_design) re-implementation of the acceleration function, rewritten from a specification of how it works. The Darwin-0.1 tree on GitHub contains the mouse acceleration code, and I could definitely write up such a spec if you think this seems doable and worth doing.
Just to jump in for a moment so that there aren't any wild goose chases. I tried the Infinite Mac NeXT setup and am seeing precisely the same behavior with the mouse. So, I guess this means its more of a NeXT thing and not so much of an emulator thing. I haven't had a chance to work with it all yet, but will try to make some time this weekend to play around with the GKMouseScaler.
I just committed an improved mouse configuration dialog and some minor improvements to mouse motion handling. Can anyone having issues with the mouse test the latest code and give me some feedback? The code is in r1789, branch_filesharing (SDL3) and branch_softfloat (SDL2) but not yet in trunk.
Note that the values in the dialog only apply to locked mode (cursor locked to window or in fullscreen). I will improve that later if the code works for people in here.
@andreas_g The SDL2 build failed for me because of missing support for nanosleep at sdlhost.c:121:23. I haven't tried making an SDL2 build in a while, so it's not too surprising this flew under the radar. I've updated my build scripts to let me select a branch at checkout so this will be easier to keep up to date in the future, should that be desired.
Windows has its own (deranged, overly complex) method of implementing tiny delays using media timers. Here (https://gist.github.com/scivision/dbbbf33c2faf5a16f31fd6d144adc314) is a polyfill for MSVC. The SDL3 build (branch-filesharing) works as expected... (once I uninstalled GKMouseScaler, anyway.)
As for performance... due to rounding and precision loss, there is some very strange behavior when moving the mouse at slow speeds. Drawing a circle is hardly possible: it clamps to following straight X or Y lines. Speeding up helps somewhat:
spirals.png
(top left: moving mouse slowly, bottom right: moving mouse faster.)
spirals-2.png
left: spiral drawn in Draw.app, Previous filesharing r1789, with slowest possible cursor settings
right: spiral drawn in Microsoft Paint, Windows 10, with same raw mouse input DPI on host
Quality is highly dependent on guest system workload. Mouse behavior on my heavily customized OS4.2 install is a fair bit worse than the same on a virgin NS3.3; in particular, even when drawing tight circles very slowly, the cursor sometimes jumps around 15-20 px diagonally instead of sticking to its vertical and horizontal troughs.
In general I'd say this is an improvement. infinitemac is still a lot better for me in terms of performance than MinGW64+SDL3, probably because it is able to maintain a much higher framerate. I am sure the Mac builds are also a great deal more optimized than the ones produced by my toolchain.
First on the compilation issue:
Does it help to replace this part in sdlhost.c
#if HAVE_NANOSLEEP
#include <errno.h>
#ifdef __MINGW32__
#include <unistd.h>
#else
#include <sys/time.h>
#endif
#endif
#include "host.h"
with this one
#if HAVE_NANOSLEEP
#include <errno.h>
#include <sys/time.h>
#endif
#include "host.h"?
Why did you have to uninstall GKMouseScaler? Did it stop working properly with the latest changes?
Do you think there should be a setting to make the cursor even slower in the guest system or are the issues caused by other things than excessive speed?
@andreas_g: The patch above worked to produce a functioning SDL2 build, but the resulting binary is getting very bad performance; moving the mouse around causes performance to dip from 40 MHz down to 30±3 MHz. Oddly, dragging a window causes the speed to shoot up to 60 MHz ??? — naïvely, I assume this is because of the absence of nanosleep. The mouse in this SDL2 build moves very slowly no matter how much I thrash the cursor around, and regardless of what I set the locked mouse speeds to.
I removed GKMouseScaler because my configuration with it was meant to eliminate mouse acceleration and I wanted to make sure I was not encountering any artifacts caused by it interacting with any changes you may have made to mouse motion handling. However that VM was still very slow, so I abandoned that install entirely for testing purposes and switched to a version of NS3.3 that had never had anything like it installed.
So it was just a header issue. Your system has nanosleep, but for some reason the header with its definition was not included with MinGW. I will fix that in the repository later today.
What speed setting are you using for Previous? 40 MHz with variable speed mode or something custom?
Did you lock the cursor to the window for testing? This is all very strange. I will simplify the configuration with one single set of values for both locked and unlocked mode. I will post here as soon as it is in the repository.
Does the appended patch improve anything?
mouse_patch1.diff
Applying that patch to r1789-softfloat definitely seems to give a more solid basis for comparison. The verdict: movement feels extremely slow and sluggish but is at least smooth so long as the linear speed isn't increased past 2 or so. Looking through the values specified in dlgMouse.c, I'm astonished at how slow all the presets are—these are basically unusable in my environment. Unfortunately, usable linear speeds get very hard to control very quickly because of low time resolution and uneven application of the NeXT mouse acceleration; there's zero consideration for smoothing in their algorithm and it shows. I'm definitely putting GKMouseScaler back in; will report on the results next time.
Clockspeed shown on the emulator's status bar still fluctuates wildly when moving the cursor vs. dragging a window, with similar values to what I mentioned previously.
Is there any way the mouse polling rate can be increased? My native builds of Previous seem to be really struggling with this compared to x86 NEXTSTEP under VirtualBox or infinitemac WASM Previous.
Quote from: Rhetorica on Mar 31, 2026, 01:13 AMThe verdict: movement feels extremely slow and sluggish but is at least smooth so long as the linear speed isn't increased past 2 or so. Looking through the values specified in dlgMouse.c, I'm astonished at how slow all the presets are—these are basically unusable in my environment.
This is weird. Can you post your configuration file?
Attached.
Thank you. It seems I am not able to improve this. Compared to Previous v4.1 is this now better or worse?
Another patch is online. It should fix the issue where the cursor sticked to vertical or horizontal lines (your spiral drawing test).
I am looking for more details on NeXT mice in this discussion (https://nextcommunity.net/forums/index.php?topic=103.msg598#new).
Quote from: andreas_g on Apr 04, 2026, 09:12 AMAnother patch is online. It should fix the issue where the cursor sticked to vertical or horizontal lines (your spiral drawing test).
A big improvement! Though I did find that I had to draw very slowly or the acceleration would cause some skipping:
spiralish.png
Perhaps I still have some use for GKMouseScaler:
spiralish-gk.png
I'm using 1.25 linear and 1.0 exponential in both of the above, r1795-filesharing.
The new 'raw mouse input' option seemed to make the mouse move a bit faster but substantially degraded smoothness so I decided to leave it off.
Greetings NeXT Community!
This is a related issue; at least, for me.
I've setup Previous 4.1 on a Late 2013 Mac Pro (aka Trashintosh) running MacOS Sequoia (via OCLP).; and also, a 2019 MacBook Pro 16" running MacOS Tahoe. Both of them experience the same issue with the mouse not being captured by the Previous emulator window.
On Previous 2.6 the mouse was captured properly by the Previous emulator's window (when using an emulated NeXTDimension card for the desktop GUI). However, under Previous 4.1 the mouse seems to never be "captured" by the emulated NeXTStep window.
This is quite frustrating since the mouse will leave the emulated desktop window before the mouse cursor reaches the edge of the desktop.
Was the mouse capture behavior by the Previous window changed at some point in the evolution of the code base to provide for a more convenient / fluid experience? Is there a runtime setting or compile time flag that I can set to re-establish the "capture" behavior of the emulator vis-a-vis the mouse?
Thanks!
Geek
Quote from: Geek.Trauma on Apr 17, 2026, 05:56 PMGreetings NeXT Community!
This is a related issue; at least, for me.
I've setup Previous 4.1 on a Late 2013 Mac Pro (aka Trashintosh) running MacOS Sequoia (via OCLP).; and also, a 2019 MacBook Pro 16" running MacOS Tahoe. Both of them experience the same issue with the mouse not being captured by the Previous emulator window.
On Previous 2.6 the mouse was captured properly by the Previous emulator's window (when using an emulated NeXTDimension card for the desktop GUI). However, under Previous 4.1 the mouse seems to never be "captured" by the emulated NeXTStep window.
This is quite frustrating since the mouse will leave the emulated desktop window before the mouse cursor reaches the edge of the desktop.
Was the mouse capture behavior by the Previous window changed at some point in the evolution of the code base to provide for a more convenient / fluid experience? Is there a runtime setting or compile time flag that I can set to re-establish the "capture" behavior of the emulator vis-a-vis the mouse?
Thanks!
Geek
On windows when I hit F12 and bring up the menu I click on the "Mouse" menu. I then tick "
Enable auto-locking" but that is on Windows.
Previous-Mouselock.png
@Geek.Trauma Nice to read that Previous still works on the old cylindric Mac Pro. Did you try what pTek recommended? Are there any issues left after enabling auto-locking?
Btw.: If you do not like auto-locking you can also manually lock and unlock the mouse by using the shortcut ctrl-alt-m (an overview on shortcuts is in the Keyboard options dialog).
Anyone following this discussion might be interested in Previous v4.2. For details see the announcement (https://nextcommunity.net/forums/index.php?topic=11.msg653#msg653) in Previous' main thread.
Hi Andreas,
I have followed this project's development since the version 0.x days. I just downloaded the Previous v4.2 binary that you posted for MacOS (Intel and Apple Silicon/aka ARM).
I still get the same behavior that the mouse refuses to lock to the Previous window (on the aforementioned Trashintosh running MacOS Sequoia).
I've never (and still don't) see this behavior with v2.6. Wondering if it might be something with differences between SDL2 vs SDL3? Also, suspecting the lack of support for the Metal 3 API with the AMD GCN drivers that the OCLP boot loader crams back into the MacOS kernel's driver stack so that the desktop GUI isn't dog slow.
Geek
Quote from: ptek on Apr 18, 2026, 04:23 AMOn windows when I hit F12 and bring up the menu I click on the "Mouse" menu. I then tick "Enable auto-locking" but that is on Windows.
Previous-Mouselock.png
I've tried toggling the 'Enable auto-locking' feature. I get the same non-locking behavior both ways.
I suspect that it has something to do with the ("technically" speaking) unsupported hardware on which I am running MacOS Sequoia (i.e. a Late 2013 Trashintosh). Maybe something in the SDL implementation and or the older AMD D300/D500/D700 drivers that OCLP restores back into the kernel's dynamically loaded set of drivers.