vmware_video: disable the SET_CURSOR_SHAPE accelerant hook.

[OscarL]

It somehow breaks mouse sharing.

Fixes Works-around #50.

[OscarL]

Tested on both x86_64 and x86_32. Fixes works-around the issue on both, without any noticeable downsides.

[OscarL]

@waddlesplash, with thanks to you for reviewing my other PRs... what do you think about this one?

Personally, this is the one I'm most interested in getting merged, as avoids the most annoying issue I had with VMware. Took me quite a while to figure out what was triggering the mouse sharing getting borked :-D

[waddlesplash]

What do other VMware video drivers do (is X11's still around for reference)?

I guess this was for accelerated mouse. Do we use that feature in this driver? If not then disabling it makes sense.

[OscarL]

Thanks.

Haven't seen other vmware driver's code. Will try to see if can find (and understand) what they do.

What I do find "funny", is that none of the "well known" cursors in Haiku (BCursorID) actually triggers a call to the accelerant's "set cursor shape" function, but "custom" ones do. I documented my findings so far in #50.

[OscarL]

Do we use that feature in this driver?

That's why I...

find it "funny"

because I was under the impression that Haiku didn't used hardware cursors at all. But seems it does depending on the cursor in question?

[OscarL]

What do other VMware video drivers do (is X11's still around for reference)?

Seems xf86-video-vmware's RedefineCursor() structure looks pretty close to our vmware_video's SET_CURSOR_SHAPE().

But other parts of the code mention that the "fifo cursor" is deprecated, and on other places they say they only support 64x64x4 ARGB cursors, so, I'm not sure if the RedefineCursor() is currently used.

(I don't have any VMware Linux VM to test things further there).

[OscarL]

Forced push is just rebasing on top of current master. I doubt I'll be able to do much more on this front (specially not noticing any downsides with having it disabled).