hrvach / deskhop

Fast Desktop Switching Device
GNU General Public License v3.0
5.97k stars 168 forks source link

How does your system know it's at the edge of screen 1 and hence, should enter screen 2? #7

Closed 205g0 closed 6 months ago

205g0 commented 6 months ago

Doesn't get really clear from the README. Even if the mouse submitted absolute values, e.g.. x, it doesn't know when the edge of a screen is reached. So, you'd need always software knowing that the mouse is at the edge. But guess I missed something.

205g0 commented 6 months ago

Ok I think I get it: Your device converts to abs. values. But then, I can't lift my mouse and reposition it without moving the mouse cursor. So, the mouse then acts like the pen on a typical Wacom tablet which is also absolute unlike a mouse (or the finger on an iPad), right?

205g0 commented 6 months ago

No, now I get it, the mouse stays relative and your device is kind of a virtual screens with its abs. coordinates catching the crossing.

Whatever, would be great if you could elaborate on this. Just to see if the user faces any compromises compared to a software solution.

205g0 commented 6 months ago

My last comment doesn't make sense, how you should your device know the real screen aspect ratios which it needs to convert to abs. value, otherwise cursor movement is skewed.

hrvach commented 6 months ago

So, your mouse sends "move up by 10", or "move right by 5" messages. Device will read all of them and adjust internal position locations it keeps (0 - 32767 for X and also 0-32767 for Y) and then report those location to the computer which will, in turn, do the mapping to the actual screen, e.g. [0, 32767] -> [0, 1919] for X axis. For now, the offset is the same for both axes (didn't notice much difference in behavior) but making screen ratios configurable is among the planned updates.

Edge of the screen is always 0 (left) and 32767 (right), regardless of the actual resolution - that's taken care by the computer when mapping absolute coords to actual screen geometry.

205g0 commented 6 months ago

For now, the offset is the same for both axes (didn't notice much difference in behavior)

This is interesting and surprising but if it works why not. Is the resolution (32,767) enough to provide a buttersmooth and absolute lag-free experience on high-refresh screens (+144hz) and gaming mice (e.g. 4,000hz polling rate)? Not that everyone would need this, though it's nice, rather to see if the 32,767 is enough for a smooth experience and your chosen hardware is fast-enough for a latency-free operation.

hrvach commented 6 months ago

This is interesting and surprising but if it works why not. Is the resolution (32,767) enough to provide a buttersmooth and absolute lag-free experience on high-refresh screens (+144hz) and gaming mice (e.g. 4,000hz polling rate)? Not that everyone would need this, though it's nice, rather to see if the 32,767 is enough for a smooth experience and your chosen hardware is fast-enough for a latency-free operation.

I don't really know much about gaming gear, my mouse cost 5$ and its polling rate is not high. This would have to be tested to make sure it can even poll that fast. For now it's a pretty basic setup (only boot protocol) but I'm working to expand it and properly parse report protocol in order to offer wider compatibility and features. I'm learning as I go along :)

p0358 commented 6 months ago

Device will read all of them and adjust internal position locations it keeps

Wouldn't this break painfully if the OS forcefully adjusts the mouse position? For example when playing any 3D game, it keeps moving mouse to the center. Or when you fire up Microsoft Paint and use keyboard arrows to move the cursor. Does it account for that at all?

hrvach commented 6 months ago

Device will read all of them and adjust internal position locations it keeps

Wouldn't this break painfully if the OS forcefully adjusts the mouse position? For example when playing any 3D game, it keeps moving mouse to the center. Or when you fire up Microsoft Paint and use keyboard arrows to move the cursor. Does it account for that at all?

If you move the pointer by another means (keyboard, another mouse), then go back to moving the mouse, the pointer will jump to where it was before that movement and simply continue from there. The mouse has no way of knowing if something else moved the cursor.

As for games, the last one I really played a lot was Doom 2, so you can guess I know very little about them. Games will likely need to get a relative mode option. If you are playing a game where super-fine movements, ultrafast polling and super-low latency is required, I'd never go for anything other than plugging the mouse directly.