Any updates or workarounds on this bug?

Any updates or workarounds on this bug?

Does setting vmmouse.present to false not work anymore? This appears to be a quirk of vmware...?

Any updates or workarounds on this bug?

Does setting vmmouse.present to false not work anymore? This appears to be a quirk of vmware...?

I have the issue with the pen tablet (not in vmware) the values of xrel and yrel are crazy high. I made some hacky workaround for it last night.

If anyone is interested, TLDR; if values are crazy high switch back to non-relative mode.

modified   Engine/Source/ThirdParty/SDL2/SDL-gui-backend/src/video/x11/SDL_x11xinput2.c
@@ -192,6 +192,11 @@ X11_HandleXinput2Event(SDL_VideoData *videodata,XGenericEventCookie *cookie)
                 return 0;  /* duplicate event, drop it. */
             }
 
+            if (relative_coords[0] > 100. || relative_coords[1] > 100.) {
+              SDL_SetRelativeMouseMode(SDL_FALSE);
+              return 0;
+            }
+
             SDL_SendMouseMotion(mouse->focus,mouse->mouseID,1,(int)relative_coords[0],(int)relative_coords[1]);
             prev_rel_coords[0] = relative_coords[0];

Is this a bug in XInput?

Is this a bug in XInput?

I haven't looked at this yet, but I'd bet anything that we are screwing up with devices that report absolute coordinates instead of relative.

(and this may or may not be a separate issue from the vmware thing.)

Yeah, it makes sense that we're not handling absolute coordinates correctly. I moved this to 2.0.24 for investigation.

Ok, looked into this, and we don't check the XIValuatorClass of devices at all, which means we accept absolute coordinates as relative values.

Scratching this together shortly, which I think will fix this issue.

I've pushed an attempt at this, but I can't find my tablet, which might have been thrown out a long time ago, so someone is going to have to tell me if it works.

It definitely still works in the not-absolute-coordinate case, but that's all I can promise here at the moment.

Anyone with a tablet have a chance to see if the latest in revision control fixes this issue? @mika314?

I am too lazy, I have a workaround. It takes forever to rebuild Unreal Engine.

I'm going to kick this out of the milestone and try to find a device for 2.26; in the worst case, we're not any worse off than we were, so I think we're good for 2.24.

I was tracking this down a bit as Unreal Editor is hitting this in TigerVNC, annnd testing this new patch and still running into the same issue. Digging a little more found a few things:

Using xinput test-xi2 --root on my normal X11 server my general events when doing relative work look like:

EVENT type 6 (Motion)
    device: 8 (8)
    detail: 0
    flags: 
    root: 663.55/468.61
    event: 663.55/468.61
    buttons:
    modifiers: locked 0 latched 0 base 0x4 effective: 0x4
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: 673.55
        1: 470.61
    windows: root 0x1e8 event 0x1e8 child 0x2c0000a
EVENT type 17 (RawMotion)
    device: 2 (8)
    detail: 0
    flags: 
    valuators:
          0: 6.00 (3.00)
          1: 2.00 (1.00)

While on TigerVNC:

EVENT type 6 (Motion)
    device: 6 (6)
    detail: 0
    flags: 
    root: 346.00/727.00
    event: 346.00/727.00
    buttons:
    modifiers: locked 0 latched 0 base 0x4 effective: 0x4
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: 328.00
        1: 715.00
    windows: root 0x3b3 event 0x3b3 child 0x240328e
EVENT type 17 (RawMotion)
    device: 2 (6)
    detail: 0
    flags: 
    valuators:
          0: 326.00 (326.00)
          1: 709.00 (709.00)

Which you can see for the RawMotion event... is using Absolute, which can be fine BUT further compounding the issue is:

for (i = 0; i < 2; i++) {
   if (devinfo->relative[i]) {
       processed_coords[i] = coords[i];
   } else {
       processed_coords[i] = devinfo->prev_coords[i] - coords[i];    /* convert absolute to relative */
   }
}
// ...
devinfo->relative[axis] = (v->mode == XIModeRelative) ? SDL_TRUE : SDL_FALSE;

Is True... so the valuator thinks its relative, while event coords are not. I can see the issue using xinput test-xi2, which is not using SDL2.

Im not 100% if all the causes are caused by the same issues here... but seems more related to the x11 server directly (Ive not tried any wayland servers out yet) vs SDL at this point.

So TigerVNC is lying and saying it's relative motion even though they're absolute coordinates?

Yeah looking at bug reports over there, some talk on this (granted this vnc bug is mouse warping, and VNC not being able to hold onto the mouse vs a direct client...)
TigerVNC/tigervnc#619

Ive not looked at their source, though the original bug report here was VMWare stuff not TigerVNC, but we have had issues on Unreal Editor with I think all RDP for Linux soo unsure how related things are to what Im see :)

So just to be clear: is there something we can do here? Or is this strictly a TigerVNC (and/or other VNC servers) issue at this point?

If there's some reasonable way to decide we're being giving absolute coords when it thinks we're getting relative coords, we can put a check in there for that, but I'm not sure how to detect that.

I have this issue with the Wacom tablet.

Also, I noticed Virtual Box, by default, sets Pointing Device to USB Tablet. I am wondering if switching to the mouse may fix the SDL issue.

I've not fully dug enough in to say, and I've only spotted what looks to be an issue with the x11 server and how the mouse devices are being faked through xinput. With regards to TightVNC, Im quite rusty now with x11 but it really seems like something is either not implemented (xinput2 interface, while they say they support it, the devices say they are relative, but return absolute cords... which seems like a bug in the server implementation they are using)

I need to double check, but even though its saying relative, I have a fear/guess that if you hit the edge of a window these events stop reporting. If this is the case, we really cannot work around much here sadly :( ... even faking it using the last known x/y, if no even when pushing right, or even if an event our x/y position against the edge of the window will be the same as the last giving us a 0 +/- :(

Still needs more debugging but its ... quite annoying to debug x11 + remote setups :)