On Mon, Jan 12, 2009 at 10:35:26AM -0500, Thomas Jaeger wrote:
> Thanks, that fixes the issue. Motion compression is now working, too.
Pushed as 488d45295105daf10ccd17ca93ae6a6f4d0104f1.
Cheers,
Peter
> Peter Hutterer wrote:
> > My gut feeling was that your patch was missing something (the
>
Thanks, that fixes the issue. Motion compression is now working, too.
Peter Hutterer wrote:
> My gut feeling was that your patch was missing something (the
> !sync.playingEvents has been there for ages AFAIK). The real problem is that
> during a device freeze, the coordinates don't get update, an
On Sat, Jan 03, 2009 at 10:31:47PM -0500, Thomas Jaeger wrote:
> Sorry, forgot the attachment.
>
> Thomas Jaeger wrote:
> > The attached patch implements the suggested behavior. I don't think
> > that this violates the spec.
> From c41b2dcfe145022b1a3dba4243ad992e903238f2 Mon Sep 17 00:00:00 200
Sorry, forgot the attachment.
Thomas Jaeger wrote:
> The attached patch implements the suggested behavior. I don't think
> that this violates the spec.
>From c41b2dcfe145022b1a3dba4243ad992e903238f2 Mon Sep 17 00:00:00 2001
From: Thomas Jaeger
Date: Sat, 3 Jan 2009 17:19:55 -0500
Subject: [PATCH
The attached patch implements the suggested behavior. I don't think
that this violates the spec.
> The question was actually about how the core pointer is reporting events
> when they are being replayed after a grab by a different client. Here
> is a part of the xev output in this situation:
>
On Mon, Dec 22, 2008 at 07:31:34PM +0100, Thomas Jäger wrote:
> >> 3. What is the intended behavior of Xinput button grabs with
> >> GrabModeSync? The two devices that I have here behave differently
> >> (xserver 1.5.99.3): The trackpoint will still send motion events
> >> (clearly the more usefu
On Mon, Dec 22, 2008 at 12:20 PM, Peter Hutterer
wrote:
> Yes and no. Devices configured with SendCoreEvents (yes by default) are always
> attached to either VCK or VCP. There's a DeviceControl that may support it,
> though I don't actually know if it works.
Fair enough, I'm going the other route
On Thu, Dec 18, 2008 at 01:30:41PM +0100, Thomas Jaeger wrote:
> Hi,
>
> I've got a few more questions on input behavior.
>
> > The second issue I encountered was a change in XTest behavior. It's not
> > possible anymore for the core pointer and the devices to be in an
> > "inconsistent" state w
Hi,
I've got a few more questions on input behavior.
> The second issue I encountered was a change in XTest behavior. It's not
> possible anymore for the core pointer and the devices to be in an
> "inconsistent" state where a button is pressed on the device but appears
> to be up as far as the c
Daniel Stone wrote:
> On Thu, Dec 11, 2008 at 11:32:57AM -0500, Thomas Jaeger wrote:
>> I'm currently in the process of updating my gesture-recognition
>> application easystroke to reflect the XInput changes in xserver-1.6 and
>> I have a couple of questions about the direction that we're headed.
>
On Thu, Dec 11, 2008 at 11:32:57AM -0500, Thomas Jaeger wrote:
> I'm currently in the process of updating my gesture-recognition
> application easystroke to reflect the XInput changes in xserver-1.6 and
> I have a couple of questions about the direction that we're headed.
>
> The first question is
Hi,
I'm currently in the process of updating my gesture-recognition
application easystroke to reflect the XInput changes in xserver-1.6 and
I have a couple of questions about the direction that we're headed.
The first question is about the behavior under core pointer freezes
caused by passive gra
12 matches
Mail list logo
