Mouse capture issue in fullscreen

[hexaae]

Fullscreen mode, TAB hotkey assigned to “Load Software”, port1=Mouse 1351, port2=joypad1, mouse capture=MMB. When I press MMB to capture mouse in the emulator, and then TAB in fullscreen the file requester pops up, but after I dismiss (cancel) the requester, the pointer gets permanently visible and can cause issues with Windows (unresponsive mouse clicks).

If I keep trying switching fullscreen ↔︎ window and press MMB and TAB to try unlocking the pointer and go back to initial behaviour, Denise 1.1.3.1 can even freeze (AppHang)

[PiCiJi]

Do you use the exclusive full screen? This mode is not designed to operate the Emu via user interface. Only hotkeys work reliable. (but not the ones to open UI)

[hexaae]

Yes, exactly as described: in fullscreen mode I press the hotkey to open UI (in this case the “Load software” file requester I assigned to TAB on the PC), then press ESC to close it but the pointer gets stuck “always on” and unresponsive for Windows. It won’t go away trying to switch to window mode back and forth: the pointer will stay always on and can give troubles to Windows 10. At this point, after trying many things (screen mode switch, capture/uncapture mouse etc.) for a while Denise ended up freezed.

[hexaae]

Maybe force temp switching to windowed when a shortcut involving UI opening is pressed could workaround this problem?

[PiCiJi]

I couldn't tell from your answer whether you're talking about "normal" or "exclusive" full screen. The information is very important, because in the "exclusive" full screen no UI element can be placed over the emulator image, only on the 2nd monitor.
Assuming you're talking about the "exclusive" full screen, does it work in the "normal" full screen? Or does the problem occur equally in both modes?
Can you fix the problem by changing the flow, if so, how. I can't recreate it. I guess you use it differently than I expect, therefore the questions to get closer to the problem.

[hexaae]

Mmmh, it seems again config dependent. Try this old cfg from “problematic games” thread: settings .

Run emu. Set Control > Port1=Mouse1351. Capture mouse with MMB, and switch to fullscreen (F11), open Load software (numpad Enter) to pop-up file requester. Now dismiss it with ESC. Mouse pointer should stay always on, confusing player and Windows…

CASE 2
Another simpler mouse problem (this should be reproducible with any cfg): capture mouse and switch to fullscreen, switch again to windowed. You should see the pointer looks no longer captured (but it is, and Windows is unresponsive to LMB/RMB till you press RMB again to un-capture it).

[PiCiJi]

If the file requester is called in fullscreen, then exited, the mouse cursor only appears if it was visible before the file requester was called. If the mouse cursor was hidden before calling the file requester, it will be hidden again after closing the file requester. Most users do not want to catch the mouse cursor again after requesting a file in fullscreen.

Try another input driver: RawInput or DirectInput

Have you selected a custom refresh rate and resolution when switching to fullscreen? If so, disable it and check again.

your CASE2 doesn’t happen for me either. Maybe there is some other problem, related to your Windows config.

to make sure are you using the latest nightly, instead of the last official release. if not, please use latest nightly build.

[hexaae]

If the mouse cursor was hidden before calling the file requester, it will be hidden again after closing the file requester.

That’s not what happens unfortunately: the mouse pointer, since you open the file requester with the linked cfg (did you try with the “settings” link in previous msg?), stays always on from that moment on, even after you close the requester…

CASE 2 tested also on a completely different PC… it’s easy to test: capture mouse and then switch fullscreen and then windowed again using hotkey: once re-windowed mouse will be visible (expected behaviour should be still invisible since is still captured) and on Windows desktop but unresponsive (input is still stolen by Denise). I can make a short video if you need and my how-to instructions are unclear…

Yes of course I’m using latest nightly.

‌

[PiCiJi]

expected behaviour should be still invisible since is still captured

that you mean with CASE 2. Normally, you switch back to window mode to make an operation. And it would seem like a bug if suddenly the mouse pointer was gone when switching back to Window mode. With a mouse 1351 selected, you can always grab the mouse pointer in Windows mode again. Without a connected device, like a mouse 1351, the mouse pointer can only be captured in fullscreen.

I will check CASE1 tomorrow again.

[hexaae]

it would seem like a bug if suddenly the mouse pointer was gone when switching back to Window mode

Yes, but the pointer is still captured but visible and moveable over Windows 10 UI: if you click over desktop or icons it won’t work, which is confusing… and that’s why I expected it to be always invisible when captured even after being “re-windowed”. IMHO it should be: either still invisible, or visible and automatically uncaptured (yes, you’ll have to recapture it on switching fs<->window).
Both would be coherent but current behavior is confusing.

[PiCiJi]

IMHO it should be: either still invisible, or visible and automatically uncaptured

sure. It’s visible and automatically uncaptured (like expected) when switching back from Fullscreen to Windows.

Have you tried another input driver: menu → options → input → driver

The capturing is different for each driver.

if you click over desktop or icons it won’t work, which is confusing

the behavior is very strange and of course immediately noticeable. Can you rename your configs and thus run the emulator in the delivery state. So we can see if any option is causing that.

[hexaae]

I can confirm that RAWInput works as expected, but using DInput8 (which was default since I launched Denise for the first time) it doesn’t, so the above bug is only in DInput8 (as in the included cfg).

Tested also DInput7÷5 and it does something else : on return to windowed (pressing two times the fullscreen hotkey) pointer stays invisible and coherently is still captured, but… you have to press the (un)capture hotkey (I use MMB) twice to unlock it to Windows 10 and make it visible this time.

Besides the strange behavior, is there any difference between them at emu level (misfeatures)?

[hexaae]

P.S. is it possible to adjust mouse sensitivity (slow down in my case with ROG Strix Carry mouse)?

[PiCiJi]

so the above bug is only in DInput8

you are right. I have tested too much with rawInput, instead of directInput and doesn’t use mouse outside of the emulator windows. Finally I can confirm the bug.

Besides of directInput, the bug only happens when the cursor is captured with the mouse itsself (MMB most cases). It doesn’t happen when mapping mouse capture to keyboard.

It seems to be a driver bug. As as workaround, the mouse grabbing is now delayed 150 ms. it works for me. Could you please check the new nightly, if it works for you too.

Besides the strange behavior, is there any difference between them at emu level (misfeatures)?

no it’s the same code for all direct input versions. mouse capturing is requested from driver.

P.S. is it possible to adjust mouse sensitivity (slow down in my case with ROG Strix Carry mouse)?

there is a slider for analog sensitivity in menu: Control → Configuration, select device

[hexaae]

Works fine only first time with DInput8. If you try again: MMB (capture), F11 (fullscreen/windowed), F11 again, will show the same issue as before.

[PiCiJi]

Yes, after several attempts, it does not always work. I've increased the delay to 200 ms in the latest nightly and it seems to be much more reliable now. Since directInput is deprecated and no longer recommended on Win10, I changed the default version to rawInput. Of course, it only affects people who use the emulator for the first time.

[hexaae]

Thank you, seems ok now after some crazy testing!