Description of problem: The Dell Mini 10v has physical buttons under the touch-sensitive touchpad area at the bottom of the touchpad. This configuration makes drag and drop impossible without using the double-tap-drag feature. Clicking and holding the touchpad button with one finger, then attempting to drag with another finger cause the pointer to fly off to the top-right (as normally would happen when touching the touchpad in two places at once). There is a patched synaptics driver which adds a 'MovementBottomArea' option to synclient - this allows a user to disable all touch operations for the bottom edge (the size of the edge is configurable) of the touchpad. With this option configured, it's possible to drag and drop, because the bottom of the touchpad is no longer touch-sensitive. There's a thread about this problem on the Ubuntu boards here: http://ubuntuforums.org/showthread.php?t=1213114 The patched driver is available at: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/+packages Version-Release number of selected component (if applicable): xorg-x11-drv-synaptics-1.2.1-1.fc12.i686 How reproducible: Always Steps to Reproduce: 1. Attempt to drag and drop using the physical touchpad buttons. Actual results: Pointer flies off when the 'dragging' finger touches the touchpad. Expected results: Pointer remains where it is until moved by the dragging finger. Additional info:
There should be a possibility of configuration of the driver with /etc/X11/xorg.conf (see synaptics(4) for more information). Also, could you please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, system log (/var/log/messages), and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above? We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 400301 [details] dmesg output
Created attachment 400303 [details] /var/log/messages
Created attachment 400304 [details] /var/log/Xorg.0.log
I played about with the BottomeEdge and AreaBottomEdge settings, but no joy. No xorg.conf and the xorg HAL files are as-installed.
I am idiot ... sorry ... there is now a Brave New World of xorg input configuration ... see https://fedoraproject.org/wiki/Input_device_configuration and you are living still in the HAL world (no /etc/xorg.conf.d yet). I think you can certainly some local configuration file in /etc/hal/fdi/policy with your preferred settings for your touchpad. Are you able to make it work?
Unfortunately not, no. There's no option with the normal driver to disable sensitivity for part of the pad, so there's no way to stop the 'flying pointer' effect when trying to drag and drop using the physical buttons. The patched driver linked from the bug description appears to be the only way to make this work for the ill-guided layout of this particular touchpad (apparently Windows users have the same problem...). To quote the Ubuntuers: "It looks like enough people had this problem that somebody patched the synaptics drivers. ... There are actually 2 changes in this driver package: one makes the trackpad less jumpy and one allows you to disable everything below a certain y-value. The jumpy patch seems to have fixed all of my woes, and I didn't need to disable the bottom part of the trackpad after all. If you still want to, I recommend starting with a MovementBottomEdge value of 4000 and playing with it from there." I don't find the pad particularly jumpy, but I'm interested in disabling the bottom quarter of the pad to let me use the buttons.
AreaBottomEdge should be the option for you. Not sure where the MovementBottomEdge comes from but it looks like that documentation may be incorrect.
If I set AreaBottomEdge to, say, 3000 then movements and taps etc in the bottom quarter of the pad have no effect on the pointer, so the AreaBottomEdge option appears to do what the man page says. However, the drag and drop 'flying pointer' effect still happens if I've got one finger in the AreaBottomEdge disabled touchpad area (where the physical buttons are) and attempt to drag inside the non-disabled area. So AreaBottomEdge doesn't quite cut it - I don't know if that's the intended behaviour of AreaBottomEdge, but that's what's happening. The patch linked above adds 'MovementBottomEdge' as a new configuration option which /completely/ disables the bottom edge of the trackpad. That's basically what I'm looking for.
The MovementBottomEdge patch was upstreamed by Alberto and turned into the Area*Edge options. So in theory, it should do the same thing :) See https://bugs.freedesktop.org/show_bug.cgi?id=21613 for that bugreport. The flying pointer option is something else in fact, see http://bugs.freedesktop.org/show_bug.cgi?id=21614. That's bottlenecking on me and the fact that I just don't have a device to test it with and all previous patches broke my touchpad in one way or another.
Ah. My apologies. I'd seen the 'Movement' and 'Area' options described differently, so I thought they were separate things. So it's actually more the 'jumpy' element of that patch that fixes the problem. I always thought jumping cursors were expected behaviour with touchpads in general... If there's anything you want to test on the Mini, let me know.
I think there's two problems, but for your case the main one is what's pointed out in freedesktop bug 21613 comment 28. We don't have a patch for this yet so if you have some coding experience that might be a good one to get started. Let me know if I can help you with getting set up, it's quite trivial actually.
OK. I've got enough xorg-devel and gcc stuff in to compile the synaptics src.rpm so I should be in a position to have a poke (no pun intended) at it. Don't expect much - it's been a long time since I touched any C. The code looks pretty easy to follow, though. I've just noticed that the Fedora driver with AreaBottomEdge actually half works. If your dragging finger's already inside the 'Synaptics Area' and then you click with the other finger in the disabled bottom area, it works OK. But if you click (and hold), then add a finger to the active touchpad area to drag, that's when the pointer does a runner.
sounds a bit like there should be a finger counter. I haven't touched this code for a while and I don't have a multitouch pad anyway, but some checks to count the fingers in the invalid area might be all that's needed.
ok, some good news on this front. I finally managed to get my hands onto a mini and start fixing this issue. Unfortunately, there's a rather large set of patches and it may take me another few days to iron it out, especially now that the Mini's BIOS committed suicide. Also a warning: the auto-configuration for this is likely to land only in F-13, not sure if I find the time to backport to F-12. A rawhide build for the first half of this fix is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2176249 The second half is not make the area handling suck this badly: http://lists.freedesktop.org/archives/xorg-devel/2010-May/008296.html
xorg-x11-drv-synaptics-1.2.2-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.2.2-5.fc13
Awesome. I've not had a chance to test it yet - my Mini's mainly acting as a serial console for work at the moment, so I can't mess about with it. I think F13 should be out by the time I get to play with it.
HP Pavilion DM4-1060US running Fedora 13, xorg-x11-drv-synaptics-1.2.2-6.fc13 experiences this problem as well. AreaBottomEdge 4000 works fine with one finger, but as described by David in comment 9 it still freaks out and jumps with two, rendering dragging impossible. I'm wanting to stay on F13 but would be happy to collaborate with any backport work to correct this - I don't know the project sources but I can do monkey-see monkey-do development stuff with someone who does know.
fedora 13 / 14 same problem here with Macbook Pro
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.