Bug 439386 - Synaptics touchpad touching to tap doesn't work after suspend/resume cycle
Summary: Synaptics touchpad touching to tap doesn't work after suspend/resume cycle
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: synaptics
Version: 9
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 437609 446313 447310 452367 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-28 13:44 UTC by Adrian "Adi1981" P.
Modified: 2018-04-11 19:23 UTC (History)
58 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-16 23:27:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
xorg.0.log (21.08 KB, text/plain)
2008-03-28 13:44 UTC, Adrian "Adi1981" P.
no flags Details
kdm.log (33.11 KB, text/plain)
2008-03-28 13:45 UTC, Adrian "Adi1981" P.
no flags Details
dmesg output (46.04 KB, text/plain)
2008-03-28 13:46 UTC, Adrian "Adi1981" P.
no flags Details
/proc/bus/input/devices (1.91 KB, text/plain)
2008-03-28 13:47 UTC, Adrian "Adi1981" P.
no flags Details
Xorg.0.log (23.71 KB, text/plain)
2008-03-28 14:03 UTC, Adrian "Adi1981" P.
no flags Details
kdm.log (39.26 KB, text/plain)
2008-03-28 14:03 UTC, Adrian "Adi1981" P.
no flags Details
Xorg.0.log at the time touchpad started working (30.94 KB, text/plain)
2008-05-14 07:36 UTC, Mike C
no flags Details
xorg.conf (1.22 KB, text/plain)
2008-05-14 13:51 UTC, Deependra Singh Shekhawat
no flags Details
Xorg.0.log (19.95 KB, text/plain)
2008-05-14 13:52 UTC, Deependra Singh Shekhawat
no flags Details
xorg.conf (1.53 KB, text/plain)
2008-07-02 19:09 UTC, Mike C
no flags Details
FDI configuration for synaptics driver (740 bytes, text/plain)
2008-07-25 07:16 UTC, Matěj Cepl
no flags Details
My synaptics.fdi (1.96 KB, text/plain)
2008-09-15 14:55 UTC, Rohan Dhruva
no flags Details
Modified synaptics.fdi (3.49 KB, text/plain)
2008-09-16 13:07 UTC, Rohan Dhruva
no flags Details
Output of hal-device. Relevant portion starts from line 125. (113.46 KB, text/plain)
2008-09-16 13:08 UTC, Rohan Dhruva
no flags Details

Description Adrian "Adi1981" P. 2008-03-28 13:44:42 UTC
Description of problem:

I've got synaptics touchpad (Asus F3Sc), but it seems to not working with
rawhide's xorg (with default config). Temporary solution is to add to xorg.conf:
in ServerLayout section

InputDevice    "Synaptics"

and new section: 

Section "InputDevice"
        Identifier  "Synaptics"
        Driver      "synaptics"
        Option      "Device" "/dev/input/mice"
        Option      "Protocol" "auto-dev"
        Option      "Emulate3Buttons" "yes"
        Option      "SHMConfig" "on"
        Option      "SendCoreEvents" "true"
EndSection

But it doesn't resolve all problems - vertical and horizontal scrolling works,
moving pointer also, but tapping doesn't work at all. With
xorg-x11-server-Xorg-1.4 (from F8) Everything was working ok with this config

Version-Release number of selected component (if applicable):
[adi@localhost ~]$ rpm -q synaptics xorg-x11-server-Xorg
synaptics-0.14.6-6.fc9.i386
xorg-x11-server-Xorg-1.4.99.901-13.20080314.fc9.i386
[adi@localhost ~]$ uname -r
2.6.25-0.167.rc7.git2.fc9.i686

How reproducible:
Always

Steps to Reproduce:
1. Boot system and try using touchpad
  
Actual results:
Touchpad is not working.

Expected results:
V & H scrolling, tapping and moving pointer should work.

Additional info:
See attachements

Comment 1 Adrian "Adi1981" P. 2008-03-28 13:44:42 UTC
Created attachment 299463 [details]
xorg.0.log

Comment 2 Adrian "Adi1981" P. 2008-03-28 13:45:56 UTC
Created attachment 299464 [details]
kdm.log

There are also some warnings and errors in kdm.log

Comment 3 Adrian "Adi1981" P. 2008-03-28 13:46:29 UTC
Created attachment 299465 [details]
dmesg output

Comment 4 Adrian "Adi1981" P. 2008-03-28 13:47:41 UTC
Created attachment 299466 [details]
/proc/bus/input/devices

Comment 5 Adrian "Adi1981" P. 2008-03-28 14:03:02 UTC
Created attachment 299467 [details]
Xorg.0.log

ARGH... i've screwed this when trying to install nvidia which have created
xorg.conf... Anyway after removing xorg.conf tapping is still not working, rest
is OK. Old Xorg.0.log and kdm.log are not actual, here's new ones.

Comment 6 Adrian "Adi1981" P. 2008-03-28 14:03:23 UTC
Created attachment 299468 [details]
kdm.log

Comment 7 Gerwin Krist 2008-03-29 09:35:52 UTC
I can confirm on my Dell D610 the cursor was moving dog slow with the default
auto-created xorg.conf. After adding the above text and installing ksynaptics it
was snappy again. But tapping does still not work.

I also would like to see the SHMconfig to be defaulted to On (probably because
of security reasons off) or atleast an option to enable it easily for average
joe (read: my colleagues :D)

Comment 8 Hendrik Borghorst 2008-04-12 21:32:11 UTC
I can confirm it on Asus EEE-PC. Tapping is not working



Comment 9 josc 2008-04-18 12:17:24 UTC
HP nx7400:
- scrolling works out of the box
- tapping does not work

Comment 10 Michael Elkins 2008-04-20 18:43:21 UTC
Same issue on a Dell Latitude D610.  Adding the InputDevice section for the
synaptics driver also does not fix the inability to tap for a left mouse click.


Comment 11 Jared Keith Spurbeck 2008-04-24 16:19:40 UTC
Same here, on an IC Power notebook. Tapping does not work.

Comment 12 Matěj Cepl 2008-04-24 16:27:50 UTC
I can confirm reproduction with my notebook, but I have to qualify it -- it
actually works but only until the frist suspend/resume cycle. Does anybody of
people who confirmed reproduction of this bug did reproduce it from a fresh boot
of the computer or only after suspend/resuming the computer?


Comment 13 Michael Elkins 2008-04-24 17:24:01 UTC
It does not work even with a cold boot.

Interestingly, I just discovered that tapping works during the graphical boot (I
can tap to show/hide details), but once gdm starts up, I can't tap to select the
user, or on the Suspend/Restart/Shut Down buttons.

Comment 14 Adrian "Adi1981" P. 2008-04-25 23:05:41 UTC
Today i've updated my system and i've got at last my tapping back again ! I
didn't test it after suspend/resume, but after booting system it definitely
works now for me.

Comment 15 Matěj Cepl 2008-04-26 06:35:34 UTC
(In reply to comment #14)
> Today i've updated my system and i've got at last my tapping back again ! I
> didn't test it after suspend/resume, but after booting system it definitely
> works now for me.

Note, that I can reproduce this only after suspend/resume. On the fresh boot of
the computer tapping works.

Does anybody else observe this as well?

Comment 16 Matěj Cepl 2008-04-28 12:40:19 UTC
*** Bug 437609 has been marked as a duplicate of this bug. ***

Comment 18 Peter Bloomfield 2008-04-28 16:30:09 UTC
(In reply to comment #15)
[ snip ]
> Note, that I can reproduce this only after suspend/resume. On the fresh boot
> of the computer tapping works.
> 
> Does anybody else observe this as well?

As noted at Bug 437609: Yes, I observe the same thing.  I added `Option     
"TapButton1" "1"', etc., to xorg.conf and tapping is now enabled, but only until
suspend/resume.  Synclient -l reports "TapButton1 = 1" both before and after
suspend/resume.

Comment 19 Mike C 2008-05-14 07:33:54 UTC
I have an interesting observation on my system which also had the same problem
with tap not working on a newly installed F9 system (as released)

I tried the suggestions above editing xorg.conf all to no avail. 

I was using KDE4, and wanted to test "switchdesk gnome" - when I had logged in
to gnome touchpad tap started working. Even more interesting was that when I
used "switchdesk kde" then touchpad tap started working in KDE as well when I
had logged back in to the KDE session!

I did not restart X when this happened.
I will add my xorg.conf shortly.

Comment 20 Mike C 2008-05-14 07:36:09 UTC
Created attachment 305335 [details]
Xorg.0.log at the time touchpad started working

In addition to this there were no useful lines in /var/log/messages

Comment 21 Bug Zapper 2008-05-14 08:22:06 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 22 Matěj Cepl 2008-05-14 13:36:23 UTC
*** Bug 446313 has been marked as a duplicate of this bug. ***

Comment 23 Deependra Singh Shekhawat 2008-05-14 13:51:27 UTC
Created attachment 305361 [details]
xorg.conf

Comment 24 Deependra Singh Shekhawat 2008-05-14 13:52:26 UTC
Created attachment 305362 [details]
Xorg.0.log

Comment 25 Deependra Singh Shekhawat 2008-05-14 13:54:24 UTC
Hi,

The above attachments are from my brand new installed fedora9 machine. I
installed it from the Fedora9 Live cd. The tap feature didn't worked in the Live
session , after installation worked in the rhgb. But then got disabled in the
gdm and later in gnome.

Now what should I do?

Thanks

Comment 26 Lauro César Alves 2008-05-14 18:27:50 UTC
	
My touchpad does not respond to the touch, contrary to what occoria in Fedora 8
in which it worked perfectly.

My laptop is an HP pavilion zt3000.

Comment 27 James 2008-05-14 19:31:10 UTC
Seen here: ALPS GlidePoint touchpad on HP Pavilion zx5030EA. Scroll areas and
main pad work, but tapping doesn't.

Comment 28 Peter Veres 2008-05-14 20:20:27 UTC
My touchpad doesn't work too (tap-click), however scrolling works... Someone 
should finally fix it. Fujitsu Siemens Amilo Pro V3515... in fedora 8 it worked 
fine. The Fedora 9 release is terrible.

Comment 29 Bob Kashani 2008-05-14 21:57:50 UTC
Unfortunately this is not a bug. It looks like Adam decided to disable tapping
in the synaptics touchpad driver. I would agree with most of the comments here
that this change should be reverted back. Just because a few people don't like
tapping doesn't mean that it should be turned off for everyone. A better
suggestion would be to implement an easy way (maybe via gsynaptics) to turn
tapping off for the handful of people who don't like it. If it is for
accessibility reasons then this is the wrong way of doing it. The accessibility
framework should turn this off when activated.

I rebuilt the synaptics pkg and removed Adam's tapping patch if anyone is
interested it's here:

http://www.ocf.berkeley.edu/~bobk/packages/

After upgrading the pkg restart the synaptics daemon or reboot your machine.

Comment 30 Adrian "Adi1981" P. 2008-05-14 22:43:36 UTC
Thanks Bob for packages. 

For me problem has been solved earlier by adding to xorg.conf

Section "ServerLayout"
        Identifier     "single head configuration"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Synaptics"
EndSection
Section "InputDevice"
        Identifier  "Synaptics"
        Driver      "synaptics"
        Option      "Device" "/dev/input/mice"
        Option      "Protocol" "auto-dev"
        Option      "Emulate3Buttons" "yes"
        Option      "SHMConfig" "on"
        Option      "SendCoreEvents" "true"
        Option      "RTCornerButton" "2"
        Option      "RTCornerButton" "3"
        Option      "TapButton1" "1"
        Option      "TapButton2" "2"
        Option      "TapButton3" "3"
EndSection

With this tapping works fine, but unfortunately if those bits will stay
disabled, problem will occur again in F10, as there won't be xorg.conf anymore.
Then definitely (at least for me) those packages (built for f10) will be very
useful :) 

Comment 31 Kevin J. Cummings 2008-05-14 23:40:25 UTC
(In reply to comment #12)
> I can confirm reproduction with my notebook, but I have to qualify it -- it
> actually works but only until the frist suspend/resume cycle. Does anybody of
> people who confirmed reproduction of this bug did reproduce it from a fresh boot
> of the computer or only after suspend/resuming the computer?

I'll +1 the only after suspend/resume on my RCubed laptop (OEMed from ASUS). 
The touchpad works fine, but after suspend/resume, tapping no longer works.  Let
me know if you need more information from me.  I'm pretty sure that if I
kill/restart the Xserver, the touchpad works again.  I had to add the following
to make it work at all in F9:

> 	Option	    "RTCornerButton" "2"
> 	Option	    "RBCornerButton" "3"
> 	Option	    "TapButton1" "1"
> 	Option	    "TapButton2" "2"
> 	Option	    "TapButton3" "3"


Comment 32 Neil Surowich 2008-05-15 08:19:35 UTC
Thanks for the package Bob. Worked Great.

Comment 33 Joshua Roys 2008-05-15 20:44:13 UTC
+1 for reverting that patch, please...

Comment 34 Shawn Starr 2008-05-16 05:14:32 UTC
(In reply to comment #15)
> > Today i've updated my system and i've got at last my tapping back again ! I
> > didn't test it after suspend/resume, but after booting system it definitely
> > works now for me.
> 
> Note, that I can reproduce this only after suspend/resume. On the fresh boot of
> the computer tapping works.
> 
> Does anybody else observe this as well?

Adding xorg.conf options works, but on suspend/resume tapping stops working.

ALSO, if you switch VT the touch tapping stops working. I have to restart X to
get the tapping to work again.


Comment 35 Adam Jackson 2008-05-16 15:02:47 UTC
There are two problems with shmconfig.  The first is it's insecure.  The shm
segment is created world-writable.  I'm happier not having arbitrary processes
writing into the X server's address space, particularly not processes owned by
other than the session owner.  We could fix this by integrating with ConsoleKit
to shmctl() it to be only accessible by the session user, except...

The second problem is that shmconfig is just plain incompatible with fast user
switching.  The shm segment is created with a fixed segment id.  There's no way
for two users to use it at once.  We could fix the synaptics driver to create a
shm segment keyed off the display number, but that would also require fixing
gsynaptics and friends to look for the new shm segment id.

So, solve both of those things, and shmconfig becomes an option.

Comment 36 Ronald Kuetemeier 2008-05-16 15:38:32 UTC
Adam,
are you saying it will not be fixed?

Comment 37 Brian Wheeler 2008-05-16 17:12:24 UTC
Just another +1 on reverting the disable tap patch.

Comment 38 Matěj Cepl 2008-05-16 17:26:05 UTC
(In reply to comment #35)
> There are two problems with shmconfig.

Take a look at comment 34 -- this is not about shmconfig, but that there doesn't
seem to be a way how to make touch -> mouse-click working.

Comment 39 Matěj Cepl 2008-05-16 17:26:29 UTC
... after suspend/resume, that is.

Comment 40 das 2008-05-17 08:06:18 UTC
+1 for revoking the patch. (Acer Aspire 3000 laptop)

Comment 41 das 2008-05-17 08:10:09 UTC
+1 for revoking the patch. (Dell Inspiron 640m).

Comment 42 Vinu Moses 2008-05-17 11:20:39 UTC
I have the same problem (tapping not working on the touchpad) on my Acer Aspire
4720 laptop. Got around it by adding additional options in the xorg.conf file,
as described in comment #30.



Comment 43 Peter Bloomfield 2008-05-17 12:00:48 UTC
(In reply to comment #42)
> I have the same problem (tapping not working on the touchpad) on my Acer Aspire
> 4720 laptop. Got around it by adding additional options in the xorg.conf file,
> as described in comment #30.

Comment #31 fixes the typo in comment #30.  Does the workaround still work after
suspend?


Comment 44 K Killebrew 2008-05-17 16:49:50 UTC
Confirm addition of touchpad section to xorg.conf works on Dell Latitude C400;
system fails to resume after suspend; after resuming from hibernate,
tap-to-click has been lost.

Comment 45 Matěj Cepl 2008-05-17 19:56:02 UTC
Changing Summary 

Comment 46 Vinu Moses 2008-05-18 10:14:11 UTC
(In reply to comment #43)
> Comment #31 fixes the typo in comment #30.  Does the workaround still work after
> suspend?

No... it does not work after a suspend.

Comment 47 Jaroslaw Gorny 2008-05-18 14:39:57 UTC
+1 for enabling tapping.
To be true I just couldn't believe, somebody disabled it intentionally. After
all, tapping is a normal behaviour of touchpad. Disabling it is just like
disabling 'mouse click' because some users don't like it.

Comment 48 Jonathan Steffan 2008-05-18 23:41:33 UTC
Wow, +1 for enabling tapping.

Comment 49 das 2008-05-19 02:16:07 UTC
The laptop keyboards are quite cramped and difficult, to say the least. And now,
every time you want to click, just bending your finger a bit does not work, you
have to move the whole palm downwards to click the button, and hence to adjust
the fingers once again on the default row of the keyboard. All this due to this
patch. And this seems surprising that still, when this bug which is not a bug
but a patch has rendered the machine almost unusable for some of us, the
criteria show: 
Priority: Low, Severity: Medium

When it can get a high priority and gets considered as adequately severe? After
the bug starts coming out of the machine and gobbling people? And the question
is, as it has already been said in the discussion, why should I go into
readjusting the configuration and rebuilding things, when I do not want anything
special. Touchpads are meant to be tapped and they always were. It must be the
other way round: if some people want their touchpad to remain untouched while
clicking they must go into the trouble.

Comment 50 Sterling Winter 2008-05-19 06:16:48 UTC
Quoting from changelog for the relevant commit:

* Sun Mar 09 2008 Adam Jackson <ajax> 0.14.6-4
  - synaptics-0.14.6-tap-to-click.patch: Disable tap to click by default in
    the name of accessibility.

If we apply that same kind of logic to keyboard drivers, it would be like
disabling the Enter key by default (forcing use of Ctrl-M and such) because a
minority of users tend to accidentally hit the Enter key with their little
fingers while typing. The absurdity in that example is more obvious, but not
fundamentally different from what was done to the Synaptics driver. Enter keys
were made to be pressed out-of-box, and likewise Synaptics touchpads were made
to be tapped out-of-box.

A corner case is a poor justification for diverging so significantly from
upstream's intended behavior, especially when it can be addressed without
patching upstream's code and without -- as evidenced here and on the forums --
placing a greater burden upon users who fit into the majority use case. And
because xorg.conf entries enabling the default tapping behavior are now (for
whatever reason) only sufficient until the user invokes suspend/hibernate, I
would argue that this patch introduced *two* regressions. Please revert this change.

Comment 51 Richard Körber 2008-05-19 08:31:22 UTC
+1 for reverting that patch. It is the expected behaviour of a touchpad. Those
people who dislike tapping, can surely disable it with the proper xorg.conf options.

Comment 52 Oleg Girko 2008-05-19 23:02:17 UTC
Installing packages from comment #29 does not fix the problem completely.

Although tapping now works after suspend/resume or switching virtual desktops,
some parameters are not restored, like the speed of pointer and the width of
scrolling area at the right side of touchpad.

The "synclient -l" command reports correct values for RightEdge, MinSpeed,
MaxSpeed and other parameters, but they don't have effect anymore. Changing
them from "synclient" command change values reported by "synclient -l", but
have no effect on touchpad's behaviour.

The following lines appear in "/var/log/Xorg.0.log" file after returning from
suspend or switching back to virtual console running X server:

(--) AlpsPS/2 ALPS GlidePoint auto-dev sets device to /dev/input/event3
(**) Option "Device" "/dev/input/event3"
(--) AlpsPS/2 ALPS GlidePoint touchpad found
(II) <default pointer>: ps2EnableDataReporting: succeeded
(--) Synaptics auto-dev sets device to /dev/input/event3
(**) Option "Device" "/dev/input/event3"
(WW) Synaptics can't grab event device, errno=16
(--) Synaptics touchpad found

The error happens on line 49 of "eventcomm.c" file: synaptics X driver is
unable to grab event device using EVIOCGRAB ioctl call. Unfortunately, I have
no time now to diagnose why this is happening. Any ideas?

Comment 53 Oleg Girko 2008-05-20 00:03:17 UTC
Does the log messages above mean that touchpad on "/dev/input/event3" is
detected twice? The first one is autodetected as Alps, the second one taken
from "xorg.conf" configuration and detected as synaptics forcefully? Do those
two driver instances conflict in some way?

Comment 54 Sterling Winter 2008-05-20 04:23:45 UTC
(In reply to comment #52)
> Installing packages from comment #29 does not fix the problem completely.
> 
> Although tapping now works after suspend/resume or switching virtual desktops,
> some parameters are not restored, like the speed of pointer and the width of
> scrolling area at the right side of touchpad.


These settings which aren't restored -- are they all customizations from your
xorg.conf?


> (WW) Synaptics can't grab event device, errno=16
> (--) Synaptics touchpad found
> 
> The error happens on line 49 of "eventcomm.c" file: synaptics X driver is
> unable to grab event device using EVIOCGRAB ioctl call. Unfortunately, I have
> no time now to diagnose why this is happening. Any ideas?


I get the same error. Are you on x86_64 by chance? I'm wondering if the Synaptic
driver is getting linked against the wrong libs somewhere.

Comment 55 Oleg Girko 2008-05-20 04:54:41 UTC
(In reply to comment #54)
> (In reply to comment #52)
> > Installing packages from comment #29 does not fix the problem completely.
> > 
> > Although tapping now works after suspend/resume or switching virtual
> > desktops,
> > some parameters are not restored, like the speed of pointer and the width
> > of scrolling area at the right side of touchpad.
> 
> These settings which aren't restored -- are they all customizations from your
> xorg.conf?

Yes. However, "synclient -l" shows correct values, so I presume, another driver
receives events.

> > (WW) Synaptics can't grab event device, errno=16
> > (--) Synaptics touchpad found
> > 
> > The error happens on line 49 of "eventcomm.c" file: synaptics X driver is
> > unable to grab event device using EVIOCGRAB ioctl call. Unfortunately, I
have
> > no time now to diagnose why this is happening. Any ideas?
> 
> 
> I get the same error. Are you on x86_64 by chance?

Yes.

> I'm wondering if the Synaptic driver is getting linked against the wrong
> libs somewhere.

No, I don't think so:
1. I was building synaptics driver myself from SRPM.
2. The "ldd" utility shows that "synaptics_drv.so" is linked with correct
libraries.
3. The synaptics driver succeeds to grab event device using EVIOCGRAB ioctl
first time during initialisation. It fails to grab it later, after resume or
virtual console switching.

Comment 56 Oleg Girko 2008-05-20 05:17:40 UTC
Actually, I have an impression that two or three driver instances compete for
the same touchpad input event device:

(1) the synaptics driver instance configured in "xorg.conf": expected
parameters, SHM enabled, controllable by "synclient";
(2) somehow autoconfigured synaptics driver instance: identifier taken from
"/proc/bus/input/devices", default parameters, SHM disabled, "synclient" talks
to the instance (1), to tapping if tapping disabling patch applied;
(3) in some cases evdev driver takes over: faster pointer movements, no
tapping, to scrolling.

Only one driver instance takes over the event device, all others get EBUSY from
EVIOCGRAB system call. The order of driver invocation is different on X server
initialisation and on resume, so instance (1) wins only the first time, then
another ones do.

Can anybody with deeper knowledge of Xorg driver internals test my hypothesis?

Comment 57 Sterling Winter 2008-05-20 19:08:57 UTC
I can't test this right now but I just noticed that the example xorg.conf on the
Synaptics driver page has this line in the 'ServerLayout' section:

    InputDevice    "TouchPad" "AlwaysCore"

instead of what I've been using:

    InputDevice    "TouchPad" "CorePointer"

This changes the way events are handled so it might be worth a try. (According
to the manpage for xorg.conf a value of 'SendCoreEvents' should behave the same
as 'AlwaysCore' there.)

Another thing to try (but doesn't work for me) is adding 'i8042.reset' or
'i8042.nomux' to the kernel parameters in grub.conf. See:

http://gentoo-wiki.com/HARDWARE_Lenovo_3000_N100#Stuck_num-lock_and_disabled_touchpad_when_waking_from_sleep


Comment 58 Kevin J. Cummings 2008-05-20 20:12:39 UTC
(In reply to comment #57)
> I can't test this right now but I just noticed that the example xorg.conf on the
> Synaptics driver page has this line in the 'ServerLayout' section:
> 
>     InputDevice    "TouchPad" "AlwaysCore"

This is already present in my xorg.conf.  I still experience a loss of tapping
after a suspend/resume.


Comment 59 Axel Thimm 2008-05-21 14:55:54 UTC
(In reply to #bug 437702 comment #1)
> OK, looks like this one was intentional:
> 
> * Mon Mar 10 2008 Adam Jackson <ajax> 0.14.6-4
> - synaptics-0.14.6-tap-to-click.patch: Disable tap to click by default in
>   the name of accessibility.
> 
> I'm not sure this is really a good idea, since this is unexpected behaviour,
> both by upstream documentation as well as shipped documentation (e.g. the patch
> would have had to patch the man pages for example as well).
> 
> Instead it could be something that the gdm login screen could be turning on/off
> along with all the other accessibility items. Also if you really want the
> default to change then do it in teh created xorg.conf, not hardwired in the
> sources where no one will be seraching for this change in behaviour. If F9 ships
> out that way you will get lots of duplicates to this bug report.

OK, so we have 5 reports out of a total of 56 reports of all synaptics bug
reports ever filed. Not the bug raining day, but still a very unpleasant
experience with F9 and tapping.

Fixing it is easy, here is the patch
--- synaptics.spec~	2008-03-28 20:28:10.000000000 +0100
+++ synaptics.spec	2008-04-10 19:45:27.000000000 +0200
@@ -4,3 +4,3 @@
 Version:        0.14.6
-Release:	7%{?dist}
+Release:	8%{?dist}
 Summary:        Synaptics Touchpad Driver
@@ -14,3 +14,2 @@
 Patch1: synaptics-0.14.6-newx.patch
-Patch2: synaptics-0.14.6-tap-to-click.patch
 Patch3: synaptics-0.14.6-poll-delay.patch
@@ -55,3 +54,2 @@
 %endif
-%patch2 -p1 -b .tap
 %patch3 -p1 -b .polldelay
@@ -89,2 +87,5 @@
 %changelog
+* Thu Apr 10 2008 Axel Thimm <Axel.Thimm> - 0.14.6-8
+- Reenable tap to click.
+
 * Fri Mar 28 2008 Rex Dieter <rdieter> 0.14.6-7

And for the ones too lazy to rebuild I've placed the fixed synaptics package in
ATrpms' testing area or you can get it directly from

http://atrpms.net/dist/f9/synaptics/

Bought my sanity back.

Comment 60 Jan "Yenya" Kasprzak 2008-05-22 11:00:15 UTC
I have ASUS M6R with similar problems (both with stock F9 synaptics package, and
with the one from ATRPMS - comment #59). The configuration of my touchpad is
apparently lost both after the suspend/resume _and also_ after switching to the
text console and back. I dont use tap-to-click, but I use UpDownScrolling=0
(i.e. the "scroll down" button sends the "button 2" X event). Running synclient
-l shows no difference between the just-started X server and the X server after
suspend/resume or switch from another VC). Even running "synclient
UpDownScrolling=1; synclient UpDownScrolling=0" does not help.

In Fedora 8, UpDownScrolling=0 worked without problem (both after
suspend/resume, and after switch to another virtual console and back).

I have tried to rebuild and install synaptics-0.14.6-2.fc8.src.rpm from F8
updates, but the problem remains. So I think the problem is in the X server
itself (maybe libpciaccess?), not in the synaptics driver.

Comment 61 Alistair 2008-05-22 17:49:18 UTC
(In reply to comment #9)
> HP nx7400:
> - scrolling works out of the box
> - tapping does not work

Slight difference of perspective...

Scrolling works *always*, even if supposedly turned off using synclient.  (I
HATE horizontal scrolling!)

Tapping sometimes works after X-server start-up, but never survives suspend/resume.

A

Comment 62 Naveed Hasan 2008-05-23 02:07:54 UTC
Please revoke the tap-to-click disabling patch as this is a significant
divergence from expected touchpad behavior and quite annoying after a
suspend/resume cycle. Thanks.

Comment 63 Rohit V. Kapoor 2008-05-24 00:14:28 UTC
Can this buggy patch be removed? Have to kill my X everytime after a suspend
cycle to get my touchpad to work again. 


Comment 64 Rohit V. Kapoor 2008-05-24 00:34:45 UTC
(In reply to comment #59)
> And for the ones too lazy to rebuild I've placed the fixed synaptics package in
> ATrpms' testing area or you can get it directly from
> 
> http://atrpms.net/dist/f9/synaptics/
> 
> Bought my sanity back.

Thanks a lot Alex!!! Dude you rock for helping us all out from this insanity!! 

And yes, too lazy to rebuild anything ;-) ... your RPMs work great!

Comment 65 Oleg Girko 2008-05-25 02:18:46 UTC
I've found the cause of the problem.

I have an evidence that the problem described here is caused by two conflicting
instances of synaptics driver contending for the same input device. I've
slightlty modified the driver source adding more debugging output, so log
messages make it obvious. However, studying "Xorg.0.log" carefully even without
additional debugging output can reveal this problem.

The first instance is the one configured in "xorg.conf". It is initialised the
first, it works correctly according to options configured in "xorg.conf". If it
has "SHMConfig" option set to on, it can be controlled by "synclient" utility.

The second instance is autoconfigured. It's name is taken from
"/proc/bus/input/devices", it has default configuration. As default configuration
does not have "SHMConfig" option, it can't be controlled with "synclient"
utility.

At the moment of initialisation, "/dev/input/event3" (or whatever device used by
touchpad) is already grabbed by the first instance (EVIOCGRAB ioctl), so the
second instance gets no input from the touchpad device and therefore has no
effect.

However, after virtual console switching (or suspend/resume) the second
(autoconfigured) instance is turned on first (DeviceOn function). It grabs input
device with EVIOCGRAB ioctl, getting all touchpad input. The first (user-
device is already grabbed.

As the result, the second (autoconfigured) instance controls all touchpad input.
The first (user-configured) instance is still alive, it can be controlled by
"synclient" utility, but it gets no input from touchpad device, and hence has no
effect.

If there is no "InputDevice" section for touchpad device in "xorg.conf", only one
(autoconfigured) instance is started, with default parameters. I didn't find the
way to configure this instance. Naming touchpad device in "InputDevice" section
with exactly the same name as autoconfigured instance doesn't help: two instances
with the same names are started.

Removing "/usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi" file doesn't
prevent autoconfigured instance from being started. It even makes situation
worse, because after removing this file (and rebooting or restarting HAL), the
autoconfigured instance is controlled by much less capable evdev driver.

Enabling tapping in default configuration does not solve the problem, it just
eases the pain: there's tapping available after virtual console switching or
suspend/resume, but the driver settings are still default, and there's no way to
change them with "synclient" utility (it changes parameters of the first
instance, which has no effect).

Please find why the second synaptics driver instance is started, and either make
it not start if there's already synaptics driver instance configured in
"xorg.conf", or make this autoconfigured instance configurable.

Comment 66 das 2008-05-25 02:47:15 UTC
(In reply to comment #59)

> And for the ones too lazy to rebuild I've placed the fixed synaptics package in
> ATrpms' testing area or you can get it directly from
> 
> http://atrpms.net/dist/f9/synaptics/
> 
> Bought my sanity back.

Both the machines about which I reported the problem, Acer Aspire 3000 and Dell
Inspiron 640M, are now working fine. In fact, in both the cases the touchpads
are now working better than ever before. (Maybe I am getting a bit emotional
after these 'untapped' days!). 

Just installed the http://dl.atrpms.net/all/synaptics-0.14.6-8.fc9.i386.rpm
provided by Axel Thimm, and it was great. Just added this section to the
'xorg.conf':

<<
Section "InputDevice"
	Driver	"Synaptics"
	Identifier	"TouchPad"
	Option	"SHMConfig" "on"
EndSection 
>>

Everything else was done by Thimm's rpm, 'synclient -l' shows it. 

A season of summer and mangos here in Calcutta, emailing a few for Thimm.

Comment 67 das 2008-05-25 02:59:36 UTC
And on both the machines Acer and Dell, it is working after suspend/resume.

Comment 68 Martin Ebourne 2008-05-27 00:53:03 UTC
The disabled tapping after suspend had been annoying me a lot. And after I
upgraded several of my family's machines to F9 this weekend I got very strong
complaints on the lack of tapping.

In addition to the real bug in comment #65 we really need to find some better
way of solving the accessibility problem that doesn't clobber tapping by
default, which most people find essential on laptops.

Comment 69 Leo 2008-06-08 20:30:03 UTC
It's really sad that this usability problem has not been fixed. Many users that
have accustomed to the old behaviour have their productivity compromised by this
simple bug.

Comment 70 Ilpo Nyyssonen 2008-06-09 03:51:56 UTC
It's not just usability problem. It's a clear bug. Disabling the tapping by
default wouldn't be a big problem, but not being able to enable it is. Fix this
ASAP.

Comment 71 Ilpo Nyyssonen 2008-06-20 08:19:30 UTC
As a workaround

Section "ServerFlags"
        Option "AutoAddDevices" "no"
EndSection

helped for me with the "two driver instances problem" described in comment #65.

Comment 72 Sterling Winter 2008-06-20 14:37:21 UTC
(In reply to comment #71)

With the above workaround my custom Synaptics settings are preserved after
suspend/resume cycles.

However, if all of your X-mediated devices are not specified in xorg.conf this
workaround will probably disrupt the functioning of the unspecified devices upon
resume.

Comment 73 Matěj Cepl 2008-06-21 19:32:43 UTC
*** Bug 447310 has been marked as a duplicate of this bug. ***

Comment 74 Matěj Cepl 2008-06-21 19:33:06 UTC
*** Bug 452367 has been marked as a duplicate of this bug. ***

Comment 75 Greg Martyn 2008-07-01 02:36:23 UTC
++ to whoever fixes this w/o 3rd party rpm && w/o xorg.conf modification

Comment 76 Brian Wheeler 2008-07-01 12:39:56 UTC
This is starting to get stupid.  3 months since the original bug report, several
duplicate bugs, and no 'official' solution!  What exactly is the holdup?  

The patch that broke this can be rolled back, and a solution for the people who
DON'T want tap-to-click can be found, since they're in a minority. 

Comment 77 Jan "Yenya" Kasprzak 2008-07-01 13:29:16 UTC
Re: comment #76 - the problem is not in that patch. As said above (comment #65),
the same problem is with each user-defined option which is different from the
default - the settings are lost on suspend/resume or console switch (for me,
I don't care about tap-to-click, but I would like to have UpDownScrolling=0). 

Having a different default for tap-to-click (or up-down-scrolling) is a dirty
hack, for which third-party packages can be used. 

What this bug really needs is a system way how to disable the second input
driver being initialized at all, so that user defined settings work.

That said, I would also welcome the faster solution of this problem.

Comment 78 John Foderaro 2008-07-01 17:58:03 UTC
This is a high priority bug for me.  I'm going to hold off upgrading my laptops
to F9 until there is an official fix.


Comment 79 Mike C 2008-07-02 19:09:12 UTC
Created attachment 310841 [details]
xorg.conf

On a newly installed F9 on Dell Precision laptop (M4300) I had no tap to click
on the touchpad, and very slow mouse acceleration. This xorg.conf gave good
mouse response once X was restarted.

This was a clean install, and full yum update before testing.

This is a workaround and I would expect the touchpad to work without having to
mess with xorg.conf especially as in the future xorg.conf may not be present
after F10

Comment 80 Charlie Bennett 2008-07-04 19:47:43 UTC
I was having something of the same problem.  Lenovo T61p.

1. use gsynaptic to disable the touchpad altogether (wiggle only, please)
2. hibernate
3. wake up
4. touchpad magically enabled, can't disable

The workaround in comment #71 fixed this.

Comment 81 Phil 2008-07-14 01:10:10 UTC
+1 for #59, #71

I, too, consider this a high priority...

Comment 82 Peter Hutterer 2008-07-14 07:33:16 UTC
The xfree86 DDX kept its list of input devices in reverse order to the DIX. This
lead to the devices being initialised in the wrong order when waking up from
suspend.

Now, since the driver may grab the device file, if the second device wakes up
first, it leaves the first (original) device in the open, and the settings
change. I just pushed a patch to xserver that should fix this issue. 

http://cgit.freedesktop.org/xorg/xserver/commit/?id=11ee0ae9390a608a232ff94abcc0cbcf9ed7b70a

Comment 83 nikosapi 2008-07-16 10:55:59 UTC
Thanks Peter Hutterer, that patch works great!

Comment 84 Sterling Winter 2008-07-24 04:35:52 UTC
For a deeper explanation of the Xorg changes that sparked the competing
Synaptics driver issue, Peter Hutterer has just made an excellent blog post:

http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html


Comment 85 Ilpo Nyyssonen 2008-07-25 04:54:09 UTC
Nice, so it is possible to configure the synaptics with HAL fdi. Works just fine.

It is just the documentation and communication about this big change in how
things are configured that are sucking so deeply.

Comment 86 Matěj Cepl 2008-07-25 06:06:45 UTC
Some information about the fdi configuration files is here
http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi

Comment 87 Matěj Cepl 2008-07-25 07:16:45 UTC
Created attachment 312620 [details]
FDI configuration for synaptics driver

OK, so I think I have workaround working with the original Fedora-supplied
drivers and edev.

1) Drop this file into /etc/hal/fdi/policy/10-synaptics.fdi
2) restart haldaemon
3) follow instructions in comment 84 to make your Xorg use edev instead of
direct synaptics
4) restart Xorg

Does it work?

Comment 88 Matěj Cepl 2008-07-25 07:18:22 UTC
(note for us -- we have to lie to edev driver claiming that
input.x11_options.TapButton1 is string, whereas it should be int)

Comment 89 Jan "Yenya" Kasprzak 2008-08-11 15:25:57 UTC
The solution from comment #87 works for me. Thanks, Matej!

Comment 90 Michal Klich 2008-08-11 22:13:01 UTC
Yes, that fixes tapping issue but i am not able to scroll up and down with my pad right now. I have used workaround proposed in comment 87.

Comment 91 Peter Hutterer 2008-08-11 23:50:52 UTC
(In reply to comment #90)
> Yes, that fixes tapping issue but i am not able to scroll up and down with my
> pad right now. I have used workaround proposed in comment 87.

you need to add the respective input.x11_options.XYZ to the fdi file. for scrolling, this would be VertEdgeScroll. other options are described in the synaptics man page.

Comment 92 Dominik 'Rathann' Mierzejewski 2008-08-14 20:31:28 UTC
Confirmed on FS Amilo Pro V3505, tapping added in xorg.conf is gone after hibernate/thaw cycle. Restarting Xorg brings it back.

Comment 93 Peter Hutterer 2008-08-18 01:29:16 UTC
(In reply to comment #92)
> Confirmed on FS Amilo Pro V3505, tapping added in xorg.conf is gone after
> hibernate/thaw cycle. Restarting Xorg brings it back.

An explanation why is in Comment #82, with a solution in #87.

If you do not think that this is the case, please supply your log file and xorg.conf.

Comment 94 Dominik 'Rathann' Mierzejewski 2008-08-18 11:06:33 UTC
(In reply to comment #93)
> (In reply to comment #92)
> > Confirmed on FS Amilo Pro V3505, tapping added in xorg.conf is gone after
> > hibernate/thaw cycle. Restarting Xorg brings it back.
> 
> An explanation why is in Comment #82, with a solution in #87.

The solution from #87 does work. Tapping survives both VT switching and suspend, thanks a lot.

Comment 95 Fedora Update System 2008-08-22 16:21:03 UTC
synaptics-0.14.6-9.fc9 has been submitted as an update for Fedora 9.
/updates/synaptics-0.14.6-9.fc9

Comment 96 Fedora Update System 2008-08-25 09:16:19 UTC
xorg-x11-drv-synaptics-0.15.0-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-0.15.0-2.fc9

Comment 97 Fedora Update System 2008-09-05 12:20:30 UTC
xorg-x11-drv-synaptics-0.15.0-2.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-synaptics'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7264

Comment 98 Stephen Warren 2008-09-06 22:20:36 UTC
A tiny bit more information for people trying to get /etc/hal/fdi/policy/10-synaptics.fdi to work, but finding that it has no effect:

This file has two sections, which define options for two different types of touchpad hardware:

  <match key="info.product" contains="Synaptics TouchPad">
    ...
  </match>

and:

  <match key="info.product" contains="AlpsPS/2 ALPS">
    ...
  </match>

The example file attached to this bug report only includes the required options in the first of these sections. I had to place the options (copy/paste them) inside the second section for them to apply with the hardware present in my laptop.

After doing that, and deleting pretty much everything from xorg.conf (except 'Driver "nvidia"') it all works:-)

Comment 99 Fedora Update System 2008-09-07 13:31:43 UTC
xorg-x11-drv-synaptics-0.15.0-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-0.15.0-3.fc9

Comment 100 Matěj Cepl 2008-09-09 22:02:59 UTC
*** Bug 459265 has been marked as a duplicate of this bug. ***

Comment 101 David Richardson 2008-09-11 03:39:13 UTC
Though probably not completely tested, I have downloaded and installed the xorg-x11-drv-synaptics update and it works wonderfully on my Gateway laptop with Fedora 9.  However, like many, I have discovered that while typing on the keyboard sometimes the cursor moves when I don't want it to.  To remedy the situation, I purchased a mouse.  Now that I have installed the update, how to I disable my touchpad???  Thank you in advance.

Comment 102 Fedora Update System 2008-09-11 17:15:10 UTC
xorg-x11-drv-synaptics-0.15.0-3.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-synaptics'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7968

Comment 103 Rohan Dhruva 2008-09-13 06:25:16 UTC
Hi,

I tried the command given in comment 102 but it doesn't work. No updates are available for that package.

I followed the instructions in commment 87 but IMO it gives rise to more problems than it solves:
1) My 4-way scroller button (below the touchpad in between the two click buttons) no longer works - clicking "down" now works as right click
2) The clicking is VERY sensitive
3) I can't scroll by gliding in the right of the touchpad
4) Clicking with two fingers should be equal to middle click, but that doesn't work. Similarly, clicking with three fingers should be equal to right click

I don't know which of these are X.org bugs and which are evdev bugs. Is there any way to resolve the 4 issues I mentioned above?

I hope this problem doesn't occur in Fedora 10!

Comment 104 Rohan Dhruva 2008-09-13 06:47:09 UTC
One more thing which doesn't work is - I can't double tap and then move my finger to simulate a drag action. That's one of the big "conveniences" I miss too.

Comment 105 Peter Hutterer 2008-09-15 04:46:57 UTC
(In reply to comment #103)
> 1) My 4-way scroller button (below the touchpad in between the two click
> buttons) no longer works - clicking "down" now works as right click

This indicates that option UpDownScrolling is off. Switching it on should fix this. Likewise, LeftRightScrolling may need to be switched on. 

> 2) The clicking is VERY sensitive

can you define sensitive? this is a physical button, right? does it emit too many scroll events when you click?

If so, you can control this behaviour with the UpDownScrollRepeat and ScrollButtonRepeat options.

> 3) I can't scroll by gliding in the right of the touchpad

This usually indicates that either vert scrolling is turned off, or that the right edge is misconfigured (too high). To scroll, the coordinates the driver receives from the touchpad must be greater than the RightEdge setting.

> 4) Clicking with two fingers should be equal to middle click, but that doesn't
> work. Similarly, clicking with three fingers should be equal to right click

The following settings enable the behaviour you want
ClickFinger2 = 2 
ClickFinger3 = 3

All above options can be added to the fdi file in the same manner as the other options. Can you please try it and tell us if it fixes it for you?

> One more thing which doesn't work is - I can't double tap and then move my
> finger to simulate a drag action. That's one of the big "conveniences" I miss
> too.

Normal tap works fine though? If not, try increasing MaxTapMove.
I'm running 0.15.1-fc10 and double-tap drag works fine, so it might be some local setting.

Comment 106 Rohan Dhruva 2008-09-15 14:51:47 UTC
Hi Peter,

I removed the synaptics package using rpm -e --nodeps. I then installed x11-drv-synaptics package 0.15.1 from here -- http://koji.fedoraproject.org/koji/buildinfo?buildID=62375

However, that still doesn't solve any problem. I am attaching my 10-synaptics.fdi for your reference.

Comment 107 Rohan Dhruva 2008-09-15 14:55:48 UTC
Created attachment 316754 [details]
My synaptics.fdi

Adding all those options still don't solve the problems I mentioned.

Comment 108 markm 2008-09-15 15:10:27 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Today i've updated my system and i've got at last my tapping back again ! I
> > didn't test it after suspend/resume, but after booting system it definitely
> > works now for me.
> 
> Note, that I can reproduce this only after suspend/resume. On the fresh boot of
> the computer tapping works.
> 
> Does anybody else observe this as well?

Recently I have installed Fedora 9 on two Dell laptops: XPS M1330 and Latitude D620 - fresh fedora 9 install with all updates and tapping/scrolling does not work.

Comment 109 Peter Hutterer 2008-09-16 00:07:42 UTC
(In reply to comment #107)
> Adding all those options still don't solve the problems I mentioned.

Did you restart HAL and X (in that order) after adding the fdi file?
Please run "hal-device" and then look through the output if the options you added show up at the touchpad device. I noticed that the fdi only includes the parameters for SynPS/2 touchpads - maybe your model is an ALPS?


(In reply to comment #108)
> Recently I have installed Fedora 9 on two Dell laptops: XPS M1330 and Latitude
> D620 - fresh fedora 9 install with all updates and tapping/scrolling does not
> work.

0.15.1 has bad defaults for MaxTapMove - seemingly breaking tapping on touchpads that aren't appletouch/bcm974 models. Try re-setting MaxTapMove to 220, either in your xorg.conf or in the fdi file.

Regarding scrolling: I found that some devices report wrong axis ranges. e.g. my touchpad claims range 0-1500, but the effective maximum is 1200. Since the autodetection sets up the edge in the non-reachable range, scrolling breaks. Could this be the issue with your touchpad? Try adjusting RightEdge towards the center.

Comment 110 Peter Bloomfield 2008-09-16 01:00:05 UTC
(In reply to comment #109)
[ snip ]
> (In reply to comment #108)
> > Recently I have installed Fedora 9 on two Dell laptops: XPS M1330 and Latitude
> > D620 - fresh fedora 9 install with all updates and tapping/scrolling does not
> > work.
> 
> 0.15.1 has bad defaults for MaxTapMove - seemingly breaking tapping on
> touchpads that aren't appletouch/bcm974 models. Try re-setting MaxTapMove to
> 220, either in your xorg.conf or in the fdi file.

Thanks for the tip!  Tapping was really random with xorg-x11-drv-synaptics-0.15.1-1.fc10.i386--tap was seen maybe 10% of the time.  Setting MaxTapMove to 220 has made it 100% so far--seems like something around there should be the default :)

Comment 111 Rohan Dhruva 2008-09-16 13:04:32 UTC
(In reply to comment #109)
> 
> Did you restart HAL and X (in that order) after adding the fdi file?
> Please run "hal-device" and then look through the output if the options you
> added show up at the touchpad device. I noticed that the fdi only includes the
> parameters for SynPS/2 touchpads - maybe your model is an ALPS?
> 
> 

Yes, I restarted the computer to be sure. I have modified my fdi file to include parameters for ALPS touchpads, but hal-device shows that my touchpad is Synaptics. Either I am doing something very wrong, or something is broken in my system. Can you please attach your synaptics.fdi file so that I could compare? I am attaching my synaptics.fdi and hal-device output. The latter does not show the additional options which I have mentioned. In xorg.conf ServerLayout section, I have Option         "AutoAddDevices" "off" so there should be no conflict with HAL/evdev.

Please tell me where am I going wrong.

Comment 112 Rohan Dhruva 2008-09-16 13:07:06 UTC
Created attachment 316847 [details]
Modified synaptics.fdi

This one still doesn't work.

Comment 113 Rohan Dhruva 2008-09-16 13:08:31 UTC
Created attachment 316848 [details]
Output of hal-device. Relevant portion starts from line 125.

Comment 114 Fedora Update System 2008-09-16 23:27:05 UTC
xorg-x11-server-1.5.0-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 115 Peter Hutterer 2008-09-17 01:53:06 UTC
(In reply to comment #112)
> Created an attachment (id=316847) [details]
> Modified synaptics.fdi
> 
> This one still doesn't work.

<match key="info.product" contains="Synaptics Touchpad">

TouchPad, not Touchpad. That should fix it.

Comment 116 Rohan Dhruva 2008-09-17 02:05:22 UTC
I can't believe I made such a foolish mistake. However, still the problems are not solved! I restarted my computer, so there is no chance of HAL not updating. All the fdi options are now shown in hal-device output, but it seems that the effect hasn't taken place. The 4 way scroller button still doesn't work, neither does double-click-and-drag. Can you please attach your synaptics.fdi file for my reference? I think I am making a mistake in the syntax somewhere.

Comment 117 Peter Hutterer 2008-09-17 02:16:11 UTC
Rohan:
This seems to be a separate issue from the problem described in this bugreport then. 

Please open a new bug against xorg-x11-drv-synaptics and attach your xorg.log, synaptics.fdi and the comment 103. Also, please list the version of synaptics you are currently running. You can assign the bug to me.
btw. I use the stock fdi file, but I don't have a scroller button either.

Comment 118 Stephen Warren 2008-09-17 03:17:27 UTC
Rohan: I copied/pasted all the <merge>...</merge> lines inside this section too:

      <match key="info.product" contains="AlpsPS/2 ALPS">

Since my touchpad seems to not be named "Synaptics TouchPad".

Comment 119 Rohan Dhruva 2008-09-18 19:36:23 UTC
(In reply to comment #117)
> Rohan:
> This seems to be a separate issue from the problem described in this bugreport
> then. 
> 
> Please open a new bug against xorg-x11-drv-synaptics and attach your xorg.log,
> synaptics.fdi and the comment 103. Also, please list the version of synaptics
> you are currently running. You can assign the bug to me.

Hi,

Here is the new bug I have created - https://bugzilla.redhat.com/show_bug.cgi?id=462771

Thanks for patiently helping me so for.

Comment 120 Fedora Update System 2008-09-25 00:07:13 UTC
xorg-x11-drv-synaptics-0.15.0-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 121 Sergio Basto 2009-05-13 16:40:39 UTC
please https://fedoraproject.org/wiki/Input_device_configuration


Note You need to log in before you can comment on or make changes to this bug.