I've been trying to get my touchscreen working, but the pointer is always either inverted or otherwise screwed up on the vertical axis. I've tried to figure out why MinY/MaxY don't seem to be doing anything, and as far as I can tell, I've traced it to the fact that in xorg 7.3, the conversion_proc() function is never called. This seems to be confirmed by a number of comments and bug reports out there for other drivers as well. evtouch has a patch (http://www.postnuklear.de/xorg-patches/files/xf86-input-evtouch-0.8.7-misc.patch) that among other things injects the conversion_proc logic into the mainline event posting. VMWare is also affected it seems. This seems like a bug that should be affecting just about any absolute-value input method, and I'm not really sure why something like a call to conversion_proc should ever have been removed. On Ubuntu 8.04 fresh install: xorg-* 7.3+10ubuntu10 mutouch 1.1.0-3
On Thu, May 22, 2008 at 12:40:47 -0700, bugzilla-daemon@freedesktop.org wrote: > I've tried to figure out why MinY/MaxY don't seem to be doing anything, and as > far as I can tell, I've traced it to the fact that in xorg 7.3, the > conversion_proc() function is never called. This seems to be confirmed by a > number of comments and bug reports out there for other drivers as well. > evtouch has a patch > (http://www.postnuklear.de/xorg-patches/files/xf86-input-evtouch-0.8.7-misc.patch) > that among other things injects the conversion_proc logic into the mainline > event posting. VMWare is also affected it seems. > > This seems like a bug that should be affecting just about any absolute-value > input method, and I'm not really sure why something like a call to > conversion_proc should ever have been removed. > AFAIK, this is now fixed in the server in master, server-1.5-branch and server-1.4-branch (so will be in 1.4.1 and 1.5). Cheers, Julien
On Thu, May 22, 2008 at 12:55:41PM -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #1 from Julien Cristau <jcristau@debian.org> 2008-05-22 12:55:41 PST --- > AFAIK, this is now fixed in the server in master, server-1.5-branch and > server-1.4-branch (so will be in 1.4.1 and 1.5). Indeed.
I hacked in a call in my copy, and ended up getting even worse results. The math in mutouch looks at both screen size and the MinY-MaxY size, which came to 3000x3000, completely ignoring the settings I have in xorg.conf. Switching MinY/MaxY in there does cause a change in behavior (instead of inverted it just gets stuck to the bottom), yet I can't find where the string "MinY" is actually referenced anywhere in the codebase. Is something outside of the mutouch driver trying to do some kind of magic? Does HEAD also fix the math in mutouch, since it seems that things have changed rather significantly? As far as testing HEAD, I'm not seeing the mapping between the xorg CVS tree and the Ubuntu packages, is there some relatively straightforward way of pulling in the relevant files for a debuild?
(In reply to comment #3) > I hacked in a call in my copy, and ended up getting even worse results. The > math in mutouch looks at both screen size and the MinY-MaxY size, which came to > 3000x3000, completely ignoring the settings I have in xorg.conf. This is a problem with the mutouch driver then. Reopening bug, changing component. > Switching MinY/MaxY in there does cause a change in behavior (instead of inverted it just > gets stuck to the bottom), yet I can't find where the string "MinY" is actually > referenced anywhere in the codebase. Is something outside of the mutouch > driver trying to do some kind of magic? Does HEAD also fix the math in > mutouch, since it seems that things have changed rather significantly? The server checks for a valid range (min < max) and then scales linearly between these coordinates into screen coordinates. the mutouch driver needs to make sure that if an inverted range is specified, this is flipped in the driver already, otherwise the server won't scale. > As far as testing HEAD, I'm not seeing the mapping between the xorg CVS tree > and the Ubuntu packages, is there some relatively straightforward way of > pulling in the relevant files for a debuild? Your problems seem to be in the driver, so it would be enough to get git://anongit.freedesktop.org/git/xorg/driver/xf86-input-mutouch you will also have to install xorg development packages, not sure what they are called though. xorg-macros is one of them, xorg-dev-headers or so maybe too.
On Thu, May 22, 2008 at 18:17:31 -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #4 from Peter Hutterer <peter@cs.unisa.edu.au> 2008-05-22 18:17:31 PST --- > Your problems seem to be in the driver, so it would be enough to get > git://anongit.freedesktop.org/git/xorg/driver/xf86-input-mutouch > > you will also have to install xorg development packages, not sure what they are > called though. xorg-macros is one of them, xorg-dev-headers or so maybe too. > The macros are in xutils-dev, the xserver headers in xserver-xorg-dev. Cheers, Julien
I just pushed a change to driver that should fix axis inversion. Looking at the source, I don't think there are any issues with the coordinate conversion on a current X server.
A friend of mine, who apparently would like to use this driver, noticed some typos in the patch http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-mutouch.git;a=commitdiff;h=7ada6945af8c690e629bfc4ad6fe19b49cbbb66e The min/max swapping code is broken in both places. Plus, using the boolean variable as a temporary is ummm... let's say confusing instead of ugly ;-)
On Sat, Jun 21, 2008 at 04:28:41AM -0700, bugzilla-daemon@freedesktop.org wrote: > The min/max swapping code is broken in both places. indeed, you're right. > Plus, using the boolean variable as a temporary is ummm... let's say confusing > instead of ugly ;-) meh. seemed like a good idea at the time :) Fix pushed as c2a2c40506a57aa6d9e92e6dce372165c132eb85, let's see what this patch brings.
My friend thanks you, and says that on Ubuntu Hardy, backported to Xorg 7.3, mutouch 1.1.0 patched (a similar fix) works fine.
calling it fixed then.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.