Bug 282949 – xf86-input-synaptics-1.1.3: syndaemon uses bogus touchpad device

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Per Öberg 2009-08-27 19:35:30 UTC]

Syndaemon fails to disable the touchpad because it accidently finds another bogus touchpad which it disables instead.

Since SHM-option is unsafe and pretty much disabled in syndaemon (The option is gone from the accepted inputs but the code is still present in syndaemon.c and the man-page says it should be available, but anyways...) i was unable to get the syndaemon to work with 1.1.3.

xinput seems to work fine though as long as i use my device name "TouchPad" from xorg.conf.  That is, xinput set-int-prop "TouchPad" "Synaptics Off" 8 1,
actually disables my touchpad.

After hacking away in syndaemon.c i discovered that syndaemon finds the device by picking the first matching touchpad. For some reason i have a toucpad called 'SynPS/2 Synaptics TouchPad' which is found instead. Forcing syndaemon to not use this device fixes the problem.


I realize that my configuration might be at fault because i use /etc/x11/xorg.conf instead of hal but i see no reason why this should happen and i find that there isn't a lot of documentation. 

Relevant  xorg.conf section 

Section "ServerLayout"
    Option "AIGLX" "true"
    Identifier     "Layout0"
    Screen      0  "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "TouchPad" "CorePointer"
EndSection

 Section "InputDevice"
    Driver      "synaptics"
    Identifier  "TouchPad"
    Option      "SendCoreEvents"
    Option      "VertEdgeScroll"        "true"
    Option      "TapButton1"    "1"
    Option      "Protocol" "auto-dev"
    #    Option      "SHMConfig" "on"
 EndSection



Reproducible: Always

Steps to Reproduce:
1. emerge -av =x11-drivers/xf86-input-synaptics
2. edit xorg.conf, skip hal config
3. start x
4. log in and start syndaemon

Actual Results:  
syndaemon does not disable the touchpad

Expected Results:  
syndaemon should disable the touchpad

[Comment 1 Per Öberg 2009-08-27 19:58:32 UTC]

Created attachment 202431 [details, diff]
Adds device name option to syndaemon

I realize that this is an upstreams issue but by putting it here for others to find it can be helpful to other people.

I added a feature to choose device name for syndaemon

[Comment 2 Per Öberg 2009-08-28 08:13:18 UTC]

Ok, a little more digging reveales that hal is configuring another touchpad input device after my hardcoded xorg.conf touchpad.

Xorg.0.log reveals: 

(II) Synaptics touchpad driver version 1.1.3
(--) TouchPad auto-dev sets device to /dev/input/event5
(**) Option "Device" "/dev/input/event5"
(--) TouchPad: touchpad found
.
.
.
(II) XINPUT: Adding extended input device "TouchPad" (type: TOUCHPAD)
(--) TouchPad: touchpad found


and later 

(II) config/hal: Adding input device SynPS/2 Synaptics TouchPad
(II) Synaptics touchpad driver version 1.1.3
(**) Option "Device" "/dev/input/event5"
.
.
.
(WW) SynPS/2 Synaptics TouchPad can't grab event device, errno=16
(--) SynPS/2 Synaptics TouchPad: touchpad found


What I can't understand is why hal adds my touchpad even though i didn't add any configuration file. Even if the original bug-report is more or less invalid i still se a couple of points to be made

1) Having more than one touchpad controlled (which indeed seems strange)  is not possible at the moment.

2) Even though there is a message from the ebuild that hal is used for configuration I didn't realize that this means that configuring the touchpad through xorg.conf could cause weird problems. This could be clarified in the ebuild

Sorry for taking up everyones time. Maybe this report can help someone though...

[Comment 3 Christoph Brill (egore) (RESIGNED) 2011-03-09 22:18:02 UTC]

I doubt this still reproducable with xf86-input-synaptics-1.3.0 and xorg-server-1.9.4 (which is the minimum version in portage), as this version no longer relies on hal but xorg.conf.d and this is caused by a "misconfiguration". Next to that SHM was also removed.

Therefore I'm closing this bug.