You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 4, 2023. It is now read-only.
This wasn't a problem on XP since the support for touchscreens was [virtually?] non-existent, but it would appear that newer versions of Windows exhibit a really annoying behavior: if AntiMicro is controlling a joystick which is configured as a pointing device, the cursor will only appear on-screen if there's also a mouse plugged in. Unplug the mouse, the cursor disappears, although the joystick can still move the pointer (and the user can press the left CTRL button to get Windows to show where the pointer is, but it's just a momentary blip). Plug the mouse back in, the cursor reappears.
The reason for this seems to be that, if there's no mouse plugged in, Windows assumes there's a touchscreen. My guess would be that if AntiMicro can force the joystick device to be recognized with the same ID as a mouse (or just fake that a mouse is plugged in, whether it's associated with the joystick or not), the cursor should stay visible. An option like this probably shouldn't be turned on by default, of course, but it may be the only way for this particular use case to work right on Windows 10 (although it seems that Windows has been set up to do this potentially as far back as 7, maybe even Vista). Fiddling with Windows' configuration options didn't solve it, which is why I'm suggesting it here.
The text was updated successfully, but these errors were encountered:
I'm not sure if it's actually possible for AntiMicro to emit the right signals to fake the HID and allow this all on its own, since it appears to need driver-level finagling to do. But since it may not always be possible to install the above driver to accomplish this, I'll leave this issue open so investigating it won't be forgotten.
Hi @qyot27, nice workaround! Yes, I think it beyond the scope of AntiMicro to emulate hardware. Probably the most we would do is create our own mouse pointer. I'll add your fix to the wiki when I get a chance. Thanks for tracking it down!
AntiMicro is no longer maintained. There were no bigger fixes since 2017.
There is a new recommended version of this app called AntiMicroX.
As a part of cleanup, this issue will be closed and repository will be archived.
If you find this issue relevant also for that new version of application you can create a new issue (or discussion) there (but firstly check it, because many issues of the old app are fixed and there are some new functionalities implemented)
If you will decide to create a new issue for AntiMicroX remember to mention this issue for reference.
This wasn't a problem on XP since the support for touchscreens was [virtually?] non-existent, but it would appear that newer versions of Windows exhibit a really annoying behavior: if AntiMicro is controlling a joystick which is configured as a pointing device, the cursor will only appear on-screen if there's also a mouse plugged in. Unplug the mouse, the cursor disappears, although the joystick can still move the pointer (and the user can press the left CTRL button to get Windows to show where the pointer is, but it's just a momentary blip). Plug the mouse back in, the cursor reappears.
The reason for this seems to be that, if there's no mouse plugged in, Windows assumes there's a touchscreen. My guess would be that if AntiMicro can force the joystick device to be recognized with the same ID as a mouse (or just fake that a mouse is plugged in, whether it's associated with the joystick or not), the cursor should stay visible. An option like this probably shouldn't be turned on by default, of course, but it may be the only way for this particular use case to work right on Windows 10 (although it seems that Windows has been set up to do this potentially as far back as 7, maybe even Vista). Fiddling with Windows' configuration options didn't solve it, which is why I'm suggesting it here.
The text was updated successfully, but these errors were encountered: