Question about WinUAE virtual mouse driver.

hceline · 02 January 2023, 20:15

I'm wondering, how far up the input stack does the "virtual mouse driver" sit.
Is it so far up at it could have something to do with the behavior described in the last part of this post?
The reason I am asking:
I made a input recording with RudeTaper (http://aminet.net/package/util/misc/RudeTaper) of the behavior described in the first part. The i restarted WinUAE and turned off the "virtual mouse driver", before running the replay in a loop.
This was almost 9 hours ago, and the loop is is still running, without triggering the lockup described in the last part of the other post.

I see three options.
1. My recording does not contain the exact input to trigger the lockup. It might be dependent on what window I click in when entering WinUAE again. Also the recording contains only the inputs left-button down/up and scroll-wheel down/up.
2. RudeTaper inserts it's replay to far up the chain to trigger the lockup.
3. The lockup happening is dependent on WinUAE "virtual mouse driver" being loaded.

-Hagbard Celine

hceline · 03 January 2023, 15:44

After running the same replay with "virtual mouse driver" enabled for 17 hours without the lockup manifesting. I can conclude that of my three options, al-least option 1 and/or 2 are at play.
I got no indication that this is WinUAE related. But since I can not reproduce it without physical input and the "virtual mouse driver" enabled, I got no proof that it isn't either.
If this(this being what window gets the Scroll-Wheel messages) is something "virtual mouse driver" and/or "magic mouse" can not possibly affect, please chime in so I can rule out WinUAE.

Toni Wilen · 03 January 2023, 19:45

Quote:

Originally Posted by hceline

I'm wondering, how far up the input stack does the "virtual mouse driver" sit

It is Amiga side task that uses input.device IND_WRITEEVENT to inject IECLASS_POINTERPOS events. Should be the legal and correct way to do it.

hceline · 03 January 2023, 20:21

Thank you.
And I assume "magic mouse" does nothing more than watch the pointer position to know when to untrap the mouse.
Is this correct?

Toni Wilen · 03 January 2023, 20:48

Quote:

Originally Posted by hceline

Thank you.
And I assume "magic mouse" does nothing more than watch the pointer position to know when to untrap the mouse.
Is this correct?

Yes. It is fully "passive" operation from Amiga side point of view.

02 January 2023, 20:15	#1
hceline Registered User Join Date: Nov 2009 Location: Top of the world Posts: 161	Question about WinUAE virtual mouse driver. I'm wondering, how far up the input stack does the "virtual mouse driver" sit. Is it so far up at it could have something to do with the behavior described in the last part of this post? The reason I am asking: I made a input recording with RudeTaper (http://aminet.net/package/util/misc/RudeTaper) of the behavior described in the first part. The i restarted WinUAE and turned off the "virtual mouse driver", before running the replay in a loop. This was almost 9 hours ago, and the loop is is still running, without triggering the lockup described in the last part of the other post. I see three options. 1. My recording does not contain the exact input to trigger the lockup. It might be dependent on what window I click in when entering WinUAE again. Also the recording contains only the inputs left-button down/up and scroll-wheel down/up. 2. RudeTaper inserts it's replay to far up the chain to trigger the lockup. 3. The lockup happening is dependent on WinUAE "virtual mouse driver" being loaded. -Hagbard Celine Last edited by hceline; 02 January 2023 at 20:17. Reason: Forgot to insert link to post referred.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Multi-Monitor and virtual mouse driver / magic mouse problem	phipslk	support.WinUAE	0	11 January 2022 21:33
Virtual mouse driver not working in AROS	spudje	support.WinUAE	7	23 May 2021 20:39
WinUAE Win10 virtual maschine / mouse problems	tyrel	support.WinUAE	4	17 November 2019 17:50
Mouse click problem with cintiq companion and virtual mouse driver	donmikko	support.WinUAE	9	19 February 2017 11:32
Magic mouse/virtual mouse driver issues	mark_k	support.WinUAE	2	04 December 2012 20:43

03 January 2023, 15:44	#2
hceline Registered User Join Date: Nov 2009 Location: Top of the world Posts: 161	After running the same replay with "virtual mouse driver" enabled for 17 hours without the lockup manifesting. I can conclude that of my three options, al-least option 1 and/or 2 are at play. I got no indication that this is WinUAE related. But since I can not reproduce it without physical input and the "virtual mouse driver" enabled, I got no proof that it isn't either. If this(this being what window gets the Scroll-Wheel messages) is something "virtual mouse driver" and/or "magic mouse" can not possibly affect, please chime in so I can rule out WinUAE.

03 January 2023, 20:21	#4
hceline Registered User Join Date: Nov 2009 Location: Top of the world Posts: 161	Thank you. And I assume "magic mouse" does nothing more than watch the pointer position to know when to untrap the mouse. Is this correct?

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)