Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
> on a system without XInput2.

It will break dinput, we rely on the clip rectangle being reset.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Vitaliy Margolen]

On 03/26/2012 06:14 AM, Alexandre Julliard wrote:
> Dmitry Timoshkov  writes:
> > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
> > on a system without XInput2.
>
> It will break dinput, we rely on the clip rectangle being reset.

I'd say it again, dinput should not warp mouse under any circumstances. 
Also, there is such a thing as non-exclusive background mode.

Vitaliy.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Alexandre Julliard]

Vitaliy Margolen  writes:
> On 03/26/2012 06:14 AM, Alexandre Julliard wrote:
> > Dmitry Timoshkov  writes:
> > > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
> > > on a system without XInput2.
> >
> > It will break dinput, we rely on the clip rectangle being reset.
>
> I'd say it again, dinput should not warp mouse under any
> circumstances. Also, there is such a thing as non-exclusive background
> mode.

I fail to see how this is relevant here, care to explain?

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Vitaliy Margolen]

On 03/26/2012 08:15 AM, Alexandre Julliard wrote:
> Vitaliy Margolen  writes:
> > On 03/26/2012 06:14 AM, Alexandre Julliard wrote:
> > > Dmitry Timoshkov   writes:
> > > > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
> > > > on a system without XInput2.
> > >
> > > It will break dinput, we rely on the clip rectangle being reset.
> >
> > I'd say it again, dinput should not warp mouse under any
> > circumstances. Also, there is such a thing as non-exclusive background
> > mode.
>
> I fail to see how this is relevant here, care to explain?

If Dmitry fixes a real bug that means dinput shouldn't depend on broken 
behavior. And I'm questioning that exact behavior which shouldn't have been 
there in the first place. Dinput's exclusive mode works regardless of what 
ClipCursor is set to.

Vitaliy.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Alexandre Julliard]

Vitaliy Margolen  writes:
> If Dmitry fixes a real bug that means dinput shouldn't depend on
> broken behavior. And I'm questioning that exact behavior which
> shouldn't have been there in the first place. Dinput's exclusive mode
> works regardless of what ClipCursor is set to.

Of course the behavior is not identical to Windows, but that's because
we can't intercept mouse events under X11 at the level where dinput
would have to do it.

If you have suggestions on how to do this differently please explain
them. Just claiming "it's wrong because it's not like Windows" is not
helpful in this case.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Vitaliy Margolen]

On 03/27/2012 02:29 AM, Alexandre Julliard wrote:
> Vitaliy Margolen  writes:
>
> If you have suggestions on how to do this differently please explain
> them.

Dinput needs to talk to x11drv directly to get xi2 events. Same for requests 
to clip cursor in exclusive mode. The current method of using hooks can stay 
for backwards compatibility.

This can also apply to keyboard events for dinput as well. They main issue 
here is that you need a thread not directly attached to any window pulling 
all X's events. Dinput already have one such thread. You just need to let it 
talk to X.

Vitaliy.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Alexandre Julliard]

Vitaliy Margolen  writes:
> Dinput needs to talk to x11drv directly to get xi2 events. Same for
> requests to clip cursor in exclusive mode. The current method of using
> hooks can stay for backwards compatibility.

I'm not at all convinced that this would be an improvement, particularly
since you still need the events to follow the normal path for apps that
don't use dinput.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Vitaliy Margolen]

On 03/27/2012 08:04 AM, Alexandre Julliard wrote:
> Vitaliy Margolen  writes:
> > Dinput needs to talk to x11drv directly to get xi2 events. Same for
> > requests to clip cursor in exclusive mode. The current method of using
> > hooks can stay for backwards compatibility.
>
> I'm not at all convinced that this would be an improvement, particularly
> since you still need the events to follow the normal path for apps that
> don't use dinput.

In exclusive mode dinput consumes those events - they should not be making 
it to the actual application. So it's not a problem there. In background 
mode they are duplicated - again not an issue.

It's a separate data feed into dinput of key press/releases and relative 
position changes - gets rid of all the complexity related to absolute -> 
relative calculations. And it's a possible source for RawInput whenever it 
will be implemented. It can receive background kbd & mouse events as well.

Vitaliy.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Alexandre Julliard]

Vitaliy Margolen  writes:
> On 03/27/2012 08:04 AM, Alexandre Julliard wrote:
> > Vitaliy Margolen  writes:
> > > Dinput needs to talk to x11drv directly to get xi2 events. Same for
> > > requests to clip cursor in exclusive mode. The current method of using
> > > hooks can stay for backwards compatibility.
> >
> > I'm not at all convinced that this would be an improvement, particularly
> > since you still need the events to follow the normal path for apps that
> > don't use dinput.
>
> In exclusive mode dinput consumes those events - they should not be
> making it to the actual application. So it's not a problem there. In
> background mode they are duplicated - again not an issue.

The point is that we need to send the events to the server and to the
hooks anyway, so dinput might as well get them from there instead of
having its own back channel.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Dmitry Timoshkov]

Alexandre Julliard  wrote:
> > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
> > on a system without XInput2.
>
> It will break dinput, we rely on the clip rectangle being reset.

Is that a way how dinput detects xinput2 support? Or is that a general
approach to detect if a driver supports mouse clipping? How did it work
before?

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Is that a way how dinput detects xinput2 support? Or is that a general
> approach to detect if a driver supports mouse clipping? How did it work
> before?

It's used to detect that xinput2 is not supported.

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Dmitry Timoshkov]

Alexandre Julliard  wrote:
> > Is that a way how dinput detects xinput2 support? Or is that a general
> > approach to detect if a driver supports mouse clipping? How did it work
> > before?
>
> It's used to detect that xinput2 is not supported.

Apparently dinput shouldn't rely on this, but I don't see what to use
instead. How did it work before?

winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Alexandre Julliard  wrote:
> > > Is that a way how dinput detects xinput2 support? Or is that a general
> > > approach to detect if a driver supports mouse clipping? How did it work
> > > before?
> >
> > It's used to detect that xinput2 is not supported.
>
> Apparently dinput shouldn't rely on this, but I don't see what to use
> instead. How did it work before?

It didn't clip, and it obviously didn't need to detect the lack of
xinput2, since we didn't support it...