XI2 DirectInput mouse implementation RFC (Tarballed)

[Vitaliy Margolen]

Paul TBBle Hampson wrote:
> On Sun, Apr 19, 2009 at 02:39:43PM -0600, Vitaliy Margolen wrote:
>> Paul TBBle Hampson wrote:
>>> On Sun, Apr 19, 2009 at 10:48:11AM -0600, Vitaliy Margolen wrote:
>>>> Paul TBBle Hampson wrote:
>>>>> On Sun, Apr 19, 2009 at 12:46:20PM +0200, Stefan Dösinger wrote:
>>>>>> Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson:
>>>>>>> I've thrown together a rather-rough-but-working-in-a-limited-sense
>>>>>>> implementation of XInput2-based DirectInput.
>>>>>>> * Doesn't check for XInput2.h, so it won't build without it. (Laziness)
>>>>>>>   It will _run_ without XInput2, falling back to the current dinput
>>>>>>>   WndProc hooks even if compiled with XInput2 support.
>>>>>> I'm not that much into all the input code, but I always understood it the way 
>>>>>> that dinput should always use WndProc hooks, and winex11.drv implements the 
>>>>>> relative movement part either with XI2 or warping if XI2 is not available. 
>>>>>> Ie, there should be no difference between XI2 and legacy operation in 
>>>>>> dinput.dll. That would, I think, make native dinput work as well as the 
>>>>>> builtin one, and help apps that rely on hooks the same way native dinput 
>>>>>> does(if there are any).
>>>>>> The problem is that this means the warping has to be moved to winex11, which 
>>>>>> is something Vitaliy tried before and failed
>>>>>> I could be entirely wrong with that though. And I have no idea how that would 
>>>>>> affect mouse grabbing, or window focus issues etc.
>>>>> A WndProc hook can only work for Foreground-mode DI. In background mode,
>>>>> you still expect to get movement messages without being in a position to
>>>>> receive WM_MOUSEMOVE or WM_KEYPRESS.
>>>> Not necessarily. Hook is for raw mouse & keyboard events, and they are being
>>>> generated by the devices themselves. On native this works regardless of
>>>> where the pointer is.
>>> OK, I'm a little confused. What message is sent on native to all windows
>>> (or at least all windows with a DI Background Acquire on the mouse?) for
>>> a WndProc hook on the Acquiring process to handle?
>> WndProc hook is strictly to detect focus losses. The actual input comes from
>> LL_HOOKs: WH_KEYBOARD_LL & WH_MOUSE_LL.
> 
> I think I understand now.
> 
> So we really don't want to touch dinput at all, but instead just use XI2
> to feed the WH_*_LL hooks and let the existing DI code turn those hook
> inputs into event queue entries as it does now.
That's the goal. But it won't be an easy thing to do. For now (testing XI2)
we might make a special interface between dinput and x11drv.

>>> Which explains why Ventrilo in DI mode can't get keyboard
>>> input even when different Wine applications are in the foreground.
>> This is not true. You probably running then from different prefixes.
> Nope, they were the same prefix. The exact same command with my Wine
> build produced the correct behaviour.
I'm talking about WINEPREFIX (default ~/.wine).

> Actually, I just checked, and it's only movement that's being lost.
That sounds about right. Move notify aren't delivered to windows that's not
under the pointer.

> I'm probably wrong about Ventrilo. I had this vague recollection that it
> only worked with other Wine programs in non-DI mode...