On Wed, Mar 23, 2011 at 6:30 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
On Wed, Mar 23, 2011 at 12:58:21PM -0700, Jason Gerecke wrote:
As I'm working on the X11 wheel mapping, I'm finding a few weird
quirks in the code. I pretty much understand 'how' things work, but
I'm not sure why
Hello, I find it rather inconvenient that the Area Option (rather recent
GIT) appears to depend on the output device and is relative to the
screen area.
Meaning that the same Area Options have different effects when I use two
different screen setups.
Is there a particular reason why that is the
On Thu, Mar 24, 2011 at 12:29 PM, Cedric Sodhi man...@gmx.net wrote:
Hello, I find it rather inconvenient that the Area Option (rather recent
GIT) appears to depend on the output device and is relative to the
screen area.
Meaning that the same Area Options have different effects when I use two
Change oldHwProx to oldCursorHwProx to better refect its use.
Protocol 5 distance starts from the MaxCursorDist (256) when
getting in the prox while protocol 4 distance is 0 when
getting in the prox.
oldCursorHwProx keeps the hardware in/out prox state so we can
we set the MaxCursorDist for the
If the arguments to this function are only parseable up to a point,
the function prints a warning but still makes the (partial!) requested
change. For example, if the user runs:
xsetwacom --set 10 Button 1 key +a notakeyword -a
The program prints a warning about it not recognizing notakeyword
Between the parsing code seperating the two halves of set/unset
and the code being confusing in general, I've rewritten this
to hopefully make its operation a little clearer for the next
person.
Signed-off-by: Jason Gerecke killert...@gmail.com
---
tools/xsetwacom.c | 108
We don't need to bother changing the device property if
we're unsetting since we're just going to be deleting it
anyway.
Signed-off-by: Jason Gerecke killert...@gmail.com
---
tools/xsetwacom.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/tools/xsetwacom.c
