Cursor drift when ofToggleFullscreen(); and ofHideCursor(); are called on Linux

[DanBennettDev]

This issue occurs in ofv0.10.1 Linux64 gcc6release

When ofToggleFullscreen() and ofHideCursor() are both on, mouse position behaviour, in calls to e.g. ofGetMouseX(), ofGetMouseY(), is incorrect.

Specifically, in the Y axis (and maybe X also - not confirmed), forward movement seems to be scaled slightly higher than backward movement - e.g. if I move the mouse 1cm up and then 1cm down, there will be a very small net movement up. This is not noticable in one movement, but over a period of use this causes the cursor to drift upwards. This is not a result of mousing style - several users have replicated it, and I have replicated it by moving the mouse in different ways.

This seems to be due to the behaviour of glfwSetInputMode(windowP,GLFW_CURSOR,GLFW_CURSOR_DISABLED);, called in ofAppGLFWWindow.cpp

minimal example:
In app.h

int counter{0};

In app.c

void ofApp::setup(){
    // Open Mouse
    ofSetFrameRate(50);
    ofToggleFullscreen();
}

//--------------------------------------------------------------
void ofApp::update(){
    if(counter++ % 1000 ==1){
        ofHideCursor();
    } else if (counter % 1000 ==0) {
        ofShowCursor();
    }
}

//--------------------------------------------------------------
void ofApp::draw(){
    ofSetColor(0,0,0);
    ofFill();
    ofSetColor(1,1,1);
    ofDrawCircle({ofGetMouseX(), ofGetMouseY()}, 5.f);
}

With this code, if you move your mouse up and down on the spot repeatedly, never moving beyond 2cm up or down from a reference point. The cursor will rise up the screen, until every 1000th frame, when ofShowCursor() is called - at that point the cursor position resets to match the OS cursor position.

A temporary workaround for some purposes is not to call ofToggleFullScreen(), but to use a launcher script to move to fullscreen, as in this post. This effectively fullscreens and prevents the OS cursor from ever showing, and does not call glfwSetInputMode(windowP,GLFW_CURSOR,GLFW_CURSOR_DISABLED) so the drift does not happen. This would not be a workaround for e.g. 3d cam control style applications.

[DanBennettDev]

more detail on this in case anyone else is suffering with it.

It looks like it may be an OS issue, and possibly device specific.
I accidentally discovered today that the behaviour described above disappears if my mouse settings are changed.

Specifically if I run this
xinput --set-prop "Logitech G300s Optical Gaming Mouse" "libinput Accel Speed" 1

Then the issue goes away. This is Ubuntu 18.04.2 With a Logitech G300s mouse