regression: SynPS/2 touchpad detected as DLL060A:00 pointer

Bug #1265885 reported by Wren Turkal on 2014-01-03
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
linux (Ubuntu)
AceLan Kao

Bug Description

This regression occurs somewhere between 3.11.0-14-generic (latest on saucy) and 3.13.0-031300rc6-generic (a test kernel). On the earlier kernel, I actually get settings for setting up my touchpad in the unity interface. With the updated kernel, those options disappear. I only get one set of options both my mouse and my touchpad instead of each one independently. It means that I can't set the pointer speed differently or turn on natural scrolling for my touchpad.

WORKAROUND: Execute at a terminal and then reboot your system:
echo "blacklist i2c_hid" | sudo tee -a /etc/modprobe.d/blacklist.conf

Release Notes Text
Bug:1265885 On some Dell XPS13 systems the Synaptics touchpad is incorrectly recognised as a mouse. See the bug for possible workarounds.

This regression is present in kernel version 3.12.6-031206-generic.

Changed in linux (Ubuntu):
status: New → Invalid

I am just warning you that this problem may existing in what will become trusty. Is this not a valid bug to file in that case?

Joseph Salisbury (jsalisbury) wrote :

Thanks for the heads up on this, Warren.

Can you see if this bug exists in the latest Trusty kernel, which can be downloaded from:



Changed in linux (Ubuntu):
status: Invalid → Incomplete
importance: Undecided → Medium
tags: added: trusty
tags: added: kernel-da-key

Okay. I loaded the trusty linux-image+extras (3.12.0-8-generic) into saucy. There are still no input settings for my touchpad in the system settings.

Joseph Salisbury (jsalisbury) wrote :

I'd like to perform a bisect to figure out what commit caused this regression. We need to identify the earliest kernel where the issue started happening as well as the latest kernel that did not have this issue.

Can you test the following kernel:

v3.12 final:

If the bug does not exit there, then it was introduced by a stable update. If it does, we can test some of the 3.12 release candidates.



tags: added: performing-bisect
Changed in linux (Ubuntu):
status: Incomplete → In Progress
assignee: nobody → Joseph Salisbury (jsalisbury)

I am sorry. I have been extremely busy these past couple weeks. I'll try to make some progress soon.

Oh, and FWIW, I found this in dmesg:

wt@braindead:~$ dmesg | grep syn
[202484.540150] psmouse serio1: synaptics: Unable to query device.
[204320.591775] psmouse serio1: synaptics: Unable to query device.
[206356.441278] psmouse serio1: synaptics: Unable to query device.
[214607.673218] psmouse serio1: synaptics: Unable to query device.
[227250.907790] psmouse serio1: synaptics: Unable to query device.
[227293.852841] psmouse serio1: synaptics: Unable to query device.
[229105.632730] psmouse serio1: synaptics: Unable to query device.
[236480.580585] psmouse serio1: synaptics: Unable to query device.
[238292.829184] psmouse serio1: synaptics: Unable to query device.
[240104.553023] psmouse serio1: synaptics: Unable to query device.

I just tried the kernel you pointed me to (version "3.12.0-031200-generic #201311071835") does not show the touchpad controls. And just for the record, I don't see any of the messages I posted above shortly after boot. Here's proof:

wt@braindead:~$ dmesg | grep syn

I just tried another of the generic kernel. Here's some info:

wt@braindead:~/Documents$ cat linux-3.9.0-030900.has_touchpad_controls.txt
uname -a
Linux braindead 3.9.0-030900-generic #201304291257 SMP Mon Apr 29 16:58:15 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

dmesg | grep syn
[ 10.221126] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd40123/0x840300/0x126800, board id: 2734, fw id: 1522295

xinput list listing for touchpad:
 SynPS/2 Synaptics TouchPad

FTR, the xinput listing on non-working kernels is the following: DLL060A:00 06CB:2734.

I'm also attaching my dmesg from the working kernel version 3.9.0-030900.

Bah, I guess that was expected since the 3.11 series of kernels worked.

This bug is appears to be a duplicate of bug 1263319. However, I have not reinstalled. I would really like to help make sure this issue is handled properly so that other don't upgrade into this state like I did.

Joseph Salisbury (jsalisbury) wrote :

The v3.13.1 kernel is now available. Can you give that kernel a test before we start a bisect? It can be downloaded from:

I can confirm that that kernel version v3.13.1 from the above line still has the bug. I can also confirm that blacklisting i2c_hid makes the touchpad work in that kernel version.

With code based on linus' tree in a git clone that I git pulled this morning, I get the same results. I have attached the dmesg.

There are all kinds of ACPI errors in the dmesg.

tags: added: needs-kernel-logs
Joseph Salisbury (jsalisbury) wrote :

Can you test the following kernels and report back? We are looking for the earliest kernel version that exhibits this bug:


If v3.12-rc4 does not exhibit the bug then test v3.12-rc6:

If v3.12-rc4 does exhibit the bug then test v3.12-rc2:

You don't have to test every kernel, just up until the kernel that first has this bug.

Thanks in advance!

Kent Baxley (kentb) wrote :

I think I know what might be happening here...

The firmware on these Synaptics touchpads supports i2c mode as well as psmouse mode. Older kernels prior to 3.11 didn't have very good i2c support and the firmware on the touchpad would fall back to psmouse mode. psmouse mode worked nicely on machines pre-loaded with 12.04 and probably worked OK up until 13.04. Once the Saucy kernels were introduced, the 3.11 kernels had better i2c support and thus the touchpad would load up in i2c mode.

Synaptics was supposed to be working on some hid-multitouch i2c drivers and I thought they would have been upstreamed by now. Without them, the touchpad will operate in *very* basic i2c mode. This also explains the difference between what you see in xinput with the older kernels (PS/2) versus newer ones (DLL060A:00 06CB:2734). So, yes, blacklisting i2c_hid is one way to work around the problem.

I'll find out what the deal is with Synaptics...

Kent Baxley (kentb) wrote :

Here's an update from Synaptics as to what's going on. Work is progressing upstream, but, it's rather slow at the moment:

We are making progress upstreaming the driver, but it is going slowly.
Dmitry Torokhov has created a branch for our driver in his git tree
and we are submitting incremental patches to get the core of our
driver in place.

git clone git://
-b synaptics-rmi4

Because our driver is intended to support all of our RMI4 devices
there are several pieces to the driver which make it a bit more
complicated then the standard input driver. So far we have submitted
the rmi4 core and drivers for function 11 (pointing) and function 30
(the click button). Function 30 hasn't been accepted yet.

We also submitted transport driver for I2C devices which do not have
HID support. What is submitted right now works for touchscreens, but
we still need to submit some additional patches to get touchpad
support working correctly. Once those patches are submitted we will
the submit the HID transport driver. I'm not quite sure when
everything will be finally accepted by Dmitry, but it depends on how
quickly things get reviewed and accepted. If people at Canonical can
review our patches, that would help too.

Joseph Salisbury (jsalisbury) wrote :

Thanks for the update, Kent. The best way to get the patches reviewed is for the patch author to send them to the kernel team mailing list:

<email address hidden>

There is some info on a wiki here as well:

Changed in linux (Ubuntu):
status: In Progress → Triaged
tags: removed: performing-bisect
Changed in linux (Ubuntu):
assignee: Joseph Salisbury (jsalisbury) → nobody
tags: added: kernel-key
summary: - regression with respect touchpad
+ regression: SynPS/2 touchpad detected as non-working DLL060A:00 pointer
summary: - regression: SynPS/2 touchpad detected as non-working DLL060A:00 pointer
+ regression: SynPS/2 touchpad detected as DLL060A:00 pointer
Kamal Mostafa (kamalmostafa) wrote :

Kent Baxley's analysis in comment #18 is correct. Some (but not all) models of Dell XPS13 contain the Synaptics touchpad affected by this problem.

Until a newer Synaptics i2c driver becomes available, the recommended solution for Ubuntu 14.04 (Trusty) is to blacklist the i2c_hid driver, which will return the Synaptics touchpad to full functionality.

To test whether this workaround will affect you, run the 'xinput' command. If the output contains a "DLL060A:00 ..." line (indicating that it has been detected by the i2c_hid driver), then you may need this workaround.

To apply the workaround, run the following command:

    $ echo "blacklist i2c_hid" | sudo tee -a /etc/modprobe.d/blacklist.conf

... and then reboot your system. The 'xinput' command should now show a "SynPS/2" line instead of the "DLL060A:00" line, and full touchpad functionality should be restored.

description: updated
tags: removed: kernel-key
Andy Whitcroft (apw) on 2014-04-17
description: updated
Andy Whitcroft (apw) on 2014-04-17
Changed in ubuntu-release-notes:
status: New → Fix Released

What is the fix that was released? Do I still need to blacklist in trusty?

AceLan Kao (acelankao) wrote :

Hi, I'm working on this issue on bug 1305522
Currently, you still have to blacklist i2c_hid to make the touchpad work until the new kernel is released.

Janus (reslayer-mail) wrote :

Toshiba C50D, touchpad stopped working after 13.10 —» 14.04 update completely.

After I tried «echo "blacklist i2c_hid" | sudo tee -a /etc/modprobe.d/blacklist.conf» and rebooting, it works perfectly, now even with two-finger scrolling which wasn't there before. Now works, no interruptions in service.

⎜ ↳ AlpsPS/2 ALPS GlidePoint id=12 [slave pointer (2)]
⎜ ↳ ALPS PS/2 Device id=13 [slave pointer (2)]

AceLan Kao (acelankao) wrote :

Hi, I need your help to verify the kernel and report if there is any regression you found.
This will help the SRU process.

BTW, this kernel is for Synaptics i2c touchpad only.

Do you want me to install that kernel? Or are you talking to Janus?

AceLan Kao (acelankao) wrote :

Warren, I need those who has synaptics i2c touchpad device to test the kernel.
We want to make sure the new kernel doesn't break anything and enables the touchpad well.
If you are available, please give it a try and report back, thank you.

Changed in linux (Ubuntu Trusty):
assignee: nobody → AceLan Kao (acelankao)

Great news! With the new kernel, everything seems to work like when I don't blacklist the driver. The devices are named differently though.

wt@braindead:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ DLL060A:00 06CB:2734 id=12 [slave pointer (2)]
⎜ ↳ Logitech Unifying Device. Wireless PID:101a id=15 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Power Button id=8 [slave keyboard (3)]
    ↳ HID 05f3:0007 id=9 [slave keyboard (3)]
    ↳ HID 05f3:0007 id=10 [slave keyboard (3)]
    ↳ Integrated_Webcam_HD id=11 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
    ↳ Dell WMI hotkeys id=14 [slave keyboard (3)]
wt@braindead:/etc/modprobe.d$ grep i2c *
blacklist.conf:blacklist i2c_i801
wt@braindead:/etc/modprobe.d$ lsmod | grep i2c
i2c_hid 18860 0
i2c_designware_platform 12960 0
i2c_designware_core 14768 1 i2c_designware_platform
hid 106148 6 i2c_hid,hid_generic,hid_rmi,usbhid,hid_logitech_dj
i2c_algo_bit 13413 1 i915

I just wanted to report in and say this is still working great. Thanks for the hard work on this. This will be great for anyone else using the same hardware.

AceLan Kao (acelankao) wrote :

Thanks for your help.
Please refer bug 1305522 for the latest status.
The patch has been accepted and applied on the next Ubuntu kernel.
You can expect a proposed kernel after 25-May and the formal released kernel after 07-Jun

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Changed in linux (Ubuntu Trusty):
status: Triaged → Fix Committed

I just realized that this kernel has broken my touchscreen. Is that expected?

AceLan Kao (acelankao) wrote :

Could you attach the following logs here?
1. dmesg > dmesg.log
2. lsmod > lomod.log
3. xinput > xinput.log
And, do you blacklist any modules?

Here are logs for the above linked kernel.

Uname for reference:
$ uname -a
Linux braindead 3.13.0-24-generic #46 SMP Tue Apr 22 09:25:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

AceLan Kao (acelankao) wrote :

Warren, thanks for the logs.
Could you attach the dmesg again after a reboot?
And attach the result of lsusb command, too, thanks.

Here's the logs just after reboot. I also added a "uname -a" to make sure that it's clear which kernel version is being used.

FWIW, when I rebooted the laptop, it locked up on the dell bios screen. I had to cold boot to get it to boot into ubuntu. This probably was more prevalent before the latest bios update that dell released. I wouldn't be too shocked if there were some kind of ACPI firmware issue. However, I am not sure if this is related to the touchpad issue at all.

AceLan Kao (acelankao) wrote :

Warren, I'm sure that the touchscreen(06cb:0af8) is supported by trusty kernel.
It should use the module hid-multitouch, but I can't see it in the log, lsmod.log
Could you load it by yourself to see if it works?
   sudo modprobe hid-multitouch

So I loaded the module, there are no messages generated in dmesg as a result.

Also, I ran this in another window while loading the module just to make sure:
# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1230.288508] add /module/hid_multitouch (module)
KERNEL[1230.288646] add /bus/hid/drivers/hid-multitouch (drivers)
UDEV [1230.289076] add /module/hid_multitouch (module)
UDEV [1230.289442] add /bus/hid/drivers/hid-multitouch (drivers)

Looks like the only udev events are related to the module and driver load. There's nothing about the input device itself.

Also, no new devices show in "xinput list".

AceLan Kao (acelankao) wrote :

Warren, I have some thoughts need your help.

1. Try to turn off the power management and do S3 to see if it works
       cd /sys/devices/pci0000:00
       find -name control | xargs -I '{}' sudo sh -c "echo on > '{}'"
       sudo pm-suspend

2. add the quirk explicitly
       sudo echo "options usbhid quirks=0x06cb:0x0af8:0x20000000" > /etc/modprobe.d/usbhid.conf
       sudo update-initramfs -u
       (To disable this, just remove the file /etc/modprobe.d/usbhid.conf and do "sudo update-initramfs -u" again)

3. enable xhci debug message
       add the below line to kernel command line
          dyndbg='module xhci_hcd +p'
       You can add it while booting to grub, press left shift key can enter grub interactive mode, and press e to edit it like this
          linux /boot/vmlinuz-3.13.0-24-generic root=UUID=13ea166e-7711-4a7e-86bb-83a5ce4a9b05 ro quiet splash crashkernel=384M-:128M $vt_handoff dyndbg='module xhci_hcd +p'
       Just add the dyndbg parameter, then press ctrl+x or F10 to boot up, then get the dmesg log and attach it.

AceLan Kao (acelankao) wrote :

Warren, no need to do the above test now.
And let's move to bug 1305522 to discuss the issue.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers