[PATCH] touchscreen-meddling.patch

Andy Green andy at openmoko.com
Thu Jun 19 14:46:25 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| 2008/6/19 Andy Green <andy at openmoko.com>:
|> | Like this
|> | ?
|> |
|> | This is really not a coding issue, it's a configuration issue in our
|> | tslib config.  You can try to hack it into the kernel obviously (like
|> | e.g. Nokia), duplicating existing solutions, and you'll get frowned
|> | upon when trying to upstream (like e.g. Nokia).  If it must be in the
|> There is configurable averaging built into that ts driver before
|> yesterday, I just extended it a bit.
| Which probably shouldn't be there.

Well: it is (with no "probably" needed).

|>  Driver-based filtering serves a
|> useful purpose, it reduces the datarate into the input device by a
|> factor of 32 or 64 or whatever you set it at.  So this and tslib are not
|> the same deal.  Tslib NEVER got raw samples.
| Right, and it was chosen (even in 2001, when machines were slower, by
| RMK) that tslib should be getting the raw samples.  With the overhead
| it gives - this is accepted.

Er, no, it isn't accepted because when I look in the sources, I see the
kernel-side averager since day 1.  You "accepted it" in your head, OK.

| The question really is doing things the linux way or only basing on it
| (tomtom/zaurus/skype way) although it's so small in this case it's
| probably a bike-shed discussion on my part.
|> As for getting frowned upon, my dear Andrzej I get frowned upon if I get
|> up in the morning.
| Awww :)

Why thank you.

|>  I might as well do something effective and maintain
|> it myself and get frowned upon than do nothing.  Besides, I can't use
|> our wonderful flawless Openmoko build+packaging system to work on tslib
|> because it can't cope with exotic hosts like Fedora 9.
| You can use the same excuse to build the dialer and a minesweeper game
| into the linux kernel (I think there was a project doing that
| somewhere) - and you might even likely get something more reliable and
| usable and faster than the whole kernel + userspace approach, this has
| been discussed all too often already.

That's a nice straw man you got going there!  Throw in a coffee maker!

| But I share the pain - I've never used OE or MokoMakefile yet, I just
| didn't ever need to (build a distro to cross-compile a single
| program), I would have to start from reading the basics howto if I
| wanted to use OE/bitbake now.

Well then you didn't quite share the pain yet then.

| (variance plugin is already there fortunately and it only takes one
| line in the config file, no compiling)

Mickey was saying it was borked, but maybe that is because nobody looked
into the driver averaging before yesterday.

Make a beauty contest: if there's no difference in power consumption
(measured on running battery and holding down a stylus) and performance
we will change it to the userspace method.

Wow I wonder what else I can do with this super power I have for
catalysing sudden activity from the rest of the company when I touch a
problem that has lain dormant for months.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list