Bug 600650

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.

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.

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.

Created attachment 423500 [details]
xorg.conf

Created attachment 423501 [details]
dmesg after VT switch to VT2 but before switch back

Created attachment 423502 [details]
Later dmesg

Created attachment 423503 [details]
Xorg log

Created attachment 423505 [details]
messages from bootup

I've got the same problem.

What's the status of this bug? Touchpad still stops working after login if it isn't used at log in screen.

I don't encounter this bug no more. How it's with the original reporter?

I still see this, but only if I boot with the touchpad h/w switch off.

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

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.

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.

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?

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.

(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

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.

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?

(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

(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...

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

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

Those packages fix it for me.

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.