FS#23899 - [xorg] Synaptics: Trackpad inoperable; Xorg registers HDA as synaptics input device.

Attached to Project: Arch Linux
Opened by secretrobotron (secretrobotron) - Saturday, 23 April 2011, 12:53 GMT
Last edited by Allan McRae (Allan) - Friday, 16 November 2012, 11:40 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

For the past couple of days, my trackpad hasn't been working, and I found this in my xorg log:

[ 155.648] (II) Using input driver 'synaptics' for 'HDA Digital PCBeep'
[ 155.648] (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so
[ 155.648] (**) HDA Digital PCBeep: always reports core events
[ 155.648] (**) Option "Device" "/dev/input/event8"
[ 155.776] (--) HDA Digital PCBeep: invalid x-axis range. defaulting to 1615 - 5685
[ 155.776] (--) HDA Digital PCBeep: invalid y-axis range. defaulting to 1729 - 4171
[ 155.776] (--) HDA Digital PCBeep: invalid pressure range. defaulting to 0 - 256
[ 155.776] (--) HDA Digital PCBeep: invalid finger width range. defaulting to 0 - 16
[ 155.776] (**) Option "TapButton1" "1"
[ 155.776] (**) Option "TapButton2" "2"
[ 155.776] (**) Option "TapButton3" "3"
[ 155.883] (--) HDA Digital PCBeep: no supported touchpad found
[ 155.883] (EE) HDA Digital PCBeep Unable to query/initialize Synaptics hardware.
[ 155.950] (EE) PreInit returned 11 for "HDA Digital PCBeep"
[ 155.950] (II) UnloadModule: "synaptics"
[ 155.950] (II) Unloading synaptics

It looks like an attempt is being made to register HDA PCBeep as a synaptics input device, which doesn't seem quite right, and eventually, synaptics is just forgotten altogether.

Once X was up, rmmod psmouse && modprobe psmouse fixed the problem. The log still looked pretty ugly, with several attempts to register the trackpad, but removing evdev from the equation altogether (commenting out the trackpad section in 10-evdev.conf) made that disappear.

A more permanent workaround seems to be putting this in some xorg conf file (I just put it at the top of evdev):

Section "InputClass"
Identifier "HDA Digital PCBeep"
MatchProduct "HDA Digital PCBeep"
Option "Ignore" "On"
EndSection

I'm not totally sure what HDA Digital PCBeep is. I still get that all-too-familiar beep when I make wrong console movements.

According to pacman, xorg is 1.10.1-1.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 16 November 2012, 11:40 GMT
Reason for closing:  No response
Additional comments about closing:  old and probably fixed
Comment by secretrobotron (secretrobotron) - Saturday, 23 April 2011, 12:54 GMT
In addendum, the TrackPoint device (little red nub on the keyboard) on my machine still worked either way.
Comment by secretrobotron (secretrobotron) - Saturday, 23 April 2011, 14:35 GMT
In addendum to my addendum, "Integrated Camera" tried to do the same thing.
Comment by Jan de Groot (JGC) - Sunday, 24 April 2011, 14:55 GMT
Do you use the default synaptics configuration file, or did you change it in any way?
Comment by secretrobotron (secretrobotron) - Monday, 25 April 2011, 04:08 GMT
The most synaptics configuration I do is 3 calls to synclient in .xinitrc so I can disable TapButton. As far as I'm aware, I haven't touched any synaptics config files. They should all be defaults.
Comment by tiketfree (tiketfree) - Wednesday, 27 April 2011, 03:38 GMT
I also have the same bug. Happens when updating to latest xorg (1.10.1-1) on x86_64. Using the said workaround, fix the problem.
Comment by Jan de Groot (JGC) - Wednesday, 10 August 2011, 12:59 GMT
For those who are affected, please find the input device from Xorg.0.log and use udevadm info --query property --name=[devname] to find out what properties are registered by Udev. I can't reproduce this on any of my systems, so it looks like either something is horribly wrong on your systems, or some manufacturer decided to assign touchpad capabilities to an input device that should be ignored.
Comment by Jan de Groot (JGC) - Monday, 10 October 2011, 10:47 GMT
  • Field changed: Status (Assigned → Waiting on Response)
As I said in the last bugreport, I can't reproduce this, so I need the data as requested in the last comment to make a proper workaround in the package. If this data isn't provided within reasonable time, I'll close this bug as worksforme.
Comment by secretrobotron (secretrobotron) - Tuesday, 11 October 2011, 11:55 GMT
My udevadm output looks like this for HDA Digital PCBeep:

UDEV_LOG=3
DEVPATH=/devices/pci0000:00/0000:00:1b.0/input/input8/event8
MAJOR=13
MINOR=72
DEVNAME=/dev/input/event8
SUBSYSTEM=input
ID_INPUT=1
ID_PATH=pci-0000:00:1b.0
ID_PATH_TAG=pci-0000_00_1b_0

And like this for Integrated Camera:

UDEV_LOG=3
DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input9/event9
MAJOR=13
MINOR=73
DEVNAME=/dev/input/event9
SUBSYSTEM=input
ID_INPUT=1
ID_INPUT_KEY=1
ID_VENDOR=Chicony_Electronics_Co.__Ltd.
ID_VENDOR_ENC=Chicony\x20Electronics\x20Co.\x2c\x20Ltd.
ID_VENDOR_ID=17ef
ID_MODEL=Integrated_Camera
ID_MODEL_ENC=Integrated\x20Camera
ID_MODEL_ID=480f
ID_REVISION=2345
ID_SERIAL=Chicony_Electronics_Co.__Ltd._Integrated_Camera
ID_TYPE=video
ID_BUS=usb
ID_USB_INTERFACES=:0e0100:0e0200:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=uvcvideo
ID_PATH=pci-0000:00:1a.0-usb-0:1.6:1.0
ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_6_1_0
DEVLINKS=/dev/input/by-id/usb-Chicony_Electronics_Co.__Ltd._Integrated_Camera-event-if00 /dev/input/by-path/pci-0000:00:1a.0-usb-0:1.6:1.0-event

Note that *both* of these still work, and my /etc/X11/xorg.conf.d/10-evdev.conf is set to ignore all of the offending devices.
Comment by Greg (dolby) - Tuesday, 16 October 2012, 06:12 GMT
Still a problem with latest version?
Comment by secretrobotron (secretrobotron) - Tuesday, 16 October 2012, 12:42 GMT
I'll have to check when I get back home. This issue is a year old, so it's probably been dealt with.

Loading...