Mouse not freezing in the background in World of Warcraft Window.

[alkanna]

When I used a RAT5 Mouse (pretty much natively supported) and moved the camera around with right click pushed, it used to hide the cursor and let me move the camera around freely, spinning it around my character as many times as I would. Now with the Corsair Scimitar RGB and ckb-next (built the last version on Sierra with the workaround you pushed 3 days ago), let's say I move the mouse to the right to move the camera, well the mouse appears on my other monitor and once it reaches the right border of that monitor, it will stop, and I won't be able to move the camera anymore. If I move the mouse to the left to move the camera, once the mouse will (it's hidden) reach the left border of my screen, it will also stop, preventing the camera to move further.

This never happened with any other mouse I used on Sierra.

I usually play in Windowed (fullscreen) with VSync disabled, changing these settings around did not help.

Another way to explain it is that when I usually right click and drag around the camera, after moving around and letting go of right click, the cursor would appear in the same exact position I right click dat initially. With my current setup (Scimitar RGB) it actually moved the cursor in the background.

EDIT : Even when I am not running ckb, the problem is still here. Does that mean it's more of a hardware issue ?

Even more interesting : With the two mouses plugged in at the same time, works fine with the RAT5, running into the issue with the Scimitar RGB.

[alkanna]

Anyone got a workaround for that ? It's really only happening with the Scimitar RGB.

[Mikematute]

I am on the same boat as you my friend.
For now, my only work around has been uninstalling the CKB and going with out settings for it.

[alkanna]

So I can't even use the buttons then... There is no internal memory in the non pro version afaik, so I can't set it up then uninstall CKB :(

And wait, without CKB you don't have the issue ?

[jaakkovarjo]

I have this same issue. Really looking forward to this being updated.

[Nueek]

It seems that wow will set the mouse cursor to the centre of your screen when you hold left or right click and then read any changes you make to the mouse and move camera while keeping cursor in still(i think lots of games do this). However with ckb running the mouse still moves to the edge of the screen and you are no longer able to move the camera untill you unclick and start again.

[tatokis]

I've been looking into this, however due to the Apple's poor IOKit documentation I was not able to figure anything out.

[ofBits]

I’ll preface this by saying the below was tested on macOS Sierra 10.12.4.

I had this issue too with the Corsair Scimitar Pro RGB, so I took a look for myself and I believe I’ve found the culprit. The problem lies in the daemon. After some debugging I traced it back to ckb-daemon/input_mac.c, lines 28-37. Not only is that block messing with World of Warcraft, but it’s also causing undesirable behavior when using the accessibility zoom tool built into macOS. If you’re zoomed in and click either mouse button the cursor jumps wildly.

    if((options & kIOHIDSetRelativeCursorPosition) && type != NX_MOUSEMOVED){
        // Hack #2: IOHIDPostEvent will not accept relative mouse coordinates for any event other than NX_MOUSEMOVED
        // So we need to get the current absolute coordinates from CoreGraphics and then modify those...
        CGEventRef cge = CGEventCreate(nil);
        CGPoint loc = CGEventGetLocation(cge);
        CFRelease(cge);
        location.x = floor(loc.x + ev->mouseMove.dx);
        location.y = floor(loc.y + ev->mouseMove.dy);
        options = (options & ~kIOHIDSetRelativeCursorPosition) | kIOHIDSetCursorPosition;
    }

I haven’t fully isolated the cause here because in the end it wasn’t necessary, but I believe the issue lies with the use of CoreGraphics to get absolute coordinates. However, after some testing I don’t really see why this block of code is necessary. I couldn’t replicate a scenario where IOHIDPostEvent would not accept relative coordinates, no matter what mouse event triggered it. In the end I just commented this block out, rebuilt the daemon, and the mouse worked as expected. The issues in WoW and with accessibility zoom were gone.

It is possible that Apple made a change in Sierra so that now IOHIDPostEvent works with relative mouse coordinates no matter what the triggering event is, but I have no way to test this and I didn’t run across anything suggesting such when researching the issue. I’d like to verify that this doesn’t break backwards compatibility with older macOS or OS X installations before making it a pull request, so any help would be greatly appreciated, but at least for any Sierra installations it seems this hack is doing more harm than good right now.

[cjeffr]

I am having this exact issue as well, but as I'm a fairly inexperienced programmer I can't figure out how to apply the fix provided by @ofBits . Could someone provide me either the recompiled daemon with the section commented out or instructions as to how I can do it myself? Please?

[jaakkovarjo]

Thanks ofBits, was great to see someone looking into this. Hopefully you'll get this merged soon.

[ofBits]

I had an opportunity to test the modified daemon on a Mac running 10.10.5 and I've confirmed that things are broken without this hack there. Since we need to keep this hack in place for anything prior to Sierra the simplest solution is to use compile-time macros. The limitation of course is that you'll need to compile a version for >= 10.12 as well as one for < 10.12 if you wish to offer pre-compiled downloads. Making a run-time decision to use the hack or not would be ideal (depending on implementation; we don't want this check being performed on a loop), but I am not aware of a simple way to pull the OS version at run-time and don't want to add libraries just to handle it. Doing this at compile-time feels right to me personally.

For anyone interested, modifying the code as follows worked well for me. I will try to submit a pull request with this change as soon as I can.

#if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_12
    if((options & kIOHIDSetRelativeCursorPosition) && type != NX_MOUSEMOVED){
        // Hack #2: IOHIDPostEvent will not accept relative mouse coordinates for any event other than NX_MOUSEMOVED
        // So we need to get the current absolute coordinates from CoreGraphics and then modify those...
        // No longer required in macOS >= 10.12
        CGEventRef cge = CGEventCreate(nil);
        CGPoint loc = CGEventGetLocation(cge);
        CFRelease(cge);
        location.x = floor(loc.x + ev->mouseMove.dx);
        location.y = floor(loc.y + ev->mouseMove.dy);
        options = (options & ~kIOHIDSetRelativeCursorPosition) | kIOHIDSetCursorPosition;
    }
#endif

[jaakkovarjo]

I'm running high sierra 10.13 and this fix doesn't seem to work.

I've tried commenting out the code mentioned above and using the compile time macro given. After this i run the quickinstall script and it finishes succesfully and ckb is installed. When i then try the mouse in WoW the result is still the same, mouse does not freeze in the background.

[jaakkovarjo]

i must make a correction. I'm not that familiar with coding in mac. If i comment out that line and restart, this will actually fix the problem. please ignore my last post. the compile time macro does not work for me thou. My apologies for the spam.

[ofBits]

Hi @jaakkovarjo,

Sorry about such a late reply, I am still working on nailing down this fix but have been quite busy this past month.

So I made a bit of a mistake. The issue is that the compiler is setting ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED based on the QMAKE_MACOSX_DEPLOYMENT_TARGET environment variable set in ckb-daemon/ckb-daemon.pro, and that drives MAC_OS_X_VERSION_MIN_REQUIRED. Changing QMAKE_MACOSX_DEPLOYMENT_TARGET to 10.12 fixes this, but that requires code modification prior to compiling which is what I am trying to avoid.

I've come up with a new solution that should work correctly for the specific mac OS that it is compiled on.

You'll need to add the following to ckb-daemon/ckb-daemon.pro, I've added it after line 24.

macx {
    CKB_OSX_HACK2 = `echo ${OSTYPE:6}`
    lessThan(CKB_OSX_HACK2, 16) {
        DEFINES += CKB_OSX_HACK2
    }
}

Then modify the previous code block in ckb-daemon/input_mac.c to the following.

#ifdef CKB_OSX_HACK2
    if((options & kIOHIDSetRelativeCursorPosition) && type != NX_MOUSEMOVED){
        // Hack #2: IOHIDPostEvent will not accept relative mouse coordinates for any event other than NX_MOUSEMOVED
        // So we need to get the current absolute coordinates from CoreGraphics and then modify those...
        // No longer required in macOS >= 10.12
        CGEventRef cge = CGEventCreate(nil);
        CGPoint loc = CGEventGetLocation(cge);
        CFRelease(cge);
        location.x = floor(loc.x + ev->mouseMove.dx);
        location.y = floor(loc.y + ev->mouseMove.dy);
        options = (options & ~kIOHIDSetRelativeCursorPosition) | kIOHIDSetCursorPosition;
    }
#endif

When you compile it should now detect which mac OS you are on and include the hack only for versions prior to Sierra.

[tatokis]

ckb-next/ckb-next#28