Bug 462574

Building xf86-input-synaptics from fd.o git seems to fix it -- and already has the required update to the fdi file too.

Please try xorg-x11-drv-synaptics-0.15.1-1, it should address some of these issues.

https://admin.fedoraproject.org/updates/F9/FEDORA-2008-7925

Upstream is currently getting scaling issues sorted out and I have those patches for review in my inbox, so with a bit of hope we should see it soon.

Is that update not in package CVS?

synaptics is superseded by xorg-x11-drv-synaptics, the update is in the latter.

Oh, I was looking at the 'synaptics' package, not xorg-x11-drv-synaptics. Sorry.

Looks like 0.15.1 lacks the special configuration for bcm5974 which was added by commit fd3517b1, then reverted and replaced by the more cunning default handling in commit 102d1d6c. So although it'll load the driver now without me having to hack the fdi file, it'll still be unusable.

I haven't tested that hypothesis yet though, because I'll need to reboot into the new kernel for that.

The 0.15.2 package in rawhide looks like it should be OK.

0.15.2 has a few other issues as well (e.g. tap appears to break). There is a bit more work to be done upstream, so I hope that for 0.16.0 we should have all that stuff autoconfigured and working.

Seems still not to give me the scrolling (button 4&5) on two-finger movement. How do I enable that again?

Option "VertTwoFingerScroll" "on"

(or the key input.x11_options.VertTwoFingerScroll if it is in the fdi file)

Did it help?

On the F10 final, bcm5974 seems to get loaded but the two-finger scroll and right-click features don't seem to work. Tapping does work fine though.

Stewart:

Yeah, that's fixed in the synaptics 1.0 pre-releases (you can one to test from http://koji.fedoraproject.org/koji/buildinfo?buildID=69697, it'll be another few days before it'll hit F10). For the current F10 one you still need to activate two-finger scrolling manually.

New package works perfectly, thanks.

David, does it work for you?

Sorry for slow response.

The latest update to F-10 seems to break scrolling for me again. Should I see things like input.x11_options.VertTwoFingerScroll in 'lshal' output? I don't...

udi = '/org/freedesktop/Hal/devices/usb_device_5ac_231_noserial_if2_logicaldev_input'
  info.capabilities = {'input', 'input.touchpad'} (string list)
  info.category = 'input'  (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_5ac_231_noserial_if2'  (string)
  info.product = 'bcm5974'  (string)
  info.subsystem = 'input'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_5ac_231_noserial_if2_logicaldev_input'  (string)
  input.device = '/dev/input/event12'  (string)
  input.originating_device = '/org/freedesktop/Hal/devices/usb_device_5ac_231_noserial_if2'  (string)
  input.product = 'bcm5974'  (string)
  input.x11_driver = 'synaptics'  (string)
  linux.device_file = '/dev/input/event12'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'input'  (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.2/input/input12/event12'  (string)


I may have edited the .fdi file to include the required options, and it got overridden when I updated? I don't remember. Sorry.

Sorry, this was my fault, the update overwrote the fdi file. Fixed in 0.15.2-3 once the build goes through.

Hm, OK.... but weren't we intending the package to get the settings right automatically, without needing the user to modify the fdi file for himself?

yes, and I think synaptics 1 (in rawhide) is good enough at that.

I didn't upgrade F10 because a number of defaults changed for this autconfiguration to work, so it may break people's touchpads midway through a release.

Argh, F-10 updated and ate my settings again.

And it seems not to work reliably either. A lot of the time when I touch the pad, it just doesn't do _anything_. This is even with the sensitivity turned right up.

(In reply to comment #18)
> Argh, F-10 updated and ate my settings again.  

sorry. I had to revert the change in 0.15.2-3, it was against fedora's policies. if you have custom configuration, you need to put it into /etc/hal/fdi/policies, anything in /usr/share/hal/... will be overwritten with the next update.

(In reply to comment #19)
> And it seems not to work reliably either. A lot of the time when I touch the
> pad, it just doesn't do _anything_. This is even with the sensitivity turned
> right up.  

that is rather weird. the driver itself hasn't seen any changes since september, not quite sure where the different behaviour comes from.

Created attachment 338215 [details]
/usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi

With these settings, it seems to work OK. But these settings don't always get loaded or stay loaded....

At boot, it comes up with different, slower and less usable settings. If I remove and reload the bcm5974 module, the proper settings from my fdi file get loaded. That's weird enough, but it _also_ seems to regress during use. I only use the touchpad occasionally, and after a while I notice it's gone back to being slow again. Comparing 'synclient -l' output...

--- slow	2009-04-04 12:00:33.000000000 +0100
+++ correct	2009-04-04 12:00:50.000000000 +0100
-    FingerLow               = 10
+    FingerLow               = 16
-    MaxTapTime              = 0
+    MaxTapTime              = 223
-    VertScrollDelta         = 32
+    VertScrollDelta         = 40
-    MinSpeed                = 0.521
+    MinSpeed                = 0.8
-    AccelFactor             = 0.079
+    AccelFactor             = 1.2
-    CircScrollDelta         = 0.01
+    CircScrollDelta         = 0.1

The behaviour in comment #21 has started since upgrading to rawhide a few days ago. I hadn't noticed it before, in F-10.

It seems that gsynaptics-init is overwriting values from gconf.

That wouldn't be so bad, now I've worked it out, but both gsynaptics and synclient seem unable to set AccelFactor larger than 0.2. Setting it to 1.2 works fine in the fdi file as long as nothing else ever touches out...

I'm not sure what the real maximum value for AccelFactor is, but it's definitely larger than 0.2. I think it's probably 1.0 -- I certainly don't see any difference above that, and I'm not even sure I see much difference above 0.8 or so.

Fixing synclient to allow values up to 1.0 seems to make things work OK (I have to trick gsynaptics, by selecting the acceleration slider and then moving my mouse _far_ to the right of the gsynaptics window, which causes the value to go much higher than its intended 'maximum' of 200 :)

--- a/tools/synclient.c
+++ b/tools/synclient.c
@@ -125,7 +125,7 @@ static struct Parameter params[] = {
 		SYNAPTICS_PROP_SPEED,		0, /*float */	0),
     DEFINE_PAR("MaxSpeed",             max_speed,               PT_DOUBLE, 0, 1.0,
 		SYNAPTICS_PROP_SPEED,		0, /*float */	1),
-    DEFINE_PAR("AccelFactor",          accl,                    PT_DOUBLE, 0, 0.2,
+    DEFINE_PAR("AccelFactor",          accl,                    PT_DOUBLE, 0, 1.0,
 		SYNAPTICS_PROP_SPEED,		0, /*float */	2),
     DEFINE_PAR("TrackstickSpeed",      trackstick_speed,        PT_DOUBLE, 0, 200.0,
 		SYNAPTICS_PROP_SPEED,		0, /*float */ 3),

moved the gsynaptics issue to Bug 494795.

xorg-x11-drv-synaptics-1.1.0-6.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.1.0-6.fc11

xorg-x11-drv-synaptics-1.1.0-6.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.