The problem as described and solved in http://bugs.gentoo.org/206614 (see also http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?h=gentoo-patches&id=8efccb0a76833b31a8d0273b49dd584246a97c7d) was apparently reintroduced in the commit of http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=c405a69f83dab77cfe6c76f718a3ca5614a85918 thus leading to a regression carried through all the way to the present version 1.2.1. The problem seems to be that using the priv->minx and priv->miny values instead of the default -1 in the call to xf86InitValuatorAxisStruct prevents the synaptic mouse pointer from crossing over to the second screen. If the mouse pointer is moved to the second screen e.g. using an external mouse it works normally on the other screen also with the synaptics pad but gets trapped again as soon as one crosses back to the first screen. This is extremely annoying for anybody who uses an external monitor with his laptop and wants to make use of the extra desktop. The fix is trivial, simply remove the usage of priv->minx and priv->miny and pass the default values to xf86InitValuatorAxisStruct as suggested in the Gentoo patch above. I have patched my synaptics driver V1.1.3 in this way and it works just fine now but perhaps you want to review the problem more thoroughly and find a solution that takes the automatically set priv->minx and priv->miny values into account without breaking the driver as it does at the moment.
Thank you for reporting this. I need to confirm something here though. Setting the default minx to -1 is trivial enough and that's the fix needed for devices that don't announce the screen range (similar to the mouse driver). For devices that announce the range that's a bit different. by choosing an invalid range like that, we lose the ability to work as absolute device and the ability to report valuator ranges to the X server and clients. that's not good. I think the right thing to do should be to modify the announced range that we can get coordinates that go below zero. To test this (I don't have a Xinerama setup), please check the range reported by your touchpad and then hardcode a minimum value of just above that range into the driver. e.g. if your touchpad reports a range of 1500-5000, harcode the minimum to be 1501, 1510 or 1550 (high enough so you can actually trigger it but as low as possible). Does this fix the issue? If so, we can add the code to the driver to automatically announce a range of [minimum range + 1%]
(In reply to comment #1) > Thank you for reporting this. I need to confirm something here though. Setting > the default minx to -1 is trivial enough and that's the fix needed for devices > that don't announce the screen range (similar to the mouse driver). > > For devices that announce the range that's a bit different. by choosing an > invalid range like that, we lose the ability to work as absolute device and the > ability to report valuator ranges to the X server and clients. that's not good. I am by no means an expert of the internals of the X server and what are the benefits of reporting accurate valuator ranges if they exist (it didn't seem to be necessary in previous versions of the synaptics driver). But I dare say that there are more people using their laptop with an external monitor or projector attached than there are people who want to use their touchpad in absolute mode. This doesn't seem to be very useful unless the touchpad is actually a touchscreen too. Anyway, how about using the evaluator ranges only in absolute mode and the default values in relative mode. This should make everybody happy. > I think the right thing to do should be to modify the announced range that we > can get coordinates that go below zero. To test this (I don't have a Xinerama > setup), please check the range reported by your touchpad and then hardcode a > minimum value of just above that range into the driver. > e.g. if your touchpad reports a range of 1500-5000, harcode the minimum to be > 1501, 1510 or 1550 (high enough so you can actually trigger it but as low as > possible). > > Does this fix the issue? If so, we can add the code to the driver to > automatically announce a range of [minimum range + 1%] > Unfortunately none of these suggestions had any effect on the problem. I tried changing both minx/y and maxx/y +/- 150 points. Btw the ranges of my Alps touchpad are 0-1023 and 0-767. The only thing that works is to set maxx/y to -1. Also it is not exactly clear to me why changing the minx/y such that one can achieve negative values by touching the very left/top edges would solve the problem. I want the cursor to cross over to the other screen whenever it hits the screen border, not when my finger hits the touchpad border (they would only coincide in absolute mode). It would be good if this bug could be closed quickly as it has been there a while and looking at the forums it seems to have given a lot of headache to quite a few people. Touchpads are usually on laptops and laptops have small screens so many people prefer to use them with an additional external monitor to work. And even more people want to give presentations on their laptops. Plugging in a projector as external display device one can use the OpenOffice presenter console in Xinerama mode - but only if one can reach the other screen with the mouse pointer! So again, I'd suggest to use custom evaluator values only in absolute mode where there may be some sense to it and where using the second screen in Xinerama is probably impossible anyway (unless it has the exact same resolution). If any more help or testing is needed, I'll be glad to assist!
(In reply to comment #2) > I am by no means an expert of the internals of the X server and what are the > benefits of reporting accurate valuator ranges if they exist (it didn't seem to > be necessary in previous versions of the synaptics driver). One of the benefits is that a (prospective) client may use this information to scale input data into a sensible range. Right now, the server uses the axis data to apply acceleration in a device-specific manner. > But I dare say that there are more people using their laptop with an external monitor or projector attached than there are people who want to use their touchpad in absolute mode. right, I don't think having an absolute mode in the touchpad is something we really need (and those that do can use evdev instead). this particular issue is however only visible in a xinerama setting, not in an xrandr setup (which is the default these days). I use a laptop + monitor every day and have not yet spotted this issue (also, I can't actually get a xinerama setup on my hardware) out of interest - why are you using xinerama instead of xrandr? > This doesn't seem to be very useful unless the touchpad is actually a > touchscreen too. Anyway, how about using the evaluator ranges only in absolute > mode and the default values in relative mode. This should make everybody happy. unfortunately, once the device is set up, it cannot be changed anymore. protocol restrictions prohibit that :( I need to play around with this, resetting to -1,-1 completely offsets the acceleration, making the touchpad unusable here. the correct fix is likely to even be in the server, taking multiple protocol screens into account when scaling into a particular position.
Created attachment 33576 [details] [review] 0001-dix-Clip-only-into-axis-ranges-if-we-re-in-absolute-.patch finally found a box that has a touchpad and can do xinerama. Pretty simple patch, except that the repercussions may be wide, I need to test more here. clipping was always back into the axis ranges, even in relative mode. note that this is an X server patch, not for synaptics.
Manfred - have you had any chance to test this patch? It's been well received on the mailing list but I'd like to hear your feedback too.
commit 9f462ff9082634719e64d2d8d4dbd09ec7deaf2e Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Feb 26 14:02:09 2010 +1000 dix: Clip only into axis ranges if we're in absolute mode. (#26543)
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.