[Rpcemu] RPCEmu macOS mouse behaviour
rpcemu.howkins at marutan.net
Sun Mar 22 13:14:42 PDT 2020
On Sun, 22 Mar 2020 at 09:40, Andrew Hodgkinson <ahodgkin at riscosopen.org>
> The root problem is within quite strange (I'm being super polite here)
> mouse handling code.
I think the more fundamental issue is that you have issues with your Mac
setup or build system. You are right that two builds with different UUIDs
should not behave differently, but that they do should be investigated. If
I were thinking to diagnose the problem, I'd try the following;
1) Take the working and non working builds to a different Mac and run them
a) If both builds no longer work in full screen, that suggests that Mac OS
stores some meta-data related to UUID and that there's a difference in
settings between the two builds. Finding these settings, understanding them
and possibly setting them on the new build will solve this issue.
b) If the builds work and don't in the same way as your other Mac, that
suggests there's some hard-coded Mac OS workaround for that particular
UUID. If you can't find out why, the quick and dirty workaround is to set
the new build UUID to the same as the old.
I do not have a Mac so cannot suggest anything more specific than to stop
trying to work around the issue in the RPCEmu code.
However here is a quick mouse code primer for those interested.
RPCEmu uses two different sets of mouse handling code
1) "Capture Mouse" also used in "Full Screen" mode. Data from the Host OS
is fed into the relevant hardware registers (quadrature/ps2) of the IOMD
which RISC OS (or any other OS) interprets and moves its mouse.
The data injected is 'relative' coordinates from the Host OS, the amount
moved since the last time the 'mouse' was polled. Real mice only work on
relative movements as they have no concept of the displays they are running
To do this in RPCEmu, the host mouse pointer is hidden, moved to centre of
the window, each time the mouse is polled the difference from that centre
point is recorded and fed into the emulator, and the mouse moved back to
the centre again. (The mouse keeps being moved back to the centre, as we
only receive Host OS 'mouse move' events if the host pointer is over the
2) "Follow Host Mouse". Known internally (and for very good reason) as
"mousehack". RISC OS specific and whilst considerably better than it was (6
major bugs in the last 10 years) it still may have issues for yet to be
discovered usages of the RISC OS mouse API.
It works by intercepting Mouse SWIs used in RISC OS and directly injecting
results from the Host OS into the return values. It bypasses all of RISC
OS's low level handing of the mouse hardware.
The data injected in the return values of the SWIs are absolute values
(Host units converted for OS units, eigen values, and the fact the Y axis
goes the other way) as those are what the systems calling those SWIs expect.
Please note, "mousehack" still requires the support of the Host OS to move
the Host mouse pointer, as this is used when RISC OS uses a 'mouse bounding
box' such as error boxes that constrain the pointer to the error box.
You correctly note we use a heuristic to determine eigen values for the
display and mouse. Eigen values are entirely a RISC OS concept, the VIDC
hardware doesn't know about them.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the RPCEmu