Pointer warps on click with tablet emulation

[arcanist]

WinUAE 5.1.0, Wacom Intuos tablet, tablet emulation enabled, mousehack enabled. OS 3.2 with RTG and 3.1 with native.

This configuration almost works perfectly. When I depress the left or right "mouse" buttons, however, the pointer warps to a location several hundred pixels to the right and down and then immediately warps back. The same happens when releasing the button.

I figured some bad input events were being fed through mousehack and captured a log with -tabletlog 7, below. But it looks OK at a glance. The anomalous warps occur somewhere around the 'tablet: B=00000002/0 p=1' lines.

Happy to do some digging through the code but would appreciate any pointers on where to look.

tablet: X=863 y=428 z=1023 ax=85 ay=175 az=0
tablet: B=00000000 f=00000000 x=13800 y=21083 p=0 (1200,620,0)
tablet: B=00000000 f=00000000 x=13801 y=21083 p=0 (1180,620,0)
tablet: X=863 y=428 z=1023 ax=83 ay=175 az=0
tablet: B=00000002 f=00000000 x=13801 y=21083 p=0 (1180,620,0)
tablet: B=00000002 p=1
tablet: X=863 y=428 z=1023 ax=83 ay=175 az=0
tablet: B=00000002 f=00000000 x=13801 y=21077 p=0 (1180,620,0)
tablet: X=863 y=429 z=1023 ax=83 ay=175 az=0
tablet: B=00000002 f=00000000 x=13801 y=21073 p=0 (1180,620,0)
tablet: B=00000002 f=00000000 x=13801 y=21066 p=0 (1180,620,0)
tablet: B=00000002 f=00000000 x=13801 y=21059 p=0 (1180,620,0)
tablet: X=863 y=430 z=1023 ax=83 ay=175 az=0
tablet: B=00000002 f=00000000 x=13801 y=21052 p=0 (1180,620,0)
tablet: B=00000002 f=00000000 x=13801 y=21045 p=0 (1180,620,0)
tablet: X=863 y=431 z=1023 ax=83 ay=175 az=0
tablet: B=00000002 f=00000000 x=13801 y=21038 p=0 (1180,620,0)
tablet: B=00000002 f=00000000 x=13801 y=21030 p=0 (1180,620,0)
tablet: X=863 y=432 z=1023 ax=83 ay=175 az=0
tablet: B=00000002 f=00000000 x=13801 y=21024 p=0 (1180,620,0)
tablet: B=00000002 f=00000000 x=13801 y=21019 p=0 (1180,620,0)
tablet: B=00000002 f=00000000 x=13801 y=21015 p=0 (1190,630,0)
tablet: X=863 y=433 z=1023 ax=84 ay=178 az=0
tablet: B=00000002 f=00000000 x=13801 y=21011 p=0 (1190,630,0)
tablet: B=00000002 f=00000000 x=13801 y=21007 p=0 (1190,630,0)
tablet: B=00000002 f=00000000 x=13801 y=21005 p=0 (1170,630,0)
tablet: X=863 y=433 z=1023 ax=82 ay=178 az=0
tablet: B=00000002 f=00000000 x=13799 y=21004 p=0 (1170,630,0)
tablet: X=862 y=433 z=1023 ax=82 ay=178 az=0
tablet: B=00000002 f=00000000 x=13796 y=21003 p=0 (1170,630,0)
tablet: B=00000002 f=00000000 x=13794 y=21003 p=0 (1160,630,0)
tablet: B=00000002 f=00000000 x=13792 y=21003 p=0 (1160,630,0)
tablet: B=00000002 f=00000000 x=13791 y=21003 p=0 (1160,630,0)
tablet: B=00000002 f=00000000 x=13790 y=21003 p=0 (1160,630,0)
tablet: B=00000002 f=00000000 x=13789 y=21003 p=0 (1180,620,0)
tablet: X=862 y=433 z=1023 ax=83 ay=175 az=0
tablet: B=00000002 f=00000000 x=13789 y=21013 p=0 (1180,620,0)
tablet: B=00000000 f=00000000 x=13789 y=21013 p=0 (1180,620,0)
tablet: B=00000000 p=1
tablet: X=862 y=433 z=1023 ax=83 ay=175 az=0
tablet: B=00000000 f=00000000 x=13789 y=21032 p=0 (1180,620,0)
tablet: X=862 y=431 z=1023 ax=83 ay=175 az=0

[Toni Wilen]

Add also following command line parameters: "-inputlog 2 -inputdevicelog -1"
(-inpulog 2 = log host mouse events)

Does it show anything interesting when it jumps?

[arcanist]

There are no other input events at the time.

I've managed to track this down some way. I wrote an input handler to dump the events Intuition sees and this is happening:

• While the pen moves there are continuous NEWTABLET events with the correct position
• When a button is depressed or released a RAWMOUSE event is generated. However, the ie_x/ie_y fields contain the last values the mouse was moved to. i.e. If I move the mouse and then press the pen button I see these numbers update. Otherwise they do not change and are wrong.

I'm currently deciphering the code just beneath .yestablet in filesys.asm, which looks like it should update these fields.

Edit: Here it is! Now the pen works perfectly. filesys.asm is adding IntuitionBase->MouseX/Y to these values.

(A remaining problem is the mouse moves haphazardly in tablet emulation mode and the buttons don't work. I'm not sure if that's expected, so I might poke around that as well.)

diff --git a/inputdevice.cpp b/inputdevice.cpp
index f8cde0e5..945626bb 100644
--- a/inputdevice.cpp
+++ b/inputdevice.cpp
@@ -2917,6 +2917,11 @@ void inputdevice_tablet (int x, int y, int z, int pressure, uae_u32 buttonbits,
 		p[MH_BUTTONBITS + 2] = buttonbits >>  8;
 		p[MH_BUTTONBITS + 3] = buttonbits >>  0;
 
+		p[MH_ABSX] = 0;
+		p[MH_ABSX + 1] = 0;
+		p[MH_ABSY] = 0;
+		p[MH_ABSY + 1] = 0;
+
 		if (inproximity < 0) {
 			p[MH_INPROXIMITY] = p[MH_INPROXIMITY + 1] = 0xff;
 		} else {

[Toni Wilen]

I am not sure how that can fix it, now ie_xy coordinates would be always 0,0. (It is actually ibase->View.DxOffset/DyOffset that is subtracted from coordinates, not MouseX/MouseY)

It should work correctly if ibase->MouseX/MouseY is copied to ie_xy when in tablet mode.

Does https://www.winuae.net/files/b/winuae.7z work? (which has above change)

[arcanist]

Originally Posted by Toni Wilen

I am not sure how that can fix it, now ie_xy coordinates would be always 0,0. (It is actually ibase->View.DxOffset/DyOffset that is subtracted from coordinates, not MouseX/MouseY)

It should work correctly if ibase->MouseX/MouseY is copied to ie_xy when in tablet mode.

Does https://www.winuae.net/files/b/winuae.7z work? (which has above change)

That's odd. I checked the Intuition events and you're right.

With my change the RAWMOUSE ie_xy fields are always zero. This works. With your change the pointer warps to a position exactly 2*pen_xy. i.e. Intuition is interpreting these as relative movements.

Using the mouse instead I see both RAWMOUSE events and POINTERPOS events, the latter doing the correct movement. The RAWMOUSE ie_xy is non-zero and causes the same warping effect.

I'm not actually sure where the RAWMOUSE behavior is documented.

[Toni Wilen]

Originally Posted by arcanist

With my change the RAWMOUSE ie_xy fields are always zero. This works. With your change the pointer warps to a position exactly 2*pen_xy. i.e. Intuition is interpreting these as relative movements.

Weird.. There is IEQUALIFIER_RELATIVEMOUSE but that bit is not set.

Ah, it always also sends IECLASS_POINTERPOS even when in tablet mode (IECLASS_NEWPOINTERPOS). This event probably is handled as relative (ie_Qualifier is queried).

winuae.7z updated, IECLASS_POINTERPOS skipped if tablet mode (note that you might get old winuae.7z, if it happens, append ?<something randon> at the end of url to bypass cached data.

Mouse driver and tablet mode should be handled separately... This also explains why they don't want to work very well when both modes are enabled at the same time.

[arcanist]

Originally Posted by Toni Wilen

Weird.. There is IEQUALIFIER_RELATIVEMOUSE but that bit is not set.

Ah, it always also sends IECLASS_POINTERPOS even when in tablet mode (IECLASS_NEWPOINTERPOS). This event probably is handled as relative (ie_Qualifier is queried).

I didn't see any POINTERPOS events (or NEWPOINTERPOS except NEWTABLET subclass) with the previous build. The current build (I added ? to the URL to be safe) behaves the same.

Here's a log of the events received when the pen button is pressed and the pointer jumps:

IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x0
IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x0
IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x0
IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x0
IECLASS_RAWMOUSE: X=457 Y=166 CODE=0x68 QUAL=0x4000
IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x4000
IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x4000
IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x4000
IESUBCLASS_NEWTABLET: SX=0 SY=0 SXF=0 SYF=0 TX=999 TY=404 RX=2793 RY=1746 QUAL=0x4000

No relative qualifiers there. This is the mouse being moved with the pointer jumping a lot:

IECLASS_RAWMOUSE: X=122 Y=120 CODE=0xff QUAL=0x8000
IECLASS_RAWMOUSE: X=120 Y=120 CODE=0xff QUAL=0x8000
IECLASS_RAWMOUSE: X=240 Y=240 CODE=0xff QUAL=0x8000
IECLASS_POINTERPOS: X=445 Y=250 CODE=0x0  QUAL=0x0
IECLASS_POINTERPOS: X=446 Y=252 CODE=0x0  QUAL=0x0
IECLASS_RAWMOUSE: X=120 Y=120 CODE=0xff QUAL=0x8000
IECLASS_POINTERPOS: X=447 Y=252 CODE=0x0  QUAL=0x0
IECLASS_RAWMOUSE: X=120 Y=120 CODE=0xff QUAL=0x8000
IECLASS_RAWMOUSE: X=120 Y=120 CODE=0xff QUAL=0x8000
IECLASS_POINTERPOS: X=448 Y=252 CODE=0x0  QUAL=0x0
IECLASS_RAWMOUSE: X=120 Y=120 CODE=0xff QUAL=0x8000

That one does have the relative bit set, so I'd expect that behavior.

Edit: I wrote a program to inject RAWMOUSE events. It does appear Intuition ignores the relative qualifier bit and always treats these events as relative. Perhaps one option is to set IEQUALIFIER_RELATIVEMOUSE and set ie_xy to 0. Then other input handlers can interpret the event correctly.

[Toni Wilen]

Originally Posted by arcanist

I didn't see any POINTERPOS events (or NEWPOINTERPOS except NEWTABLET subclass) with the previous build. The current build (I added ? to the URL to be safe) behaves the same.

I forgot how this thing works. Yes, tablet mode won't won't generate POINTERPOS events.

Edit: I wrote a program to inject RAWMOUSE events. It does appear Intuition ignores the relative qualifier bit and always treats these events as relative. Perhaps one option is to set IEQUALIFIER_RELATIVEMOUSE and set ie_xy to 0. Then other input handlers can interpret the event correctly.

I guess this is safest option. Done. winuae.7z updated.
(Did you test using OS3.1 or 3.2+?)

[arcanist]

Originally Posted by Toni Wilen

I guess this is safest option. Done. winuae.7z updated.
(Did you test using OS3.1 or 3.2+?)

Yes, this build does work. The pen moves correctly. My input handler still shows IEQUALIFIER_RELATIVEMOUSE is not set on the RAWMOUSE events, if you intended to set it.

I tested this build on 3.1 and 3.2. I also tested RAWMOUSE event injection on 3.1 and 3.2 and both handle these as Mouse_XY += 100. I guess they were meant to originate from a mouse device and were assumed to always be relative.

IECLASS_RAWMOUSE: X=100 Y=100 CODE=0xff QUAL=0x8000
IECLASS_RAWMOUSE: X=100 Y=100 CODE=0xff QUAL=0x0

Thanks for your help, Toni!

[Toni Wilen]

IEQUALIFIER_RELATIVEMOUSE is now set (was set previously but it was overwritten). I also set it in IECLASS_NEWPOINTERPOS event which may or may not be a good idea. Please confirm

[arcanist]

Originally Posted by Toni Wilen

IEQUALIFIER_RELATIVEMOUSE is now set (was set previously but it was overwritten). I also set it in IECLASS_NEWPOINTERPOS event which may or may not be a good idea. Please confirm

Well... the flag is now set, but all the numbers on the NEWTABLET events have gone crazy and the pointer doesn't move.

IESUBCLASS_NEWTABLET: SX=16384 SY=2204 SXF=16398 SYF=14014 TX=16255862 TY=16255802 RX=16255804 RY=16255806 QUAL=0xc000
IESUBCLASS_NEWTABLET: SX=16384 SY=2204 SXF=16398 SYF=14014 TX=16255862 TY=16255802 RX=16255804 RY=16255806 QUAL=0xc000
IESUBCLASS_NEWTABLET: SX=16384 SY=2204 SXF=16398 SYF=14014 TX=16255862 TY=16255802 RX=16255804 RY=16255806 QUAL=0xc000
IECLASS_RAWMOUSE: X=0 Y=0 CODE=0xe8 QUAL=0x8000
IESUBCLASS_NEWTABLET: SX=16384 SY=2204 SXF=16398 SYF=14014 TX=16255862 TY=16255802 RX=16255804 RY=16255806 QUAL=0x8000

[Toni Wilen]

Oops, InputEvent has union fields (ie_xy, ie_addr and ie_dead). Better not clear mouse position fields when ie_addr is in use

[arcanist]

Originally Posted by Toni Wilen

Oops, InputEvent has union fields (ie_xy, ie_addr and ie_dead). Better not clear mouse position fields when ie_addr is in use

Now it's perfect.