-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | 2008/6/19 Andy Green <[EMAIL PROTECTED]>: |> | Like this |> http://svn.berlios.de/viewcvs/tslib/trunk/tslib/plugins/variance.c?rev=34&view=markup |> | ? |> | |> | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhaVRoACgkQOjLpvpq7dMqlyQCbBB2aAlbar2oIAIzcIr4mD8pJ SskAn39AOQNMfqdzf8gPxjkQwX7LBtHe =dpW3 -----END PGP SIGNATURE-----
