Bug 600650 - touchpad sometimes stops working after login
touchpad sometimes stops working after login
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
14
All Linux
low Severity high
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-05 08:32 EDT by Bradley
Modified: 2010-11-27 18:38 EST (History)
7 users (show)

See Also:
Fixed In Version: xkeyboard-config-1.9-7.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-27 18:38:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg.conf (300 bytes, text/plain)
2010-06-12 09:20 EDT, Bradley
no flags Details
dmesg after VT switch to VT2 but before switch back (121.89 KB, text/plain)
2010-06-12 09:21 EDT, Bradley
no flags Details
Later dmesg (121.98 KB, text/plain)
2010-06-12 09:21 EDT, Bradley
no flags Details
Xorg log (57.55 KB, text/plain)
2010-06-12 09:22 EDT, Bradley
no flags Details
messages from bootup (76.75 KB, text/plain)
2010-06-12 09:25 EDT, Bradley
no flags Details

  None (edit)
Description Bradley 2010-06-05 08:32:14 EDT
Description of problem:

After upgrading to 1.2.2-6, my touchpad stops working after I login. It works fine in gdb, but as soon I as log in (gnome/metacity), it stops working, both the pad and the buttons.

Downgrading (and then restarting X) fixing this.

Nothing in Xorg.log or ~/.xsession-errors

Version-Release number of selected component (if applicable):

xorg-x11-drv-synaptics-1.2.2-3.fc13.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Enable touchpad
2. Log in
  
Actual results:

Touchpad doesn't work

Expected results:

Touchpad works

Additional info:

No xorg.conf. I'm using the binary nvidia drivers, but I dont think that that would matter

Relevant bits from Xorg.log (both with the working and broken versions):

[   823.314] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event7)
[   823.314] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall"
[   823.314] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad catchall"
[   823.314] (II) LoadModule: "synaptics"
[   823.314] (II) Loading /usr/lib64/xorg/modules/input/synaptics_drv.so
[   823.314] (II) Module synaptics: vendor="X.Org Foundation"
[   823.314]    compiled for 1.7.99.901, module version = 1.2.2
[   823.314]    Module class: X.Org XInput Driver
[   823.314]    ABI class: X.Org XInput driver, version 9.0
[   823.314] (II) Synaptics touchpad driver version 1.2.2
[   823.314] (**) Option "Device" "/dev/input/event7"
[   823.325] (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472
[   823.325] (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448
[   823.325] (II) SynPS/2 Synaptics TouchPad: pressure range 0 - 255
[   823.325] (II) SynPS/2 Synaptics TouchPad: finger width range 0 - 0
[   823.325] (II) SynPS/2 Synaptics TouchPad: buttons: left right double triple
[   823.333] (--) SynPS/2 Synaptics TouchPad: touchpad found
[   823.333] (**) SynPS/2 Synaptics TouchPad: always reports core events
[   823.337] (II) XINPUT: Adding extended input device "SynPS/2 Synaptics TouchPad" (type: TOUCHPAD)
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) keeping acceleration scheme 1
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration profile 0
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration factor: 2.000
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration threshold: 4
[   823.314] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event7)
[   823.314] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall"
[   823.314] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad catchall"
[   823.314] (II) LoadModule: "synaptics"
[   823.314] (II) Loading /usr/lib64/xorg/modules/input/synaptics_drv.so
[   823.314] (II) Module synaptics: vendor="X.Org Foundation"
[   823.314]    compiled for 1.7.99.901, module version = 1.2.2
[   823.314]    Module class: X.Org XInput Driver
[   823.314]    ABI class: X.Org XInput driver, version 9.0
[   823.314] (II) Synaptics touchpad driver version 1.2.2
[   823.314] (**) Option "Device" "/dev/input/event7"
[   823.325] (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472
[   823.325] (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448
[   823.325] (II) SynPS/2 Synaptics TouchPad: pressure range 0 - 255
[   823.325] (II) SynPS/2 Synaptics TouchPad: finger width range 0 - 0
[   823.325] (II) SynPS/2 Synaptics TouchPad: buttons: left right double triple
[   823.333] (--) SynPS/2 Synaptics TouchPad: touchpad found
[   823.333] (**) SynPS/2 Synaptics TouchPad: always reports core events
[   823.337] (II) XINPUT: Adding extended input device "SynPS/2 Synaptics TouchPad" (type: TOUCHPAD)
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) keeping acceleration scheme 1
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration profile 0
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration factor: 2.000
[   823.337] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration threshold: 4
[   823.345] (--) SynPS/2 Synaptics TouchPad: touchpad found
[   823.345] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse1)
[   823.345] (EE) No input driver/identifier specified (ignoring)
Comment 1 Bradley 2010-06-06 05:30:55 EDT
Its not the update - it failed on the downgraded version after a VT switch.

The 'fix' when this happens seems to be:

1. disable touchpad using the hardware switch
2. vt switch away from X
3. vt switch back to X
4. Re-enable touchpad using the hardware switch

xinput --list-props shows 'Device Enabled' as 0 when this happens, and setting it to 1 doesn't help. When I do that, Xorg log shows:

(--) SynPS/2 Synaptics TouchPad: touchpad found

but --list-props shows it as still 0.

This happens with nouveau too, so its definitely not the binary Nvidia driver.
Comment 2 Matěj Cepl 2010-06-11 08:35:32 EDT
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Are you configuring your touchpad manually in xorg.conf? Do you have any configuration files for your touchpad in /etc/X11/xorg.conf.d/?

Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* whole X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

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.
Comment 3 Bradley 2010-06-12 09:19:42 EDT
No touchpad config in xorg.conf.d. or xorg.conf. Will attach files. In Xorg.0.log, time 145 is when I switched to VT2 after disabling the hw switch, and 192 is when I switched back to VT1 (X). There were no extra log messages when I enabled the switch again, but the touchpad did keep working.

Again, it worked fine at the login screen (gdm) and only stopped working after login.

dmesg wrapped due to the debug; the first version is after the VT switch and the second is later, after teh switch back; there is enough overlap to tie them together.
Comment 4 Bradley 2010-06-12 09:20:29 EDT
Created attachment 423500 [details]
xorg.conf
Comment 5 Bradley 2010-06-12 09:21:03 EDT
Created attachment 423501 [details]
dmesg after VT switch to VT2 but before switch back
Comment 6 Bradley 2010-06-12 09:21:39 EDT
Created attachment 423502 [details]
Later dmesg
Comment 7 Bradley 2010-06-12 09:22:01 EDT
Created attachment 423503 [details]
Xorg log
Comment 8 Bradley 2010-06-12 09:25:20 EDT
Created attachment 423505 [details]
messages from bootup
Comment 9 NSLW 2010-06-15 01:47:49 EDT
I've got the same problem.
Comment 10 NSLW 2010-06-25 05:33:17 EDT
What's the status of this bug? Touchpad still stops working after login if it isn't used at log in screen.
Comment 11 NSLW 2010-07-01 14:06:33 EDT
I don't encounter this bug no more. How it's with the original reporter?
Comment 12 Bradley 2010-07-03 04:21:44 EDT
I still see this, but only if I boot with the touchpad h/w switch off.
Comment 13 Bradley 2010-08-01 01:02:48 EDT
Also see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/549727

The workarround of doing:

gconftool -s /desktop/gnome/peripherals/touchpad/touchpad_enabled -t boolean true
killall gnome-session

works but then after a reboot and login with the touchpad h/w button disabled, it somehow ends up in false again
Comment 14 Peter Hutterer 2010-08-02 18:29:47 EDT
Bradley: for clarification, when you boot with the touchpad hw button disabled (how does this button look like?) then touchpad_enabled is false. enabling the touchpad in hardware does not change the gconf setting.
is this correct?

if so, does the hw button spit out any events that we can listen for?


either way, not a synaptics issue, gnome-settings-daemon instead.
Comment 15 Bradley 2010-08-03 08:04:06 EDT
There's a physical (ie hardware) light - blue==on, amber==off. This seems to be managed in hardware - the switch toggles fine even before the boot process has finished. (Its also software controllable; windows restores it to the last state on bootup - I see it changing colour mid-way through the bootup. Linux has never done that, but that's almost certainly a separate issue)

It spits out a scancode (showkey says 192 is off and 193 is on), but I don't think that that's the issue - it works fine in the gdm login screen and only dies as I log in.

It feels like something (gnome-settings-daemon?) is reading some hardware state that reflects the bootup state not the current state, and then disabling the touchpad in gconf based on that. The once its disabled it never checks that state again to reenable that, whether on key change or a reboot. Thats a total guess, though.
Comment 16 Bastien Nocera 2010-10-27 10:09:39 EDT
Given this:
Jun 12 23:12:40 plum kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
Jun 12 23:12:41 plum kernel: psmouse.c: resync failed, issuing reconnect request

I'd go as far as to say that the problem is hardware related.

In GNOME, the only things setting the "touchpad enabled" GConf key are the mouse configuration in gnome-control-center, and gnome-settings-daemon's media-keys plugin, which handles the "touchpad" button.

What could happen is that the hardware both spits out a keyboard event, and enables/disables the hardware. Which means that we'd be getting the state of it wrong.

Could you try:
- disable the touchpad key press handling by disabling the "media-keys" plugin (set /apps/gnome_settings_daemon/plugins/media-keys/active to false in GConf, using gconf-editor).
- enable the touchpad (as in comment 13)
- checking the keysym in the "xev" output when pressing the touchpad enable/disable button

Does the touchpad still get disabled when pressing the enable/disable button, even though nothing changes in gconf, and nothing handles that button?
Comment 17 Cornelia Pfeffer 2010-10-30 12:40:00 EDT
I have the same problem. When I let the touchpad disabled rebooting the system, it still works when it restarts, but after the login it remains disabled. Pressing the key enable-disable, nothing changes in the function (it remains disabled), but I see the pop-up that shows me if I enabled or disabled exactly contrary to the light on the key. In configuration editor /desktop/gnome/peripherals/touchpad/touchpad_enabled is disabled, and only enabling it there the touchpad turns working normally.

When I reboot with the touchpad ENABLED, there is no problem after login, everything works right.

My laptop is an ACER Aspire 5536.

I don't think it could be a hardware-problem, to me it seems a software-problem.
Comment 18 Bradley 2010-10-30 23:00:28 EDT
(In reply to comment #16)
> Given this:
> Jun 12 23:12:40 plum kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
> synchronization, throwing 4 bytes away.
> Jun 12 23:12:41 plum kernel: psmouse.c: resync failed, issuing reconnect
> request
> 
> I'd go as far as to say that the problem is hardware related.

Hmm. When the touchpad is disconnected I'd *expect* the driver to get out of sync, surely?

> In GNOME, the only things setting the "touchpad enabled" GConf key are the
> mouse configuration in gnome-control-center, and gnome-settings-daemon's
> media-keys plugin, which handles the "touchpad" button.

But it works on gdm and breaks after login, even without pressing the key in between

> What could happen is that the hardware both spits out a keyboard event, and
> enables/disables the hardware.

since the touchpad light changes even in grub, that's quite likely.

> Which means that we'd be getting the state of it wrong.

that would explain why changing it when I'm logged in affects things, but not on bootup. Unless there are two bugs there. Does the plugin try to read the current status from the hardware on login?

> Could you try:
> - disable the touchpad key press handling by disabling the "media-keys" plugin
> (set /apps/gnome_settings_daemon/plugins/media-keys/active to false in GConf,
> using gconf-editor).
> - enable the touchpad (as in comment 13)
> - checking the keysym in the "xev" output when pressing the touchpad
> enable/disable button

No xev output

> Does the touchpad still get disabled when pressing the enable/disable button,
> even though nothing changes in gconf, and nothing handles that button?

Yes, but then re-enabling it works after disabling the plugin (it does take a couple of seconds to respond to touchpad movements, presumably due to the resyncing). As expected, other media keys (mute, etc) then don't work
Comment 19 Bastien Nocera 2010-11-01 15:18:07 EDT
Do you all use HP laptops, or others?

For people that use HP laptops, bug 623239 might be interesting to check out. The keys are broken on those in such a way that it would be impossible to get the touchpad back.

Another problem is that the gnome-settings-daemon configuration in gdm is different from the user's so even if the touchpad was disabled in gdm, it could be enabled in the session, and vice-versa. We should probably make that a system setting, rather than simply a session one.

There's also the problem that the button is wrongly mapped. See https://bugs.freedesktop.org/show_bug.cgi?id=31300 for more gory details.
Comment 20 Bradley 2010-11-02 07:09:31 EDT
I use an HP laptop. But it works under windows, and it used to work before the upgrade I mentioned, so..... also, the keyboard keeps working, so bug 623239 doesn't look the same.

> There's also the problem that the button is wrongly mapped. See
> https://bugs.freedesktop.org/show_bug.cgi?id=31300 for more gory details.

But see comment 1 - when I force enable the input device, X disables it again. What is causing it to do that?
Comment 21 NSLW 2010-11-02 13:16:30 EDT
(In reply to comment #19)
> Do you all use HP laptops, or others?

I use Acer laptop. I noticed two cases:

1. case:
a) touchpad active
b) turn off computer
c) start computer
d) touchpad is active
e) log in
f) touchpad is active

2. case:
a) touchpad is inactive
b) turn off computer
c) start computer
d) touchpad is active
e) log in
f) touchpad is inactive and I cannot activate it

I use fn+F7 to switch touchpad state
Comment 22 Bastien Nocera 2010-11-02 14:23:16 EDT
(In reply to comment #21)
> (In reply to comment #19)
> > Do you all use HP laptops, or others?
> 
> I use Acer laptop. I noticed two cases:
> 
> 1. case:
> a) touchpad active
> b) turn off computer
> c) start computer
> d) touchpad is active
> e) log in
> f) touchpad is active
> 
> 2. case:
> a) touchpad is inactive
> b) turn off computer
> c) start computer
> d) touchpad is active
> e) log in
> f) touchpad is inactive

That's because the state of the touchpad is session specific, when it shouldn't be. There's no mouse plugin in the gnome-settings-daemon in gdm[1], so even then, the state wouldn't be respected.

I filed https://bugzilla.gnome.org/show_bug.cgi?id=633838 about that.

[1]: http://git.gnome.org/browse/gdm/tree/gui/simple-greeter/gdm-simple-greeter.schemas.in

> and I cannot activate it

That's another problem. People thought that they could use different keys for toggling the touchpad (some use F21, F22, or F23, try "grep -ri touchpad extras/keymap" the udev source tree).

This needs to be fixed, as mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=31300

> I use fn+F7 to switch touchpad state

Which has likely 2 separate keycodes depending on whether you enable or disable the device.

(In reply to comment #20)
> I use an HP laptop. But it works under windows, and it used to work before the
> upgrade I mentioned, so..... also, the keyboard keeps working, so bug 623239
> doesn't look the same.

That's because we added support for disabling the touchpad in gnome-settings-daemon. There was no support before, so the key didn't do anything in software. Just disable the keybinding it in the keybindings preferences, and it will still work.

> > There's also the problem that the button is wrongly mapped. See
> > https://bugs.freedesktop.org/show_bug.cgi?id=31300 for more gory details.
> 
> But see comment 1 - when I force enable the input device, X disables it again.
> What is causing it to do that?

1) The touchpad only works in hardware
2) It still sends XF86TouchpadToggle when *enabling* the touchpad (and not when disabling), so gnome-settings-daemon acts upon it.

Nobody really thought this through when it was implemented in gnome-settings-daemon, but gnome-settings-daemon isn't doing anything wrong. Just all the layers underneath are broken.

I'll carry on working on this and will try to unbreak the situation.

In the meanwhile, if you have an HP laptop, go to keybindings, and disable the touchpad shortcut.

If you have another laptop, you'll need to wait for me to fix the bugs in Xorg's headers, Xorg's keymaps, and udev's keymaps...
Comment 23 Fedora Update System 2010-11-25 12:57:33 EST
xkeyboard-config-1.9-7.fc14,xorg-x11-proto-devel-7.4-39.fc14,udev-161-8.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/xkeyboard-config-1.9-7.fc14,xorg-x11-proto-devel-7.4-39.fc14,udev-161-8.fc14
Comment 24 Fedora Update System 2010-11-25 20:11:17 EST
xkeyboard-config-1.9-7.fc14, xorg-x11-proto-devel-7.4-39.fc14, udev-161-8.fc14 has been pushed to the Fedora 14 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 xkeyboard-config xorg-x11-proto-devel udev'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xkeyboard-config-1.9-7.fc14,xorg-x11-proto-devel-7.4-39.fc14,udev-161-8.fc14
Comment 25 Bradley 2010-11-26 21:26:44 EST
Those packages fix it for me.
Comment 26 Fedora Update System 2010-11-27 18:38:23 EST
xkeyboard-config-1.9-7.fc14, xorg-x11-proto-devel-7.4-39.fc14, udev-161-8.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

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