On Sun, 22 Mar 2020 at 09:40, Andrew Hodgkinson <ahodg...@riscosopen.org> wrote:
> 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 there 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 on. 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 RPCEmu window) 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. Peter
_______________________________________________ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
