2008/10/26 Simon Thum [EMAIL PROTECTED]:
Søren Hauberg wrote:
issue is keeping the code fairly clean. I imagine that the solution
you suggest will be fairly complicated, in which case I don't think it
would be worth the slight performance gain. But perhaps my priorities
aren't in place...
On Mon, Oct 27, 2008 at 08:44:24AM +0100, Søren Hauberg wrote:
Just a quick thought: double-scaling means we transform one coordinate
from [a, b] to [c, d] in the driver, and then from [c, d] to [e, f] in
the server, right? Here [a, b] is determined by the hardware. What if
we choose [c, d]
Peter Hutterer wrote:
On Sat, Oct 25, 2008 at 01:42:31PM +0100, Colin Guthrie wrote:
Well they didn't appear to come up I'll have a look and see if I can
get more info. Not being able to log in to debug it due to lack of
keyboard meant I didn't really research/probe as much as I should
On Mon, Oct 27, 2008 at 09:20:55AM +0100, Søren Hauberg wrote:
Yes, not knowing [a, b] at server startup is indeed the real problem.
If we want to support run-time calibration, then it simply won't be
possible to fix these parameters at startup. From what I understand,
it is only the driver
Søren Hauberg wrote:
2008/10/24 Peter Hutterer [EMAIL PROTECTED]:
Hmm, yeah then I don't see an alternative to double scaling. But, hey,
as long as it only happens on touch screens then I think it'll be
okay, as it doesn't happen on ordinary devices.
May may want to try if you can avoid
2008/10/26 Simon Thum [EMAIL PROTECTED]:
Søren Hauberg wrote:
2008/10/24 Peter Hutterer [EMAIL PROTECTED]:
Hmm, yeah then I don't see an alternative to double scaling. But, hey,
as long as it only happens on touch screens then I think it'll be
okay, as it doesn't happen on ordinary devices.
Søren Hauberg wrote:
issue is keeping the code fairly clean. I imagine that the solution
you suggest will be fairly complicated, in which case I don't think it
would be worth the slight performance gain. But perhaps my priorities
aren't in place...
Well, the issue is precision which is
2008/10/26 Simon Thum [EMAIL PROTECTED]:
Søren Hauberg wrote:
issue is keeping the code fairly clean. I imagine that the solution
you suggest will be fairly complicated, in which case I don't think it
would be worth the slight performance gain. But perhaps my priorities
aren't in place...
On Sat, Oct 25, 2008 at 01:42:31PM +0100, Colin Guthrie wrote:
Well they didn't appear to come up I'll have a look and see if I can
get more info. Not being able to log in to debug it due to lack of
keyboard meant I didn't really research/probe as much as I should have
done... :)
lshal
Peter Hutterer wrote:
On Fri, Oct 24, 2008 at 08:50:20AM +0200, Søren Hauberg wrote:
2008/10/24 Peter Hutterer [EMAIL PROTECTED]:
Touchscreen support (courtesy of Søren) enables devices that report only
BTN_TOUCH capability, but no BTN_LEFT, BTN_RIGHT, etc.
Great! The only major thing left is
On Fri, Oct 24, 2008 at 11:43:03AM +0200, Søren Hauberg wrote:
Yeah, I can understand that. As I think I've made quite clear in
previous posts: I'm stupid. That is, I don't really know X. So, here's
a stupid question [1]: the server scales from what ever the driver
reports to some range. So,
2008/10/24 Peter Hutterer [EMAIL PROTECTED]:
it can be combined, if you specify the correct min/max range in the config (or
you let it get picked up from the kernel). Then the driver doesn't need
scaling, the server does it.
For calibration, that doesn't work. Or to be more precise, it only
Peter Hutterer wrote:
On Fri, Oct 24, 2008 at 10:59:25AM +0100, Colin Guthrie wrote:
It seems that my usb mouse wanted to make double clicks rather than
single clicks when I tried this driver. Not overly sure why! When trying
to update the xserver and getting inspired by the Fedora patches,
evdev 2.1 RC2
Touchscreen support (courtesy of Søren) enables devices that report only
BTN_TOUCH capability, but no BTN_LEFT, BTN_RIGHT, etc.
Julien Cristau (1):
Fix TestBit() on 64bit
Peter Hutterer (6):
Don't post keycodes 255.
Add option GrabDevice, don't grab the device
14 matches
Mail list logo
