Bug#623095: tslib: 623095: possibly a kernel issue
Hi, since I haven't got any feedback and this issue has caused openmoko install.sh to fail for more than two months I'll start preparing an NMU soon. -Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623095: tslib: 623095: possibly a kernel issue
Hello, On Tue, Jul 05, 2011 at 09:25:28AM +0300, Timo Juhani Lindfors wrote: since I haven't got any feedback and this issue has caused openmoko install.sh to fail for more than two months I'll start preparing an NMU soon. I have tested the patch and it seems to work here on IGEPv2 board. I'll try to make an upload of the package ASAP. Cheers, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html signature.asc Description: Digital signature
Bug#623095: tslib: 623095: possibly a kernel issue
On Tue, 07 Jun 2011 14:14:50 +0300, Timo Juhani Lindfors wrote: I've attached a tested debdiff against 1.0-8. source package and armel binaries are available at http://lindi.iki.fi/lindi/tslib/ The patched package works fine for me, thanks! Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Treibhaus: Colosseum signature.asc Description: Digital signature
Bug#623095: tslib: 623095: possibly a kernel issue
Hi, I'm running linux-image-2.6.37-qtmoko-gta02 from pkg-fso repositories and can confirm that the patched tslib packages by lindi make the touchscreen work again. Thank you! cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623095: tslib: 623095: possibly a kernel issue
package libts-0.0-0 tags 623095 patch thanks Hi, if I read 8613e4c2872a87cc309a42de2c7091744dc54d0e correctly it seems that it does not modify any parts of the API that tslib actually uses. Wouldn't it then be safe for tslib to allow both EV_VERSION 0x010001 and 0x01? I've attached a tested debdiff against 1.0-8. source package and armel binaries are available at http://lindi.iki.fi/lindi/tslib/ diff -Nru tslib-1.0/debian/changelog tslib-1.0/debian/changelog --- tslib-1.0/debian/changelog 2011-04-05 21:41:48.0 +0300 +++ tslib-1.0/debian/changelog 2011-06-07 13:57:20.0 +0300 @@ -1,3 +1,15 @@ +tslib (1.0-8lindi1) unstable; urgency=low + + * Add patch allow_EV_VERSION_0 to continue supporting Linux 2.6.36 and +older. Previously kernel support depended on the kernel headers that +tslib was built against. (Closes: #623095) + + * Do not refuse to work with old kernels. We can safely work with +kernels that use EV_VERSION 0x01 API since we use no features from +0x010001 yet. (Closes: #623095) + + -- Timo Juhani Lindfors timo.lindf...@iki.fi Tue, 07 Jun 2011 13:22:27 +0300 + tslib (1.0-8) unstable; urgency=low * Drop .la file as per Policy 10.2 (Closes: #620658) diff -Nru tslib-1.0/debian/patches/allow_EV_VERSION_0 tslib-1.0/debian/patches/allow_EV_VERSION_0 --- tslib-1.0/debian/patches/allow_EV_VERSION_0 1970-01-01 02:00:00.0 +0200 +++ tslib-1.0/debian/patches/allow_EV_VERSION_0 2011-06-07 13:57:05.0 +0300 @@ -0,0 +1,22 @@ +Description: Support Linux 2.6.36 and older + Linux 2.6.37 bumps EV_VERSION to 0x010001. To continue support for + Linux 2.6.36 and older we explicitely allow EV_VERSION 0x01 + here. This should not be a problem since tslib does not currently use + any of the API that was changed in this bump (upstream commit + 8613e4c2872a87cc309a42de2c7091744dc54d0e). +Author: Timo Juhani Lindfors timo.lindf...@iki.fi +Last-Update: 2011-06-07 +Forwarded: no +Bug-Debian: http://bugs.debian.org/623095 + +--- a/plugins/input-raw.c b/plugins/input-raw.c +@@ -60,7 +60,7 @@ + unsigned long absbit[ABS_MAX / BITS_PER_LONG + 1]; + + if (! ((ioctl(ts-fd, EVIOCGVERSION, version) = 0) +- (version == EV_VERSION) ++ (version == EV_VERSION || version == 0x01) + (ioctl(ts-fd, EVIOCGBIT(0, sizeof(bit)), bit) = 0) + (bit[0] (1 EV_ABS)) + (ioctl(ts-fd, EVIOCGBIT(EV_ABS, sizeof(absbit)), absbit) = 0) diff -Nru tslib-1.0/debian/patches/series tslib-1.0/debian/patches/series --- tslib-1.0/debian/patches/series 2011-04-05 21:38:26.0 +0300 +++ tslib-1.0/debian/patches/series 2011-06-07 13:19:36.0 +0300 @@ -3,3 +3,4 @@ 32bitBE-support.diff ac-init.diff glibc2.8.diff +allow_EV_VERSION_0 -Timo
Bug#623095: tslib: 623095: possibly a kernel issue
From the #debian-arm IRC channel: pabs codehelp: any chance to get #623095 fixed soon? rtp pabs: which kernel are you using ? pabs pkg-fso 2.6.34 rtp ok, so you're maybe hitting the problem I'm thinking of. rtp in 2.6.37 there has been changes in put stuff (see commit 8613e4c2872a87cc309a42de2c7091744dc54d0e in Linus tree) and they increased ev version number rtp so if tslib has been build with = 2.6.37 header, there will be a version mismatch rtp s/put/input/ pabs hmmm pabs its about time there was a newer kernel for openmoko devices, will try to see if there are any plans for a new one rtp you can ask larsc or the other possibility would be to backport the commit I gave but this may break stuff for people updating the kernel but not userspace -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
