Yes, that is what I meant, I need to convert the coordinates of the mouse pointer to the dX/dY values sent to the emulated hardware in a way that gives a reasonable sensitivity with most Enterprise software.
I think, it's more a "try it" thing
At least I've done that, implementing and trying the result how it "feels". I cannot say there is an 'exact' value. However what I found, that using Xep128 in window and full screen mode, the "scaling" between the mouse-proto-level dx dy should be modified somewhat compared to the situation when it's fullscreen, since in window mode mouse "feels" too sensitive, for obvious reason. Maybe it's of course not the window/full screen topic at all, but on the fact, how big the emulated screen is (I mean on the PC monitor, that is), currently.
If the majority of software with mouse support assumes or supports a certain resolution for dX/dY, for example dX = +16 moves one character to the left, then it is possible to write the emulation in a way that in those software the sensitivity of the emulated mouse matches that of the host OS. That is, if you move the pointer by one character on the screen, then it will also move by one character in the EP software, even if the actual position cannot be matched.
I don't think it would work in general ... Maybe, but for example EP software may be "lazy" to do the check for a while (disk I/O for longer, no mouse check meanwhile) so there will be a difference already. Also, I don't think there is a "standard" of mapping mouse dx/dy values to screen dx/dy, but who knows ... And for me, I would even annoying to see the mouse PC pointer and the EP "drawn" mouse pointer at the same time, to be honest
That's true, that you can disable (PC) mouse pointer just for the emulator window, and you can try "not to grab it", ie you can "pull out" mouse from the emulator window, and you can use it normally in other windows on your host OS, maybe, that would be a benefit ...
The same applies to the mouse wheel, although in that case there might not be a real sensitivity, and it is more like simple up/down buttons that should send +1/-1 as the delta whenever such events are received?
Though, I have code for mouse wheel, honestly, I haven't even tried that ever
I planned a similar feature, while the 1500 us (is that value correct?) timer is active, reading the B6h port returns data from the mouse buffer, otherwise it is the joystick input like before. It would also be possible to send the mouse data on both columns (bits 0 and 1 of port B6h at the same time), if that is of any use and it does not break any software.
Honestly, I am even lazy to understand my own code in Xep128 emu
But my approach was something like checking "mouse pulses" (what is sent over the serial port) and if there is not so much, I treat the read as "joystick scan" otherwise "mouse scan". On joy-1 conflicting I simply use a "veto" variable that "joy is OK". So maybe, it's OK, that you replicate for both of J and K column, and you just need to take care this "veto" stuff in case of a conflict between joy and mouse.
My work was also some kind of try&error process, for example SymbOS didn't worked without some added work-around, what I can't remember too much in details
I mean, if you do this "heuristic" logic, as SymbOS try to "detect" mouse and maybe too "short" period it was for Xep128 to "judge" it as a mouse scan. And if SymbOS fails to "find mouse" it won't use it then, even if it would work on the next msec, for example ...