On 09/03/2012 05:30 PM, Neil Jerram wrote:
Benjamin Deering<ben_deer...@swissmail.org> writes:
I seem to remember that part of the touchscreen filtering is disabled
on gta04. Does anyone remember why and do we know if it still needs
to be disabled?
Yes, this has indeed been discussed before, but I believe with no action
or resolution yet. The following is what I could turn up; I think the
important idea is just the last paragraph, i.e. to look at tslib.
From: NeilBrown<ne...@suse.de>
Subject: Re: [Gta04-owner] Beta Tester's Report on qtmoko v40
To: List for communicating with real GTA04 owners<gta04-ow...@goldelico.com>
Cc: n...@ossau.homelinux.net
Date: Tue, 28 Feb 2012 10:34:32 +1100
On Mon, 27 Feb 2012 23:06:47 +0000 Neil Jerram<n...@ossau.homelinux.net>
wrote:
Sven Dyroff<s.dyr...@phytec.de> writes:
Handling the touch
I don't think that I'll get familiar with that behaviour. For me it's just
nasty. Please give me at least a hint where I can play with what values and
I'll try to squeeze out a more comfortable touch reaction.
I think you said before that it was too jittery - is that correct? I
think I'm sometimes seeing the same problem.
I don't know what the solution is, or even how to investigate further,
but:
- I think I remember a mailing list thread about dejittering support
having been removed from the kernel recently (approx in the last year
or so), and hence needing to be added to tslib instead. Or perhaps
vice versa?
- When googling for this, I came across tsc2007_platform_data, and its
max_rt, poll_delay and poll_period fields that were recently added by
Thierry Reding. I wonder if these fields might help us?
For GTA04 the tsc2007_platform_data struct initialisation (in
arch/arm/mach-omap2/board-omap3gta04.c) doesn't set these fields, so I
presume they're all implicitly 0.
Correct - which means the defaults are used.
max_rt is an upper-bound for the pressure. If it senses a higher pressue it
will ignore it. I wonder why you would do that? Maybe a high pressue number
is considerred to be an error?
It defaults to MAX_12BIT which means no pressures are ignored.
poll_delay is never used.
poll_period is a number of msec (defaults to '1' but is rounded up to
jiffies, so probably about 5). It represents how often the current stylus
location is polled. I doubt increasing that would help much.
I wondered about experimenting with those fields, but it would be a
major pain to have to rebuild and reinstall the kernel for every set of
values to try.
Any other thoughts on dejittering?
tslib has dejitter code. See "man 5 tslib.conf". That is where I would look
to try to improve touchscreen response.
NeilBrown
I spent some time with this tonight.
after:
opkg install xf86-input-tslib
and some changes to my xorg.conf, I have a smoother pointer as seen by
drawing quick lines in numptyphysics. My xorg.conf is a little messy
right now, but the important changes were switching the touchscreen
driver from evdev to tslib and adding a dummy device so X wouldn't try
to use /dev/input/mice as a second pointer.
Section "InputDevice"
Identifier "tslib touchscreen catchall"
Driver "tslib"
Option "Device" "/dev/input/event0"
Option "Width" "480"
Option "Height" "640"
Option "CorePointer" "true"
Option "SendCoreEvents" "true"
Option "MinX" "6"
Option "MaxX" "474"
Option "MinY" "4"
Option "MaxY" "633"
# Option "InvertY" "1"
EndSection
Section "InputDevice"
Identifier "dummy"
Driver "void"
Option "Device" "/dev/input/mice"
EndSection
Section "ServerLayout"
Identifier "Builtin Default Layout"
Screen "Builtin Default fbdev Screen 0"
InputDevice "tslib touchscreen catchall"
InputDevice "dummy"
EndSection
after this I was seeing xinput_calibrator running each time I started
X. Changing /etc/profile.d/tslib.sh to use event0 instead of
touchscreen0 seems to have helped.
I think with some cleanup this might be worth adding, but I will know
more about it when my gta04 is back in its case after tommorow.
Ben
_______________________________________________
Shr-devel mailing list
Shr-devel@lists.shr-project.org
http://lists.shr-project.org/mailman/listinfo/shr-devel
