* About Dell Inspiron 3442 touchpad
@ 2014-10-29 1:00 Luiz Carlos Ramos
2014-10-29 1:40 ` Benjamin Tissoires
0 siblings, 1 reply; 10+ messages in thread
From: Luiz Carlos Ramos @ 2014-10-29 1:00 UTC (permalink / raw)
To: linux-input
Hello,
I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
Some details:
- I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
tests
- xinput ignores the touchpad; it shows only a USB mouse/keyboard
adapter and the laptop's keyboard:
root@pace:/sys/bus/hid/devices# xinput
Virtual core pointer id=2 [master pointer
(3)]
Virtual core XTEST pointer id=4 [slave
pointer (2)]
Generic USB K/B id=12 [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=9 [slave
keyboard (3)]
Sleep Button id=10 [slave
keyboard (3)]
Integrated_Webcam_HD id=13 [slave
keyboard (3)]
AT Translated Set 2 keyboard id=14 [slave
keyboard (3)]
Dell WMI hotkeys id=15 [slave
keyboard (3)]
Video Bus id=8 [slave
keyboard (3)]
Generic USB K/B id=11 [slave
keyboard (3)]
- it seems Ubuntu certified this machine (check
http://www.ubuntu.com/certification/hardware/201402-14674/components/),
but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
even loading psmouse.ko, or doing other tricks
- some articles lists some tips for making it work (like
http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
them carefully, made some tests, and they didn't work. One article says
I could blacklist i2c_hid or like in order to make the bring up the
touchpad in PS/2 mode, but I couldn't succeed doing so
- at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
almost obsolete. It seems to be just merged into the kernel
- from Windows 8.1, which runs in the same machine (dual boot), I
concluded the proper way of making it work is to use HID over I2C. It
seems that there are two components loaded; one I2CHID, and a Synaptics
HID. This makes me hint it may be a Synaptics device
- it seems there are two I2C busses in the machine. One is related to
the Intel video graphics subsystem (i801). The other seems to be linked
to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
(i2c_designware_platform) is the right one to be used in this case, but
it appears to be working:
root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
total 0
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
../../../devices/pci0000:00/INT33C2:00/i2c-0
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
../../../devices/pci0000:00/INT33C3:00/i2c-1
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
../../../devices/pci0000:00/0000:00:02.0/i2c-2
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
../../../devices/pci0000:00/0000:00:02.0/i2c-3
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
../../../devices/pci0000:00/0000:00:02.0/i2c-4
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
../../../devices/pci0000:00/0000:00:02.0/i2c-5
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
../../../devices/pci0000:00/0000:00:02.0/i2c-6
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
../../../devices/pci0000:00/0000:00:02.0/i2c-7
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
../../../devices/pci0000:00/0000:00:02.0/i2c-8
lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
i2c_hid 10682 0
hid 94632 3 i2c_hid,hid_generic,usbhid
i2c_dev 5739 0
i2c_designware_platform 3189 0
i2c_i801 13732 0
i2c_designware_core 6045 1 i2c_designware_platform
i2c_algo_bit 5351 1 i915
i2c_core 35216 11
drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
- in the HID /sys directory, there are three devices. Two are related to
a keyboard/mouse USB adapter. The third seems to be the linked to the
touchpad:
root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
total 0
lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
- when I load the kernel module i2c-hid.ko (with debug=1), I read this
in dmesg:
[146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
[146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
[146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
00
[146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
[146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
[146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
[146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
08
[146172.575436] i2c_hid i2c-DLL0652:00: resetting...
[146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
01
[146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
[146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
[146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
[146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
[146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
ff 09 01 a1 01 85 09 09 02 15 00 26
[146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
[146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
08
I am aware this information probably is not sufficient to draw any
conclusions, but I'd appreciate to hear from someone who knows i2c_hid
in detail what steps I should take next. For me the last command timed
out or got stuck, but I haven't checked the code to see if it's the
case. Anyway, if it was a timeout case, it should have something logged
after the time expired.
I have some programming skills, and so if it's the case of applying any
patches, or recompiling the kernel or any subsystem to make tests, I'm
up to.
Many thanks,
Luiz Ramos
lramos dot prof at yahoo dot com dot br
São Paulo - Brazil
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-10-29 1:00 About Dell Inspiron 3442 touchpad Luiz Carlos Ramos
@ 2014-10-29 1:40 ` Benjamin Tissoires
2014-10-30 10:06 ` Luiz Carlos Ramos
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2014-10-29 1:40 UTC (permalink / raw)
To: Luiz Carlos Ramos; +Cc: linux-input
Hi Luiz,
On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
<lramos.prof@yahoo.com.br> wrote:
> Hello,
>
> I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
>
> Some details:
>
> - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
> tests
>
> - xinput ignores the touchpad; it shows only a USB mouse/keyboard
> adapter and the laptop's keyboard:
>
> root@pace:/sys/bus/hid/devices# xinput
> Virtual core pointer id=2 [master pointer
> (3)]
> Virtual core XTEST pointer id=4 [slave
> pointer (2)]
> Generic USB K/B id=12 [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=9 [slave
> keyboard (3)]
> Sleep Button id=10 [slave
> keyboard (3)]
> Integrated_Webcam_HD id=13 [slave
> keyboard (3)]
> AT Translated Set 2 keyboard id=14 [slave
> keyboard (3)]
> Dell WMI hotkeys id=15 [slave
> keyboard (3)]
> Video Bus id=8 [slave
> keyboard (3)]
> Generic USB K/B id=11 [slave
> keyboard (3)]
>
> - it seems Ubuntu certified this machine (check
> http://www.ubuntu.com/certification/hardware/201402-14674/components/),
> but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
> even loading psmouse.ko, or doing other tricks
>
> - some articles lists some tips for making it work (like
> http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
> or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
> them carefully, made some tests, and they didn't work. One article says
> I could blacklist i2c_hid or like in order to make the bring up the
> touchpad in PS/2 mode, but I couldn't succeed doing so
>
> - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
> almost obsolete. It seems to be just merged into the kernel
>
> - from Windows 8.1, which runs in the same machine (dual boot), I
> concluded the proper way of making it work is to use HID over I2C. It
> seems that there are two components loaded; one I2CHID, and a Synaptics
> HID. This makes me hint it may be a Synaptics device
Well, if this is a Synaptics HID over I2C device, it should be handled
by hid-rmi in recent kernels (or hid-multitouch but I would say
hid-rmi in your case).
Is the hid-rmi module loaded? Can we get a dmesg output so we can see
if there is any problem?
>
> - it seems there are two I2C busses in the machine. One is related to
> the Intel video graphics subsystem (i801). The other seems to be linked
> to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
> (i2c_designware_platform) is the right one to be used in this case, but
> it appears to be working:
Yeah, i2c_designware_platform is pretty common for Haswell processors.
>
> root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
> total 0
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
> ../../../devices/pci0000:00/INT33C2:00/i2c-0
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
> ../../../devices/pci0000:00/INT33C3:00/i2c-1
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
> ../../../devices/pci0000:00/0000:00:02.0/i2c-2
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
> ../../../devices/pci0000:00/0000:00:02.0/i2c-3
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
> ../../../devices/pci0000:00/0000:00:02.0/i2c-4
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
> ../../../devices/pci0000:00/0000:00:02.0/i2c-5
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
> ../../../devices/pci0000:00/0000:00:02.0/i2c-6
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
> ../../../devices/pci0000:00/0000:00:02.0/i2c-7
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
> ../../../devices/pci0000:00/0000:00:02.0/i2c-8
> lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
> ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
This one is the touchpad.
>
> root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
> i2c_hid 10682 0
> hid 94632 3 i2c_hid,hid_generic,usbhid
> i2c_dev 5739 0
> i2c_designware_platform 3189 0
> i2c_i801 13732 0
> i2c_designware_core 6045 1 i2c_designware_platform
> i2c_algo_bit 5351 1 i915
> i2c_core 35216 11
> drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
>
> - in the HID /sys directory, there are three devices. Two are related to
> a keyboard/mouse USB adapter. The third seems to be the linked to the
> touchpad:
>
> root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
> total 0
> lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
> ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
> lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
> ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
> lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
> ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
This is the HID over I2C touchpad.
>
> - when I load the kernel module i2c-hid.ko (with debug=1), I read this
> in dmesg:
>
> [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> 00
> [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> 08
> [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
> [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> 01
> [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> ff 09 01 a1 01 85 09 09 02 15 00 26
> [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> 08
Everything is fine, this is the normal behavior while connecting a
i2c_hid device.
Normally, we should have then hid-rmi asking for more things and then
it will eventually set up the input device.
>
> I am aware this information probably is not sufficient to draw any
> conclusions, but I'd appreciate to hear from someone who knows i2c_hid
> in detail what steps I should take next. For me the last command timed
> out or got stuck, but I haven't checked the code to see if it's the
> case. Anyway, if it was a timeout case, it should have something logged
> after the time expired.
There is no answer from the device when a SET_POWER is emitted. So
this is not a timeout problem.
If hid-rmi is compiled and is not taking the device, we have a big
problem, but for now, the symptoms look like you do not have this
driver compiled and hid-generic does not bind the device because it
waits for hid-rmi to handle it.
>
> I have some programming skills, and so if it's the case of applying any
> patches, or recompiling the kernel or any subsystem to make tests, I'm
> up to.
Cool, thanks.
Cheers,
Benjamin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-10-29 1:40 ` Benjamin Tissoires
@ 2014-10-30 10:06 ` Luiz Carlos Ramos
2014-11-05 1:11 ` Luiz Carlos Ramos
0 siblings, 1 reply; 10+ messages in thread
From: Luiz Carlos Ramos @ 2014-10-30 10:06 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input
Hi Benjamin,
Thanks for the assistance and quick reply.
On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
> Hi Luiz,
>
> On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
> <lramos.prof@yahoo.com.br> wrote:
> > Hello,
> >
> > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
> >
> > Some details:
> >
> > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
> > tests
> >
> > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
> > adapter and the laptop's keyboard:
> >
> > root@pace:/sys/bus/hid/devices# xinput
> > Virtual core pointer id=2 [master pointer
> > (3)]
> > Virtual core XTEST pointer id=4 [slave
> > pointer (2)]
> > Generic USB K/B id=12 [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=9 [slave
> > keyboard (3)]
> > Sleep Button id=10 [slave
> > keyboard (3)]
> > Integrated_Webcam_HD id=13 [slave
> > keyboard (3)]
> > AT Translated Set 2 keyboard id=14 [slave
> > keyboard (3)]
> > Dell WMI hotkeys id=15 [slave
> > keyboard (3)]
> > Video Bus id=8 [slave
> > keyboard (3)]
> > Generic USB K/B id=11 [slave
> > keyboard (3)]
> >
> > - it seems Ubuntu certified this machine (check
> > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
> > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
> > even loading psmouse.ko, or doing other tricks
> >
> > - some articles lists some tips for making it work (like
> > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
> > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
> > them carefully, made some tests, and they didn't work. One article says
> > I could blacklist i2c_hid or like in order to make the bring up the
> > touchpad in PS/2 mode, but I couldn't succeed doing so
> >
> > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
> > almost obsolete. It seems to be just merged into the kernel
> >
> > - from Windows 8.1, which runs in the same machine (dual boot), I
> > concluded the proper way of making it work is to use HID over I2C. It
> > seems that there are two components loaded; one I2CHID, and a Synaptics
> > HID. This makes me hint it may be a Synaptics device
>
> Well, if this is a Synaptics HID over I2C device, it should be handled
> by hid-rmi in recent kernels (or hid-multitouch but I would say
> hid-rmi in your case).
> Is the hid-rmi module loaded? Can we get a dmesg output so we can see
> if there is any problem?
>
> >
> > - it seems there are two I2C busses in the machine. One is related to
> > the Intel video graphics subsystem (i801). The other seems to be linked
> > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
> > (i2c_designware_platform) is the right one to be used in this case, but
> > it appears to be working:
>
> Yeah, i2c_designware_platform is pretty common for Haswell processors.
>
> >
> > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
> > total 0
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
> > ../../../devices/pci0000:00/INT33C2:00/i2c-0
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
> > ../../../devices/pci0000:00/INT33C3:00/i2c-1
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
> > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
> > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
> > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
> > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
> > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
> > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
> > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
> > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
> > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
>
> This one is the touchpad.
>
> >
> > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
> > i2c_hid 10682 0
> > hid 94632 3 i2c_hid,hid_generic,usbhid
> > i2c_dev 5739 0
> > i2c_designware_platform 3189 0
> > i2c_i801 13732 0
> > i2c_designware_core 6045 1 i2c_designware_platform
> > i2c_algo_bit 5351 1 i915
> > i2c_core 35216 11
> > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
> >
> > - in the HID /sys directory, there are three devices. Two are related to
> > a keyboard/mouse USB adapter. The third seems to be the linked to the
> > touchpad:
> >
> > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
> > total 0
> > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
> > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
> > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
> > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
> > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
> > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
>
> This is the HID over I2C touchpad.
>
> >
> > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
> > in dmesg:
> >
> > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> > 00
> > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> > 08
> > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
> > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> > 01
> > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> > ff 09 01 a1 01 85 09 09 02 15 00 26
> > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> > 08
>
> Everything is fine, this is the normal behavior while connecting a
> i2c_hid device.
> Normally, we should have then hid-rmi asking for more things and then
> it will eventually set up the input device.
>
> >
> > I am aware this information probably is not sufficient to draw any
> > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
> > in detail what steps I should take next. For me the last command timed
> > out or got stuck, but I haven't checked the code to see if it's the
> > case. Anyway, if it was a timeout case, it should have something logged
> > after the time expired.
>
> There is no answer from the device when a SET_POWER is emitted. So
> this is not a timeout problem.
>
> If hid-rmi is compiled and is not taking the device, we have a big
> problem, but for now, the symptoms look like you do not have this
> driver compiled and hid-generic does not bind the device because it
> waits for hid-rmi to handle it.
>
Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
dmesg output (relevant lines):
[158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
[158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
[158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
00
[158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
[158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
[158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
[158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
08
[158885.786494] i2c_hid i2c-DLL0652:00: resetting...
[158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
01
[158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
[158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
[158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
[158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
[158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
ff 09 01 a1 01 85 09 09 02 15 00 26
[158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
[158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
08
I included lines like:
printk(KERN_ERR "hid_rmi_probe(): called\n");
printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
in the beginning and at the end of the routine rmi_probe(). These lines
didn't
appear in dmesg (those pictured above). I don't know if "probe" is to be
called
in this case, or not. Is there any other condition to make hid-rmi be
"instantiated",
I mean, other kmod to be loaded, or a special ioctl() coming to the hid
from userland,
or even echoing something to the "bind" file at /sys/...?
Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
/sys/bus/hid/drivers/hid-rmi/
total 0
--w------- 1 root root 4096 Out 30 08:03 bind
lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
../../../../module/hid_rmi
--w------- 1 root root 4096 Out 30 08:03 new_id
--w------- 1 root root 4096 Out 30 07:48 uevent
--w------- 1 root root 4096 Out 30 08:03 unbind
One thing I didn't still did is to reboot the machine. I found it was
not the case,
but this type of action use to work a lot in IT/IS, right? :-)
> >
> > I have some programming skills, and so if it's the case of applying any
> > patches, or recompiling the kernel or any subsystem to make tests, I'm
> > up to.
>
> Cool, thanks.
>
> Cheers,
> Benjamin
Many thanks,
Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-10-30 10:06 ` Luiz Carlos Ramos
@ 2014-11-05 1:11 ` Luiz Carlos Ramos
2014-11-05 2:49 ` Benjamin Tissoires
0 siblings, 1 reply; 10+ messages in thread
From: Luiz Carlos Ramos @ 2014-11-05 1:11 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input
Hi, Benjamin,
I think I just wrote the email below in a way it suggests everything had
gone well and the issue was resolved... but unfortunately it's not the
case. In my reply, I wrote some remarks in the text body in that email,
but I think they weren't noticed at all given the first paragraph.
Only to recall, the problem is with a Dell Inspiron 3442, that has a
touchpad which doesn't show up. It seems like it is a Synaptics I2C
device. Your last advice was to insmod hid-rmi, which would hopefully
make things go on after I2C basic device handshake. However, it didn't
happen.
I managed also to put some "printk" at the beginning and at the end of
the "probe" function of hid-rmi, and it seems both were not called. I
don't know if some kind of ioctl() should be issued, or if udevd should
be configured some special way, but my feeling is that I am missing
something really really important and obvious.
Thanks,
Luiz
On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
> Hi Benjamin,
>
> Thanks for the assistance and quick reply.
>
> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
> > Hi Luiz,
> >
> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
> > <lramos.prof@yahoo.com.br> wrote:
> > > Hello,
> > >
> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
> > >
> > > Some details:
> > >
> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
> > > tests
> > >
> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
> > > adapter and the laptop's keyboard:
> > >
> > > root@pace:/sys/bus/hid/devices# xinput
> > > Virtual core pointer id=2 [master pointer
> > > (3)]
> > > Virtual core XTEST pointer id=4 [slave
> > > pointer (2)]
> > > Generic USB K/B id=12 [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=9 [slave
> > > keyboard (3)]
> > > Sleep Button id=10 [slave
> > > keyboard (3)]
> > > Integrated_Webcam_HD id=13 [slave
> > > keyboard (3)]
> > > AT Translated Set 2 keyboard id=14 [slave
> > > keyboard (3)]
> > > Dell WMI hotkeys id=15 [slave
> > > keyboard (3)]
> > > Video Bus id=8 [slave
> > > keyboard (3)]
> > > Generic USB K/B id=11 [slave
> > > keyboard (3)]
> > >
> > > - it seems Ubuntu certified this machine (check
> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
> > > even loading psmouse.ko, or doing other tricks
> > >
> > > - some articles lists some tips for making it work (like
> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
> > > them carefully, made some tests, and they didn't work. One article says
> > > I could blacklist i2c_hid or like in order to make the bring up the
> > > touchpad in PS/2 mode, but I couldn't succeed doing so
> > >
> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
> > > almost obsolete. It seems to be just merged into the kernel
> > >
> > > - from Windows 8.1, which runs in the same machine (dual boot), I
> > > concluded the proper way of making it work is to use HID over I2C. It
> > > seems that there are two components loaded; one I2CHID, and a Synaptics
> > > HID. This makes me hint it may be a Synaptics device
> >
> > Well, if this is a Synaptics HID over I2C device, it should be handled
> > by hid-rmi in recent kernels (or hid-multitouch but I would say
> > hid-rmi in your case).
> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
> > if there is any problem?
> >
> > >
> > > - it seems there are two I2C busses in the machine. One is related to
> > > the Intel video graphics subsystem (i801). The other seems to be linked
> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
> > > (i2c_designware_platform) is the right one to be used in this case, but
> > > it appears to be working:
> >
> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
> >
> > >
> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
> > > total 0
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
> >
> > This one is the touchpad.
> >
> > >
> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
> > > i2c_hid 10682 0
> > > hid 94632 3 i2c_hid,hid_generic,usbhid
> > > i2c_dev 5739 0
> > > i2c_designware_platform 3189 0
> > > i2c_i801 13732 0
> > > i2c_designware_core 6045 1 i2c_designware_platform
> > > i2c_algo_bit 5351 1 i915
> > > i2c_core 35216 11
> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
> > >
> > > - in the HID /sys directory, there are three devices. Two are related to
> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
> > > touchpad:
> > >
> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
> > > total 0
> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
> >
> > This is the HID over I2C touchpad.
> >
> > >
> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
> > > in dmesg:
> > >
> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> > > 00
> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> > > 08
> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> > > 01
> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> > > ff 09 01 a1 01 85 09 09 02 15 00 26
> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> > > 08
> >
> > Everything is fine, this is the normal behavior while connecting a
> > i2c_hid device.
> > Normally, we should have then hid-rmi asking for more things and then
> > it will eventually set up the input device.
> >
> > >
> > > I am aware this information probably is not sufficient to draw any
> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
> > > in detail what steps I should take next. For me the last command timed
> > > out or got stuck, but I haven't checked the code to see if it's the
> > > case. Anyway, if it was a timeout case, it should have something logged
> > > after the time expired.
> >
> > There is no answer from the device when a SET_POWER is emitted. So
> > this is not a timeout problem.
> >
> > If hid-rmi is compiled and is not taking the device, we have a big
> > problem, but for now, the symptoms look like you do not have this
> > driver compiled and hid-generic does not bind the device because it
> > waits for hid-rmi to handle it.
> >
>
> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
> dmesg output (relevant lines):
>
> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> 00
> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> 08
> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> 01
> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> ff 09 01 a1 01 85 09 09 02 15 00 26
> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> 08
>
> I included lines like:
>
> printk(KERN_ERR "hid_rmi_probe(): called\n");
> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
>
> in the beginning and at the end of the routine rmi_probe(). These lines
> didn't
> appear in dmesg (those pictured above). I don't know if "probe" is to be
> called
> in this case, or not. Is there any other condition to make hid-rmi be
> "instantiated",
> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
> from userland,
> or even echoing something to the "bind" file at /sys/...?
>
> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
>
> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
> /sys/bus/hid/drivers/hid-rmi/
> total 0
> --w------- 1 root root 4096 Out 30 08:03 bind
> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
> ../../../../module/hid_rmi
> --w------- 1 root root 4096 Out 30 08:03 new_id
> --w------- 1 root root 4096 Out 30 07:48 uevent
> --w------- 1 root root 4096 Out 30 08:03 unbind
>
> One thing I didn't still did is to reboot the machine. I found it was
> not the case,
> but this type of action use to work a lot in IT/IS, right? :-)
>
> > >
> > > I have some programming skills, and so if it's the case of applying any
> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
> > > up to.
> >
> > Cool, thanks.
> >
> > Cheers,
> > Benjamin
>
> Many thanks,
>
> Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-11-05 1:11 ` Luiz Carlos Ramos
@ 2014-11-05 2:49 ` Benjamin Tissoires
2014-11-05 8:09 ` Luiz Carlos Ramos
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2014-11-05 2:49 UTC (permalink / raw)
To: Luiz Carlos Ramos, Andrew Duggan; +Cc: linux-input
Hi Luiz,
On Tue, Nov 4, 2014 at 8:11 PM, Luiz Carlos Ramos
<lramos.prof@yahoo.com.br> wrote:
> Hi, Benjamin,
>
> I think I just wrote the email below in a way it suggests everything had
> gone well and the issue was resolved... but unfortunately it's not the
> case. In my reply, I wrote some remarks in the text body in that email,
> but I think they weren't noticed at all given the first paragraph.
Apologies for that. I read it, thought about it, and forgot it.
>
> Only to recall, the problem is with a Dell Inspiron 3442, that has a
> touchpad which doesn't show up. It seems like it is a Synaptics I2C
> device. Your last advice was to insmod hid-rmi, which would hopefully
> make things go on after I2C basic device handshake. However, it didn't
> happen.
Yeah, so given the state of the 3.16 kernel and your tests, the group
associated to the device is simply not the RMI one.
Which is weird.
>
> I managed also to put some "printk" at the beginning and at the end of
> the "probe" function of hid-rmi, and it seems both were not called. I
> don't know if some kind of ioctl() should be issued, or if udevd should
> be configured some special way, but my feeling is that I am missing
> something really really important and obvious.
>
No, I think your device is in a black hole. If the device declares
nothing special, it should be handled by hid-rmi. But given that it is
not the case, it might declares itself as a multitouch capable, and
should be handled by hid-multitouch. But if hid-multitouch does not
drive it properly, that is weird.
Can you provide the modalias of the HID device: in "udevadm info
--export-db", look for the device attached to i2c_hid, and find its
son which has a modalias in the form of
MODALIAS=hid:b0018gXXXXv000006cbp00002985. I am interested in what is
after the "g".
Also, can you export the content of the report descriptor of your
device. You can find it in
/sys/kernel/debug/hid/0018\:06CB\:2985.*/rdesc assuming you have
debugfs mounted under /sys/kernel/debug
Cheers,
Benjamin
>
>
> On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
>> Hi Benjamin,
>>
>> Thanks for the assistance and quick reply.
>>
>> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
>> > Hi Luiz,
>> >
>> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
>> > <lramos.prof@yahoo.com.br> wrote:
>> > > Hello,
>> > >
>> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
>> > >
>> > > Some details:
>> > >
>> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
>> > > tests
>> > >
>> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
>> > > adapter and the laptop's keyboard:
>> > >
>> > > root@pace:/sys/bus/hid/devices# xinput
>> > > Virtual core pointer id=2 [master pointer
>> > > (3)]
>> > > Virtual core XTEST pointer id=4 [slave
>> > > pointer (2)]
>> > > Generic USB K/B id=12 [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=9 [slave
>> > > keyboard (3)]
>> > > Sleep Button id=10 [slave
>> > > keyboard (3)]
>> > > Integrated_Webcam_HD id=13 [slave
>> > > keyboard (3)]
>> > > AT Translated Set 2 keyboard id=14 [slave
>> > > keyboard (3)]
>> > > Dell WMI hotkeys id=15 [slave
>> > > keyboard (3)]
>> > > Video Bus id=8 [slave
>> > > keyboard (3)]
>> > > Generic USB K/B id=11 [slave
>> > > keyboard (3)]
>> > >
>> > > - it seems Ubuntu certified this machine (check
>> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
>> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
>> > > even loading psmouse.ko, or doing other tricks
>> > >
>> > > - some articles lists some tips for making it work (like
>> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
>> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
>> > > them carefully, made some tests, and they didn't work. One article says
>> > > I could blacklist i2c_hid or like in order to make the bring up the
>> > > touchpad in PS/2 mode, but I couldn't succeed doing so
>> > >
>> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
>> > > almost obsolete. It seems to be just merged into the kernel
>> > >
>> > > - from Windows 8.1, which runs in the same machine (dual boot), I
>> > > concluded the proper way of making it work is to use HID over I2C. It
>> > > seems that there are two components loaded; one I2CHID, and a Synaptics
>> > > HID. This makes me hint it may be a Synaptics device
>> >
>> > Well, if this is a Synaptics HID over I2C device, it should be handled
>> > by hid-rmi in recent kernels (or hid-multitouch but I would say
>> > hid-rmi in your case).
>> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
>> > if there is any problem?
>> >
>> > >
>> > > - it seems there are two I2C busses in the machine. One is related to
>> > > the Intel video graphics subsystem (i801). The other seems to be linked
>> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
>> > > (i2c_designware_platform) is the right one to be used in this case, but
>> > > it appears to be working:
>> >
>> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
>> >
>> > >
>> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
>> > > total 0
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
>> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
>> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
>> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
>> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
>> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
>> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
>> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
>> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
>> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
>> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
>> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
>> >
>> > This one is the touchpad.
>> >
>> > >
>> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
>> > > i2c_hid 10682 0
>> > > hid 94632 3 i2c_hid,hid_generic,usbhid
>> > > i2c_dev 5739 0
>> > > i2c_designware_platform 3189 0
>> > > i2c_i801 13732 0
>> > > i2c_designware_core 6045 1 i2c_designware_platform
>> > > i2c_algo_bit 5351 1 i915
>> > > i2c_core 35216 11
>> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
>> > >
>> > > - in the HID /sys directory, there are three devices. Two are related to
>> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
>> > > touchpad:
>> > >
>> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
>> > > total 0
>> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
>> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
>> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
>> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
>> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
>> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
>> >
>> > This is the HID over I2C touchpad.
>> >
>> > >
>> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
>> > > in dmesg:
>> > >
>> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
>> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
>> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
>> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
>> > > 00
>> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
>> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
>> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> > > 08
>> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
>> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> > > 01
>> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
>> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
>> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
>> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
>> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
>> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
>> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
>> > > ff 09 01 a1 01 85 09 09 02 15 00 26
>> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
>> > > 08
>> >
>> > Everything is fine, this is the normal behavior while connecting a
>> > i2c_hid device.
>> > Normally, we should have then hid-rmi asking for more things and then
>> > it will eventually set up the input device.
>> >
>> > >
>> > > I am aware this information probably is not sufficient to draw any
>> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
>> > > in detail what steps I should take next. For me the last command timed
>> > > out or got stuck, but I haven't checked the code to see if it's the
>> > > case. Anyway, if it was a timeout case, it should have something logged
>> > > after the time expired.
>> >
>> > There is no answer from the device when a SET_POWER is emitted. So
>> > this is not a timeout problem.
>> >
>> > If hid-rmi is compiled and is not taking the device, we have a big
>> > problem, but for now, the symptoms look like you do not have this
>> > driver compiled and hid-generic does not bind the device because it
>> > waits for hid-rmi to handle it.
>> >
>>
>> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
>> dmesg output (relevant lines):
>>
>> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
>> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
>> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
>> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
>> 00
>> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
>> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
>> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> 08
>> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
>> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> 01
>> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
>> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
>> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
>> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
>> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
>> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
>> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
>> ff 09 01 a1 01 85 09 09 02 15 00 26
>> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
>> 08
>>
>> I included lines like:
>>
>> printk(KERN_ERR "hid_rmi_probe(): called\n");
>> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
>>
>> in the beginning and at the end of the routine rmi_probe(). These lines
>> didn't
>> appear in dmesg (those pictured above). I don't know if "probe" is to be
>> called
>> in this case, or not. Is there any other condition to make hid-rmi be
>> "instantiated",
>> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
>> from userland,
>> or even echoing something to the "bind" file at /sys/...?
>>
>> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
>>
>> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
>> /sys/bus/hid/drivers/hid-rmi/
>> total 0
>> --w------- 1 root root 4096 Out 30 08:03 bind
>> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
>> ../../../../module/hid_rmi
>> --w------- 1 root root 4096 Out 30 08:03 new_id
>> --w------- 1 root root 4096 Out 30 07:48 uevent
>> --w------- 1 root root 4096 Out 30 08:03 unbind
>>
>> One thing I didn't still did is to reboot the machine. I found it was
>> not the case,
>> but this type of action use to work a lot in IT/IS, right? :-)
>>
>> > >
>> > > I have some programming skills, and so if it's the case of applying any
>> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
>> > > up to.
>> >
>> > Cool, thanks.
>> >
>> > Cheers,
>> > Benjamin
>>
>> Many thanks,
>>
>> Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-11-05 2:49 ` Benjamin Tissoires
@ 2014-11-05 8:09 ` Luiz Carlos Ramos
2014-11-05 15:35 ` Benjamin Tissoires
0 siblings, 1 reply; 10+ messages in thread
From: Luiz Carlos Ramos @ 2014-11-05 8:09 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input, andrew.duggan
Hi, Benjamin,
Thanks again!
Here it is an excerpt from $(udevadm info --export-db), I think the
relevant one:
P:
/devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
E:
DEVPATH=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
E: HID_ID=0018:000006CB:00002985
E: HID_NAME=DLL0652:00 06CB:2985
E: MODALIAS=hid:b0018g0000v000006CBp00002985
E: SUBSYSTEM=hid
E: UDEV_LOG=3
Also, this is the same information, from
/sys/bus/hid/devices/0018:06CB:2985.0005/modalias:
root@giustizia:/sys/bus/hid/devices/0018:06CB:2985.0005# cat modalias
hid:b0018g0000v000006CBp00002985
And, finally, the device descriptor:
root@giustizia:/sys/kernel/debug/hid/0018:06CB:2985.0005# cat rdesc
05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01
95 02 81 02 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06
c0 c0 06 00 ff 09 01 a1 01 85 09 09 02 15 00 26 ff 00 75 08 95 14 91 02
85 0a 09 03 15 00 26 ff 00 75 08 95 14 91 02 85 0b 09 04 15 00 26 ff 00
75 08 95 1d 81 02 85 0c 09 05 15 00 26 ff 00 75 08 95 1d 81 02 85 0f 09
06 15 00 26 ff 00 75 08 95 01 b1 02 c0
Yesterday, after sending my reply, I figured out that vendor 06CB means
Synaptics; am I right?
Also, again, if you'd like to me to code/patch/test anything, fell free
to ask me.
Many thanks again,
Luiz
On Wed, Nov 5, 2014, at 00:49, Benjamin Tissoires wrote:
> Hi Luiz,
>
> On Tue, Nov 4, 2014 at 8:11 PM, Luiz Carlos Ramos
> <lramos.prof@yahoo.com.br> wrote:
> > Hi, Benjamin,
> >
> > I think I just wrote the email below in a way it suggests everything had
> > gone well and the issue was resolved... but unfortunately it's not the
> > case. In my reply, I wrote some remarks in the text body in that email,
> > but I think they weren't noticed at all given the first paragraph.
>
> Apologies for that. I read it, thought about it, and forgot it.
>
> >
> > Only to recall, the problem is with a Dell Inspiron 3442, that has a
> > touchpad which doesn't show up. It seems like it is a Synaptics I2C
> > device. Your last advice was to insmod hid-rmi, which would hopefully
> > make things go on after I2C basic device handshake. However, it didn't
> > happen.
>
> Yeah, so given the state of the 3.16 kernel and your tests, the group
> associated to the device is simply not the RMI one.
> Which is weird.
>
> >
> > I managed also to put some "printk" at the beginning and at the end of
> > the "probe" function of hid-rmi, and it seems both were not called. I
> > don't know if some kind of ioctl() should be issued, or if udevd should
> > be configured some special way, but my feeling is that I am missing
> > something really really important and obvious.
> >
>
> No, I think your device is in a black hole. If the device declares
> nothing special, it should be handled by hid-rmi. But given that it is
> not the case, it might declares itself as a multitouch capable, and
> should be handled by hid-multitouch. But if hid-multitouch does not
> drive it properly, that is weird.
>
> Can you provide the modalias of the HID device: in "udevadm info
> --export-db", look for the device attached to i2c_hid, and find its
> son which has a modalias in the form of
> MODALIAS=hid:b0018gXXXXv000006cbp00002985. I am interested in what is
> after the "g".
>
> Also, can you export the content of the report descriptor of your
> device. You can find it in
> /sys/kernel/debug/hid/0018\:06CB\:2985.*/rdesc assuming you have
> debugfs mounted under /sys/kernel/debug
>
> Cheers,
> Benjamin
>
> >
> >
> > On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
> >> Hi Benjamin,
> >>
> >> Thanks for the assistance and quick reply.
> >>
> >> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
> >> > Hi Luiz,
> >> >
> >> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
> >> > <lramos.prof@yahoo.com.br> wrote:
> >> > > Hello,
> >> > >
> >> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
> >> > >
> >> > > Some details:
> >> > >
> >> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
> >> > > tests
> >> > >
> >> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
> >> > > adapter and the laptop's keyboard:
> >> > >
> >> > > root@pace:/sys/bus/hid/devices# xinput
> >> > > Virtual core pointer id=2 [master pointer
> >> > > (3)]
> >> > > Virtual core XTEST pointer id=4 [slave
> >> > > pointer (2)]
> >> > > Generic USB K/B id=12 [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=9 [slave
> >> > > keyboard (3)]
> >> > > Sleep Button id=10 [slave
> >> > > keyboard (3)]
> >> > > Integrated_Webcam_HD id=13 [slave
> >> > > keyboard (3)]
> >> > > AT Translated Set 2 keyboard id=14 [slave
> >> > > keyboard (3)]
> >> > > Dell WMI hotkeys id=15 [slave
> >> > > keyboard (3)]
> >> > > Video Bus id=8 [slave
> >> > > keyboard (3)]
> >> > > Generic USB K/B id=11 [slave
> >> > > keyboard (3)]
> >> > >
> >> > > - it seems Ubuntu certified this machine (check
> >> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
> >> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
> >> > > even loading psmouse.ko, or doing other tricks
> >> > >
> >> > > - some articles lists some tips for making it work (like
> >> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
> >> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
> >> > > them carefully, made some tests, and they didn't work. One article says
> >> > > I could blacklist i2c_hid or like in order to make the bring up the
> >> > > touchpad in PS/2 mode, but I couldn't succeed doing so
> >> > >
> >> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
> >> > > almost obsolete. It seems to be just merged into the kernel
> >> > >
> >> > > - from Windows 8.1, which runs in the same machine (dual boot), I
> >> > > concluded the proper way of making it work is to use HID over I2C. It
> >> > > seems that there are two components loaded; one I2CHID, and a Synaptics
> >> > > HID. This makes me hint it may be a Synaptics device
> >> >
> >> > Well, if this is a Synaptics HID over I2C device, it should be handled
> >> > by hid-rmi in recent kernels (or hid-multitouch but I would say
> >> > hid-rmi in your case).
> >> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
> >> > if there is any problem?
> >> >
> >> > >
> >> > > - it seems there are two I2C busses in the machine. One is related to
> >> > > the Intel video graphics subsystem (i801). The other seems to be linked
> >> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
> >> > > (i2c_designware_platform) is the right one to be used in this case, but
> >> > > it appears to be working:
> >> >
> >> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
> >> >
> >> > >
> >> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
> >> > > total 0
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
> >> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
> >> >
> >> > This one is the touchpad.
> >> >
> >> > >
> >> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
> >> > > i2c_hid 10682 0
> >> > > hid 94632 3 i2c_hid,hid_generic,usbhid
> >> > > i2c_dev 5739 0
> >> > > i2c_designware_platform 3189 0
> >> > > i2c_i801 13732 0
> >> > > i2c_designware_core 6045 1 i2c_designware_platform
> >> > > i2c_algo_bit 5351 1 i915
> >> > > i2c_core 35216 11
> >> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
> >> > >
> >> > > - in the HID /sys directory, there are three devices. Two are related to
> >> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
> >> > > touchpad:
> >> > >
> >> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
> >> > > total 0
> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
> >> >
> >> > This is the HID over I2C touchpad.
> >> >
> >> > >
> >> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
> >> > > in dmesg:
> >> > >
> >> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> > > 00
> >> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> > > 08
> >> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
> >> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> > > 01
> >> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> > > ff 09 01 a1 01 85 09 09 02 15 00 26
> >> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> > > 08
> >> >
> >> > Everything is fine, this is the normal behavior while connecting a
> >> > i2c_hid device.
> >> > Normally, we should have then hid-rmi asking for more things and then
> >> > it will eventually set up the input device.
> >> >
> >> > >
> >> > > I am aware this information probably is not sufficient to draw any
> >> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
> >> > > in detail what steps I should take next. For me the last command timed
> >> > > out or got stuck, but I haven't checked the code to see if it's the
> >> > > case. Anyway, if it was a timeout case, it should have something logged
> >> > > after the time expired.
> >> >
> >> > There is no answer from the device when a SET_POWER is emitted. So
> >> > this is not a timeout problem.
> >> >
> >> > If hid-rmi is compiled and is not taking the device, we have a big
> >> > problem, but for now, the symptoms look like you do not have this
> >> > driver compiled and hid-generic does not bind the device because it
> >> > waits for hid-rmi to handle it.
> >> >
> >>
> >> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
> >> dmesg output (relevant lines):
> >>
> >> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> 00
> >> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> 08
> >> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
> >> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> 01
> >> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> ff 09 01 a1 01 85 09 09 02 15 00 26
> >> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> 08
> >>
> >> I included lines like:
> >>
> >> printk(KERN_ERR "hid_rmi_probe(): called\n");
> >> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
> >>
> >> in the beginning and at the end of the routine rmi_probe(). These lines
> >> didn't
> >> appear in dmesg (those pictured above). I don't know if "probe" is to be
> >> called
> >> in this case, or not. Is there any other condition to make hid-rmi be
> >> "instantiated",
> >> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
> >> from userland,
> >> or even echoing something to the "bind" file at /sys/...?
> >>
> >> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
> >>
> >> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
> >> /sys/bus/hid/drivers/hid-rmi/
> >> total 0
> >> --w------- 1 root root 4096 Out 30 08:03 bind
> >> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
> >> ../../../../module/hid_rmi
> >> --w------- 1 root root 4096 Out 30 08:03 new_id
> >> --w------- 1 root root 4096 Out 30 07:48 uevent
> >> --w------- 1 root root 4096 Out 30 08:03 unbind
> >>
> >> One thing I didn't still did is to reboot the machine. I found it was
> >> not the case,
> >> but this type of action use to work a lot in IT/IS, right? :-)
> >>
> >> > >
> >> > > I have some programming skills, and so if it's the case of applying any
> >> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
> >> > > up to.
> >> >
> >> > Cool, thanks.
> >> >
> >> > Cheers,
> >> > Benjamin
> >>
> >> Many thanks,
> >>
> >> Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-11-05 8:09 ` Luiz Carlos Ramos
@ 2014-11-05 15:35 ` Benjamin Tissoires
2014-11-05 23:09 ` Luiz Carlos Ramos
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2014-11-05 15:35 UTC (permalink / raw)
To: Luiz Carlos Ramos; +Cc: linux-input, Andrew Duggan
Hi Luiz,
On Wed, Nov 5, 2014 at 3:09 AM, Luiz Carlos Ramos
<lramos.prof@yahoo.com.br> wrote:
> Hi, Benjamin,
>
> Thanks again!
>
> Here it is an excerpt from $(udevadm info --export-db), I think the
> relevant one:
>
> P:
> /devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> E:
> DEVPATH=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> E: HID_ID=0018:000006CB:00002985
> E: HID_NAME=DLL0652:00 06CB:2985
> E: MODALIAS=hid:b0018g0000v000006CBp00002985
> E: SUBSYSTEM=hid
> E: UDEV_LOG=3
>
> Also, this is the same information, from
> /sys/bus/hid/devices/0018:06CB:2985.0005/modalias:
>
> root@giustizia:/sys/bus/hid/devices/0018:06CB:2985.0005# cat modalias
> hid:b0018g0000v000006CBp00002985
So this is definitively wrong. g0000 means that your device has not
been scanned for the reports. However, there is no way a vanilla
kernel will not scan a Synaptics HID device.
My guess is that your arch kernel has some crappy patches which
prevent your touchpad to be bound to hid-rmi.
Can you point out to the patches that has been added to the kernel
tree by your distribution? (I never managed to find this information
for arch)
>
> And, finally, the device descriptor:
>
> root@giustizia:/sys/kernel/debug/hid/0018:06CB:2985.0005# cat rdesc
> 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01
> 95 02 81 02 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06
> c0 c0 06 00 ff 09 01 a1 01 85 09 09 02 15 00 26 ff 00 75 08 95 14 91 02
> 85 0a 09 03 15 00 26 ff 00 75 08 95 14 91 02 85 0b 09 04 15 00 26 ff 00
> 75 08 95 1d 81 02 85 0c 09 05 15 00 26 ff 00 75 08 95 1d 81 02 85 0f 09
> 06 15 00 26 ff 00 75 08 95 01 b1 02 c0
Thanks. So after injecting this in my boxes, (which are currently a
plain 3.16.3-200.fc20 from fedora 20, and a somewhat vanilla 3.18-rc3
+ Jiri's upstream hid patches for 3.19), hid-rmi picks up the device.
Please try to use a vanilla kernel and see if things are better.
>
> Yesterday, after sending my reply, I figured out that vendor 06CB means
> Synaptics; am I right?
You are right.
>
> Also, again, if you'd like to me to code/patch/test anything, fell free
> to ask me.
Well, please try a vanilla kernel (3.16.7 if you want to keep your
current config file, or a 3.17.2), and check if it does not magically
works.
Cheers,
Benjamin
>>
>> On Tue, Nov 4, 2014 at 8:11 PM, Luiz Carlos Ramos
>> <lramos.prof@yahoo.com.br> wrote:
>> > Hi, Benjamin,
>> >
>> > I think I just wrote the email below in a way it suggests everything had
>> > gone well and the issue was resolved... but unfortunately it's not the
>> > case. In my reply, I wrote some remarks in the text body in that email,
>> > but I think they weren't noticed at all given the first paragraph.
>>
>> Apologies for that. I read it, thought about it, and forgot it.
>>
>> >
>> > Only to recall, the problem is with a Dell Inspiron 3442, that has a
>> > touchpad which doesn't show up. It seems like it is a Synaptics I2C
>> > device. Your last advice was to insmod hid-rmi, which would hopefully
>> > make things go on after I2C basic device handshake. However, it didn't
>> > happen.
>>
>> Yeah, so given the state of the 3.16 kernel and your tests, the group
>> associated to the device is simply not the RMI one.
>> Which is weird.
>>
>> >
>> > I managed also to put some "printk" at the beginning and at the end of
>> > the "probe" function of hid-rmi, and it seems both were not called. I
>> > don't know if some kind of ioctl() should be issued, or if udevd should
>> > be configured some special way, but my feeling is that I am missing
>> > something really really important and obvious.
>> >
>>
>> No, I think your device is in a black hole. If the device declares
>> nothing special, it should be handled by hid-rmi. But given that it is
>> not the case, it might declares itself as a multitouch capable, and
>> should be handled by hid-multitouch. But if hid-multitouch does not
>> drive it properly, that is weird.
>>
>> Can you provide the modalias of the HID device: in "udevadm info
>> --export-db", look for the device attached to i2c_hid, and find its
>> son which has a modalias in the form of
>> MODALIAS=hid:b0018gXXXXv000006cbp00002985. I am interested in what is
>> after the "g".
>>
>> Also, can you export the content of the report descriptor of your
>> device. You can find it in
>> /sys/kernel/debug/hid/0018\:06CB\:2985.*/rdesc assuming you have
>> debugfs mounted under /sys/kernel/debug
>>
>> Cheers,
>> Benjamin
>>
>> >
>> >
>> > On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
>> >> Hi Benjamin,
>> >>
>> >> Thanks for the assistance and quick reply.
>> >>
>> >> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
>> >> > Hi Luiz,
>> >> >
>> >> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
>> >> > <lramos.prof@yahoo.com.br> wrote:
>> >> > > Hello,
>> >> > >
>> >> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
>> >> > >
>> >> > > Some details:
>> >> > >
>> >> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
>> >> > > tests
>> >> > >
>> >> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
>> >> > > adapter and the laptop's keyboard:
>> >> > >
>> >> > > root@pace:/sys/bus/hid/devices# xinput
>> >> > > Virtual core pointer id=2 [master pointer
>> >> > > (3)]
>> >> > > Virtual core XTEST pointer id=4 [slave
>> >> > > pointer (2)]
>> >> > > Generic USB K/B id=12 [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=9 [slave
>> >> > > keyboard (3)]
>> >> > > Sleep Button id=10 [slave
>> >> > > keyboard (3)]
>> >> > > Integrated_Webcam_HD id=13 [slave
>> >> > > keyboard (3)]
>> >> > > AT Translated Set 2 keyboard id=14 [slave
>> >> > > keyboard (3)]
>> >> > > Dell WMI hotkeys id=15 [slave
>> >> > > keyboard (3)]
>> >> > > Video Bus id=8 [slave
>> >> > > keyboard (3)]
>> >> > > Generic USB K/B id=11 [slave
>> >> > > keyboard (3)]
>> >> > >
>> >> > > - it seems Ubuntu certified this machine (check
>> >> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
>> >> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
>> >> > > even loading psmouse.ko, or doing other tricks
>> >> > >
>> >> > > - some articles lists some tips for making it work (like
>> >> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
>> >> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
>> >> > > them carefully, made some tests, and they didn't work. One article says
>> >> > > I could blacklist i2c_hid or like in order to make the bring up the
>> >> > > touchpad in PS/2 mode, but I couldn't succeed doing so
>> >> > >
>> >> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
>> >> > > almost obsolete. It seems to be just merged into the kernel
>> >> > >
>> >> > > - from Windows 8.1, which runs in the same machine (dual boot), I
>> >> > > concluded the proper way of making it work is to use HID over I2C. It
>> >> > > seems that there are two components loaded; one I2CHID, and a Synaptics
>> >> > > HID. This makes me hint it may be a Synaptics device
>> >> >
>> >> > Well, if this is a Synaptics HID over I2C device, it should be handled
>> >> > by hid-rmi in recent kernels (or hid-multitouch but I would say
>> >> > hid-rmi in your case).
>> >> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
>> >> > if there is any problem?
>> >> >
>> >> > >
>> >> > > - it seems there are two I2C busses in the machine. One is related to
>> >> > > the Intel video graphics subsystem (i801). The other seems to be linked
>> >> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
>> >> > > (i2c_designware_platform) is the right one to be used in this case, but
>> >> > > it appears to be working:
>> >> >
>> >> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
>> >> >
>> >> > >
>> >> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
>> >> > > total 0
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
>> >> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
>> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
>> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
>> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
>> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
>> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
>> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
>> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
>> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
>> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
>> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
>> >> >
>> >> > This one is the touchpad.
>> >> >
>> >> > >
>> >> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
>> >> > > i2c_hid 10682 0
>> >> > > hid 94632 3 i2c_hid,hid_generic,usbhid
>> >> > > i2c_dev 5739 0
>> >> > > i2c_designware_platform 3189 0
>> >> > > i2c_i801 13732 0
>> >> > > i2c_designware_core 6045 1 i2c_designware_platform
>> >> > > i2c_algo_bit 5351 1 i915
>> >> > > i2c_core 35216 11
>> >> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
>> >> > >
>> >> > > - in the HID /sys directory, there are three devices. Two are related to
>> >> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
>> >> > > touchpad:
>> >> > >
>> >> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
>> >> > > total 0
>> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
>> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
>> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
>> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
>> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
>> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
>> >> >
>> >> > This is the HID over I2C touchpad.
>> >> >
>> >> > >
>> >> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
>> >> > > in dmesg:
>> >> > >
>> >> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
>> >> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
>> >> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
>> >> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
>> >> > > 00
>> >> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
>> >> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
>> >> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> > > 08
>> >> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
>> >> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> > > 01
>> >> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
>> >> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
>> >> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
>> >> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
>> >> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
>> >> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
>> >> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
>> >> > > ff 09 01 a1 01 85 09 09 02 15 00 26
>> >> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
>> >> > > 08
>> >> >
>> >> > Everything is fine, this is the normal behavior while connecting a
>> >> > i2c_hid device.
>> >> > Normally, we should have then hid-rmi asking for more things and then
>> >> > it will eventually set up the input device.
>> >> >
>> >> > >
>> >> > > I am aware this information probably is not sufficient to draw any
>> >> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
>> >> > > in detail what steps I should take next. For me the last command timed
>> >> > > out or got stuck, but I haven't checked the code to see if it's the
>> >> > > case. Anyway, if it was a timeout case, it should have something logged
>> >> > > after the time expired.
>> >> >
>> >> > There is no answer from the device when a SET_POWER is emitted. So
>> >> > this is not a timeout problem.
>> >> >
>> >> > If hid-rmi is compiled and is not taking the device, we have a big
>> >> > problem, but for now, the symptoms look like you do not have this
>> >> > driver compiled and hid-generic does not bind the device because it
>> >> > waits for hid-rmi to handle it.
>> >> >
>> >>
>> >> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
>> >> dmesg output (relevant lines):
>> >>
>> >> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
>> >> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
>> >> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
>> >> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
>> >> 00
>> >> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
>> >> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
>> >> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> 08
>> >> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
>> >> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> 01
>> >> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
>> >> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
>> >> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
>> >> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
>> >> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
>> >> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
>> >> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
>> >> ff 09 01 a1 01 85 09 09 02 15 00 26
>> >> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
>> >> 08
>> >>
>> >> I included lines like:
>> >>
>> >> printk(KERN_ERR "hid_rmi_probe(): called\n");
>> >> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
>> >>
>> >> in the beginning and at the end of the routine rmi_probe(). These lines
>> >> didn't
>> >> appear in dmesg (those pictured above). I don't know if "probe" is to be
>> >> called
>> >> in this case, or not. Is there any other condition to make hid-rmi be
>> >> "instantiated",
>> >> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
>> >> from userland,
>> >> or even echoing something to the "bind" file at /sys/...?
>> >>
>> >> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
>> >>
>> >> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
>> >> /sys/bus/hid/drivers/hid-rmi/
>> >> total 0
>> >> --w------- 1 root root 4096 Out 30 08:03 bind
>> >> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
>> >> ../../../../module/hid_rmi
>> >> --w------- 1 root root 4096 Out 30 08:03 new_id
>> >> --w------- 1 root root 4096 Out 30 07:48 uevent
>> >> --w------- 1 root root 4096 Out 30 08:03 unbind
>> >>
>> >> One thing I didn't still did is to reboot the machine. I found it was
>> >> not the case,
>> >> but this type of action use to work a lot in IT/IS, right? :-)
>> >>
>> >> > >
>> >> > > I have some programming skills, and so if it's the case of applying any
>> >> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
>> >> > > up to.
>> >> >
>> >> > Cool, thanks.
>> >> >
>> >> > Cheers,
>> >> > Benjamin
>> >>
>> >> Many thanks,
>> >>
>> >> Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-11-05 15:35 ` Benjamin Tissoires
@ 2014-11-05 23:09 ` Luiz Carlos Ramos
2014-11-06 2:03 ` Andrew Duggan
0 siblings, 1 reply; 10+ messages in thread
From: Luiz Carlos Ramos @ 2014-11-05 23:09 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input, Andrew Duggan
Hi, Benjamin.
I'm just using vanilla 3.16.3, no patches, with .config built from the
one from Slackware stable (kernel 3.10.17). Anyway, I'll try to upgrade
it to the lastest 3.16.
As soon as I have something to inform, I'll keep you informed.
Let me ask you one thing. What exactly is the "g" number in the device
id? The comments at the file include/linux/hid.h suggest it is a kind of
"group", but this "group" seems to be a special word in HID world, with
a meaning different than the common sense.
Thanks again,
Luiz
On Wed, Nov 5, 2014, at 13:35, Benjamin Tissoires wrote:
> Hi Luiz,
>
> On Wed, Nov 5, 2014 at 3:09 AM, Luiz Carlos Ramos
> <lramos.prof@yahoo.com.br> wrote:
> > Hi, Benjamin,
> >
> > Thanks again!
> >
> > Here it is an excerpt from $(udevadm info --export-db), I think the
> > relevant one:
> >
> > P:
> > /devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> > E:
> > DEVPATH=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> > E: HID_ID=0018:000006CB:00002985
> > E: HID_NAME=DLL0652:00 06CB:2985
> > E: MODALIAS=hid:b0018g0000v000006CBp00002985
> > E: SUBSYSTEM=hid
> > E: UDEV_LOG=3
> >
> > Also, this is the same information, from
> > /sys/bus/hid/devices/0018:06CB:2985.0005/modalias:
> >
> > root@giustizia:/sys/bus/hid/devices/0018:06CB:2985.0005# cat modalias
> > hid:b0018g0000v000006CBp00002985
>
> So this is definitively wrong. g0000 means that your device has not
> been scanned for the reports. However, there is no way a vanilla
> kernel will not scan a Synaptics HID device.
> My guess is that your arch kernel has some crappy patches which
> prevent your touchpad to be bound to hid-rmi.
>
> Can you point out to the patches that has been added to the kernel
> tree by your distribution? (I never managed to find this information
> for arch)
>
> >
> > And, finally, the device descriptor:
> >
> > root@giustizia:/sys/kernel/debug/hid/0018:06CB:2985.0005# cat rdesc
> > 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01
> > 95 02 81 02 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06
> > c0 c0 06 00 ff 09 01 a1 01 85 09 09 02 15 00 26 ff 00 75 08 95 14 91 02
> > 85 0a 09 03 15 00 26 ff 00 75 08 95 14 91 02 85 0b 09 04 15 00 26 ff 00
> > 75 08 95 1d 81 02 85 0c 09 05 15 00 26 ff 00 75 08 95 1d 81 02 85 0f 09
> > 06 15 00 26 ff 00 75 08 95 01 b1 02 c0
>
> Thanks. So after injecting this in my boxes, (which are currently a
> plain 3.16.3-200.fc20 from fedora 20, and a somewhat vanilla 3.18-rc3
> + Jiri's upstream hid patches for 3.19), hid-rmi picks up the device.
>
> Please try to use a vanilla kernel and see if things are better.
>
> >
> > Yesterday, after sending my reply, I figured out that vendor 06CB means
> > Synaptics; am I right?
>
> You are right.
>
> >
> > Also, again, if you'd like to me to code/patch/test anything, fell free
> > to ask me.
>
> Well, please try a vanilla kernel (3.16.7 if you want to keep your
> current config file, or a 3.17.2), and check if it does not magically
> works.
>
> Cheers,
> Benjamin
>
> >>
> >> On Tue, Nov 4, 2014 at 8:11 PM, Luiz Carlos Ramos
> >> <lramos.prof@yahoo.com.br> wrote:
> >> > Hi, Benjamin,
> >> >
> >> > I think I just wrote the email below in a way it suggests everything had
> >> > gone well and the issue was resolved... but unfortunately it's not the
> >> > case. In my reply, I wrote some remarks in the text body in that email,
> >> > but I think they weren't noticed at all given the first paragraph.
> >>
> >> Apologies for that. I read it, thought about it, and forgot it.
> >>
> >> >
> >> > Only to recall, the problem is with a Dell Inspiron 3442, that has a
> >> > touchpad which doesn't show up. It seems like it is a Synaptics I2C
> >> > device. Your last advice was to insmod hid-rmi, which would hopefully
> >> > make things go on after I2C basic device handshake. However, it didn't
> >> > happen.
> >>
> >> Yeah, so given the state of the 3.16 kernel and your tests, the group
> >> associated to the device is simply not the RMI one.
> >> Which is weird.
> >>
> >> >
> >> > I managed also to put some "printk" at the beginning and at the end of
> >> > the "probe" function of hid-rmi, and it seems both were not called. I
> >> > don't know if some kind of ioctl() should be issued, or if udevd should
> >> > be configured some special way, but my feeling is that I am missing
> >> > something really really important and obvious.
> >> >
> >>
> >> No, I think your device is in a black hole. If the device declares
> >> nothing special, it should be handled by hid-rmi. But given that it is
> >> not the case, it might declares itself as a multitouch capable, and
> >> should be handled by hid-multitouch. But if hid-multitouch does not
> >> drive it properly, that is weird.
> >>
> >> Can you provide the modalias of the HID device: in "udevadm info
> >> --export-db", look for the device attached to i2c_hid, and find its
> >> son which has a modalias in the form of
> >> MODALIAS=hid:b0018gXXXXv000006cbp00002985. I am interested in what is
> >> after the "g".
> >>
> >> Also, can you export the content of the report descriptor of your
> >> device. You can find it in
> >> /sys/kernel/debug/hid/0018\:06CB\:2985.*/rdesc assuming you have
> >> debugfs mounted under /sys/kernel/debug
> >>
> >> Cheers,
> >> Benjamin
> >>
> >> >
> >> >
> >> > On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
> >> >> Hi Benjamin,
> >> >>
> >> >> Thanks for the assistance and quick reply.
> >> >>
> >> >> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
> >> >> > Hi Luiz,
> >> >> >
> >> >> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
> >> >> > <lramos.prof@yahoo.com.br> wrote:
> >> >> > > Hello,
> >> >> > >
> >> >> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
> >> >> > >
> >> >> > > Some details:
> >> >> > >
> >> >> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
> >> >> > > tests
> >> >> > >
> >> >> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
> >> >> > > adapter and the laptop's keyboard:
> >> >> > >
> >> >> > > root@pace:/sys/bus/hid/devices# xinput
> >> >> > > Virtual core pointer id=2 [master pointer
> >> >> > > (3)]
> >> >> > > Virtual core XTEST pointer id=4 [slave
> >> >> > > pointer (2)]
> >> >> > > Generic USB K/B id=12 [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=9 [slave
> >> >> > > keyboard (3)]
> >> >> > > Sleep Button id=10 [slave
> >> >> > > keyboard (3)]
> >> >> > > Integrated_Webcam_HD id=13 [slave
> >> >> > > keyboard (3)]
> >> >> > > AT Translated Set 2 keyboard id=14 [slave
> >> >> > > keyboard (3)]
> >> >> > > Dell WMI hotkeys id=15 [slave
> >> >> > > keyboard (3)]
> >> >> > > Video Bus id=8 [slave
> >> >> > > keyboard (3)]
> >> >> > > Generic USB K/B id=11 [slave
> >> >> > > keyboard (3)]
> >> >> > >
> >> >> > > - it seems Ubuntu certified this machine (check
> >> >> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
> >> >> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
> >> >> > > even loading psmouse.ko, or doing other tricks
> >> >> > >
> >> >> > > - some articles lists some tips for making it work (like
> >> >> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
> >> >> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
> >> >> > > them carefully, made some tests, and they didn't work. One article says
> >> >> > > I could blacklist i2c_hid or like in order to make the bring up the
> >> >> > > touchpad in PS/2 mode, but I couldn't succeed doing so
> >> >> > >
> >> >> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
> >> >> > > almost obsolete. It seems to be just merged into the kernel
> >> >> > >
> >> >> > > - from Windows 8.1, which runs in the same machine (dual boot), I
> >> >> > > concluded the proper way of making it work is to use HID over I2C. It
> >> >> > > seems that there are two components loaded; one I2CHID, and a Synaptics
> >> >> > > HID. This makes me hint it may be a Synaptics device
> >> >> >
> >> >> > Well, if this is a Synaptics HID over I2C device, it should be handled
> >> >> > by hid-rmi in recent kernels (or hid-multitouch but I would say
> >> >> > hid-rmi in your case).
> >> >> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
> >> >> > if there is any problem?
> >> >> >
> >> >> > >
> >> >> > > - it seems there are two I2C busses in the machine. One is related to
> >> >> > > the Intel video graphics subsystem (i801). The other seems to be linked
> >> >> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
> >> >> > > (i2c_designware_platform) is the right one to be used in this case, but
> >> >> > > it appears to be working:
> >> >> >
> >> >> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
> >> >> >
> >> >> > >
> >> >> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
> >> >> > > total 0
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
> >> >> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
> >> >> >
> >> >> > This one is the touchpad.
> >> >> >
> >> >> > >
> >> >> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
> >> >> > > i2c_hid 10682 0
> >> >> > > hid 94632 3 i2c_hid,hid_generic,usbhid
> >> >> > > i2c_dev 5739 0
> >> >> > > i2c_designware_platform 3189 0
> >> >> > > i2c_i801 13732 0
> >> >> > > i2c_designware_core 6045 1 i2c_designware_platform
> >> >> > > i2c_algo_bit 5351 1 i915
> >> >> > > i2c_core 35216 11
> >> >> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
> >> >> > >
> >> >> > > - in the HID /sys directory, there are three devices. Two are related to
> >> >> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
> >> >> > > touchpad:
> >> >> > >
> >> >> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
> >> >> > > total 0
> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
> >> >> >
> >> >> > This is the HID over I2C touchpad.
> >> >> >
> >> >> > >
> >> >> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
> >> >> > > in dmesg:
> >> >> > >
> >> >> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> >> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> >> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> >> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> >> > > 00
> >> >> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> >> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> >> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> > > 08
> >> >> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
> >> >> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> > > 01
> >> >> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> >> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> >> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> >> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> >> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> >> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> >> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> >> > > ff 09 01 a1 01 85 09 09 02 15 00 26
> >> >> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> >> > > 08
> >> >> >
> >> >> > Everything is fine, this is the normal behavior while connecting a
> >> >> > i2c_hid device.
> >> >> > Normally, we should have then hid-rmi asking for more things and then
> >> >> > it will eventually set up the input device.
> >> >> >
> >> >> > >
> >> >> > > I am aware this information probably is not sufficient to draw any
> >> >> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
> >> >> > > in detail what steps I should take next. For me the last command timed
> >> >> > > out or got stuck, but I haven't checked the code to see if it's the
> >> >> > > case. Anyway, if it was a timeout case, it should have something logged
> >> >> > > after the time expired.
> >> >> >
> >> >> > There is no answer from the device when a SET_POWER is emitted. So
> >> >> > this is not a timeout problem.
> >> >> >
> >> >> > If hid-rmi is compiled and is not taking the device, we have a big
> >> >> > problem, but for now, the symptoms look like you do not have this
> >> >> > driver compiled and hid-generic does not bind the device because it
> >> >> > waits for hid-rmi to handle it.
> >> >> >
> >> >>
> >> >> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
> >> >> dmesg output (relevant lines):
> >> >>
> >> >> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> >> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> >> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> >> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> >> 00
> >> >> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> >> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> >> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> 08
> >> >> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
> >> >> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> 01
> >> >> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> >> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> >> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> >> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> >> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> >> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> >> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> >> ff 09 01 a1 01 85 09 09 02 15 00 26
> >> >> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> >> 08
> >> >>
> >> >> I included lines like:
> >> >>
> >> >> printk(KERN_ERR "hid_rmi_probe(): called\n");
> >> >> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
> >> >>
> >> >> in the beginning and at the end of the routine rmi_probe(). These lines
> >> >> didn't
> >> >> appear in dmesg (those pictured above). I don't know if "probe" is to be
> >> >> called
> >> >> in this case, or not. Is there any other condition to make hid-rmi be
> >> >> "instantiated",
> >> >> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
> >> >> from userland,
> >> >> or even echoing something to the "bind" file at /sys/...?
> >> >>
> >> >> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
> >> >>
> >> >> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
> >> >> /sys/bus/hid/drivers/hid-rmi/
> >> >> total 0
> >> >> --w------- 1 root root 4096 Out 30 08:03 bind
> >> >> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
> >> >> ../../../../module/hid_rmi
> >> >> --w------- 1 root root 4096 Out 30 08:03 new_id
> >> >> --w------- 1 root root 4096 Out 30 07:48 uevent
> >> >> --w------- 1 root root 4096 Out 30 08:03 unbind
> >> >>
> >> >> One thing I didn't still did is to reboot the machine. I found it was
> >> >> not the case,
> >> >> but this type of action use to work a lot in IT/IS, right? :-)
> >> >>
> >> >> > >
> >> >> > > I have some programming skills, and so if it's the case of applying any
> >> >> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
> >> >> > > up to.
> >> >> >
> >> >> > Cool, thanks.
> >> >> >
> >> >> > Cheers,
> >> >> > Benjamin
> >> >>
> >> >> Many thanks,
> >> >>
> >> >> Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-11-05 23:09 ` Luiz Carlos Ramos
@ 2014-11-06 2:03 ` Andrew Duggan
2014-11-07 9:33 ` Luiz Carlos Ramos
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Duggan @ 2014-11-06 2:03 UTC (permalink / raw)
To: Luiz Carlos Ramos; +Cc: Benjamin Tissoires, linux-input
On Wed, Nov 5, 2014 at 3:09 PM, Luiz Carlos Ramos
<lramos.prof@yahoo.com.br> wrote:
> Hi, Benjamin.
>
> I'm just using vanilla 3.16.3, no patches, with .config built from the
> one from Slackware stable (kernel 3.10.17). Anyway, I'll try to upgrade
> it to the lastest 3.16.
>
I pulled 3.16.3 from linux-stable and tested with a similar touchpad.
Everything worked as expected and the touchpad was assigned to
HID_GROUP_RMI and hid-rmi bound to it. The touchpad in this Dell
system looks like it should be similar to the touchpads in other Dell
systems which we have tested with hid-rmi. Like those other systems it
does also have a PS/2 interface. But, I don't think that this is
significant because i2c_hid is talking to the touchpad and is
successfully reading the report descriptor. That would not interfere
with the group assignment.
The only thing that I can think of is either the hid module is being
loaded with the ignore_special_drivers parameter set, or somehow an
entry got added to the hid_have_special_driver list. I would guess the
ignore_special_drivers parameter is set since there would not be an
entry for our VID in hid_have_special_driver in a vanilla kernel.
> As soon as I have something to inform, I'll keep you informed.
>
> Let me ask you one thing. What exactly is the "g" number in the device
> id? The comments at the file include/linux/hid.h suggest it is a kind of
> "group", but this "group" seems to be a special word in HID world, with
> a meaning different than the common sense.
>
The hid-core driver parses the HID report descriptor and assigns the
device a group based on the fields in the descriptor. Later, hid-core
uses the group to determine which subdriver to bind to the device and
the group number is included in modalias. Since, your touchpad has the
Synaptics vendor id hid_scan_report should be assigning it the group
HID_GROUP_RMI (g0100 in modalias since HID_GROUP_RMI is defined as
0x0100 in include/linux/hid.h). But, according to your modalias no
group is being assigned.
> Thanks again,
>
> Luiz
>
>
> On Wed, Nov 5, 2014, at 13:35, Benjamin Tissoires wrote:
>> Hi Luiz,
>>
>> On Wed, Nov 5, 2014 at 3:09 AM, Luiz Carlos Ramos
>> <lramos.prof@yahoo.com.br> wrote:
>> > Hi, Benjamin,
>> >
>> > Thanks again!
>> >
>> > Here it is an excerpt from $(udevadm info --export-db), I think the
>> > relevant one:
>> >
>> > P:
>> > /devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
>> > E:
>> > DEVPATH=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
>> > E: HID_ID=0018:000006CB:00002985
>> > E: HID_NAME=DLL0652:00 06CB:2985
>> > E: MODALIAS=hid:b0018g0000v000006CBp00002985
>> > E: SUBSYSTEM=hid
>> > E: UDEV_LOG=3
>> >
>> > Also, this is the same information, from
>> > /sys/bus/hid/devices/0018:06CB:2985.0005/modalias:
>> >
>> > root@giustizia:/sys/bus/hid/devices/0018:06CB:2985.0005# cat modalias
>> > hid:b0018g0000v000006CBp00002985
>>
>> So this is definitively wrong. g0000 means that your device has not
>> been scanned for the reports. However, there is no way a vanilla
>> kernel will not scan a Synaptics HID device.
>> My guess is that your arch kernel has some crappy patches which
>> prevent your touchpad to be bound to hid-rmi.
>>
>> Can you point out to the patches that has been added to the kernel
>> tree by your distribution? (I never managed to find this information
>> for arch)
>>
>> >
>> > And, finally, the device descriptor:
>> >
>> > root@giustizia:/sys/kernel/debug/hid/0018:06CB:2985.0005# cat rdesc
>> > 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01
>> > 95 02 81 02 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06
>> > c0 c0 06 00 ff 09 01 a1 01 85 09 09 02 15 00 26 ff 00 75 08 95 14 91 02
>> > 85 0a 09 03 15 00 26 ff 00 75 08 95 14 91 02 85 0b 09 04 15 00 26 ff 00
>> > 75 08 95 1d 81 02 85 0c 09 05 15 00 26 ff 00 75 08 95 1d 81 02 85 0f 09
>> > 06 15 00 26 ff 00 75 08 95 01 b1 02 c0
>>
>> Thanks. So after injecting this in my boxes, (which are currently a
>> plain 3.16.3-200.fc20 from fedora 20, and a somewhat vanilla 3.18-rc3
>> + Jiri's upstream hid patches for 3.19), hid-rmi picks up the device.
>>
>> Please try to use a vanilla kernel and see if things are better.
>>
>> >
>> > Yesterday, after sending my reply, I figured out that vendor 06CB means
>> > Synaptics; am I right?
>>
>> You are right.
>>
>> >
>> > Also, again, if you'd like to me to code/patch/test anything, fell free
>> > to ask me.
>>
>> Well, please try a vanilla kernel (3.16.7 if you want to keep your
>> current config file, or a 3.17.2), and check if it does not magically
>> works.
>>
>> Cheers,
>> Benjamin
>>
>> >>
>> >> On Tue, Nov 4, 2014 at 8:11 PM, Luiz Carlos Ramos
>> >> <lramos.prof@yahoo.com.br> wrote:
>> >> > Hi, Benjamin,
>> >> >
>> >> > I think I just wrote the email below in a way it suggests everything had
>> >> > gone well and the issue was resolved... but unfortunately it's not the
>> >> > case. In my reply, I wrote some remarks in the text body in that email,
>> >> > but I think they weren't noticed at all given the first paragraph.
>> >>
>> >> Apologies for that. I read it, thought about it, and forgot it.
>> >>
>> >> >
>> >> > Only to recall, the problem is with a Dell Inspiron 3442, that has a
>> >> > touchpad which doesn't show up. It seems like it is a Synaptics I2C
>> >> > device. Your last advice was to insmod hid-rmi, which would hopefully
>> >> > make things go on after I2C basic device handshake. However, it didn't
>> >> > happen.
>> >>
>> >> Yeah, so given the state of the 3.16 kernel and your tests, the group
>> >> associated to the device is simply not the RMI one.
>> >> Which is weird.
>> >>
>> >> >
>> >> > I managed also to put some "printk" at the beginning and at the end of
>> >> > the "probe" function of hid-rmi, and it seems both were not called. I
>> >> > don't know if some kind of ioctl() should be issued, or if udevd should
>> >> > be configured some special way, but my feeling is that I am missing
>> >> > something really really important and obvious.
>> >> >
>> >>
>> >> No, I think your device is in a black hole. If the device declares
>> >> nothing special, it should be handled by hid-rmi. But given that it is
>> >> not the case, it might declares itself as a multitouch capable, and
>> >> should be handled by hid-multitouch. But if hid-multitouch does not
>> >> drive it properly, that is weird.
>> >>
>> >> Can you provide the modalias of the HID device: in "udevadm info
>> >> --export-db", look for the device attached to i2c_hid, and find its
>> >> son which has a modalias in the form of
>> >> MODALIAS=hid:b0018gXXXXv000006cbp00002985. I am interested in what is
>> >> after the "g".
>> >>
>> >> Also, can you export the content of the report descriptor of your
>> >> device. You can find it in
>> >> /sys/kernel/debug/hid/0018\:06CB\:2985.*/rdesc assuming you have
>> >> debugfs mounted under /sys/kernel/debug
>> >>
>> >> Cheers,
>> >> Benjamin
>> >>
>> >> >
>> >> >
>> >> > On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
>> >> >> Hi Benjamin,
>> >> >>
>> >> >> Thanks for the assistance and quick reply.
>> >> >>
>> >> >> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
>> >> >> > Hi Luiz,
>> >> >> >
>> >> >> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
>> >> >> > <lramos.prof@yahoo.com.br> wrote:
>> >> >> > > Hello,
>> >> >> > >
>> >> >> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
>> >> >> > >
>> >> >> > > Some details:
>> >> >> > >
>> >> >> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
>> >> >> > > tests
>> >> >> > >
>> >> >> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
>> >> >> > > adapter and the laptop's keyboard:
>> >> >> > >
>> >> >> > > root@pace:/sys/bus/hid/devices# xinput
>> >> >> > > Virtual core pointer id=2 [master pointer
>> >> >> > > (3)]
>> >> >> > > Virtual core XTEST pointer id=4 [slave
>> >> >> > > pointer (2)]
>> >> >> > > Generic USB K/B id=12 [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=9 [slave
>> >> >> > > keyboard (3)]
>> >> >> > > Sleep Button id=10 [slave
>> >> >> > > keyboard (3)]
>> >> >> > > Integrated_Webcam_HD id=13 [slave
>> >> >> > > keyboard (3)]
>> >> >> > > AT Translated Set 2 keyboard id=14 [slave
>> >> >> > > keyboard (3)]
>> >> >> > > Dell WMI hotkeys id=15 [slave
>> >> >> > > keyboard (3)]
>> >> >> > > Video Bus id=8 [slave
>> >> >> > > keyboard (3)]
>> >> >> > > Generic USB K/B id=11 [slave
>> >> >> > > keyboard (3)]
>> >> >> > >
>> >> >> > > - it seems Ubuntu certified this machine (check
>> >> >> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
>> >> >> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
>> >> >> > > even loading psmouse.ko, or doing other tricks
>> >> >> > >
>> >> >> > > - some articles lists some tips for making it work (like
>> >> >> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
>> >> >> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
>> >> >> > > them carefully, made some tests, and they didn't work. One article says
>> >> >> > > I could blacklist i2c_hid or like in order to make the bring up the
>> >> >> > > touchpad in PS/2 mode, but I couldn't succeed doing so
>> >> >> > >
>> >> >> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
>> >> >> > > almost obsolete. It seems to be just merged into the kernel
>> >> >> > >
>> >> >> > > - from Windows 8.1, which runs in the same machine (dual boot), I
>> >> >> > > concluded the proper way of making it work is to use HID over I2C. It
>> >> >> > > seems that there are two components loaded; one I2CHID, and a Synaptics
>> >> >> > > HID. This makes me hint it may be a Synaptics device
>> >> >> >
>> >> >> > Well, if this is a Synaptics HID over I2C device, it should be handled
>> >> >> > by hid-rmi in recent kernels (or hid-multitouch but I would say
>> >> >> > hid-rmi in your case).
>> >> >> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
>> >> >> > if there is any problem?
>> >> >> >
>> >> >> > >
>> >> >> > > - it seems there are two I2C busses in the machine. One is related to
>> >> >> > > the Intel video graphics subsystem (i801). The other seems to be linked
>> >> >> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
>> >> >> > > (i2c_designware_platform) is the right one to be used in this case, but
>> >> >> > > it appears to be working:
>> >> >> >
>> >> >> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
>> >> >> >
>> >> >> > >
>> >> >> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
>> >> >> > > total 0
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
>> >> >> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
>> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
>> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
>> >> >> >
>> >> >> > This one is the touchpad.
>> >> >> >
>> >> >> > >
>> >> >> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
>> >> >> > > i2c_hid 10682 0
>> >> >> > > hid 94632 3 i2c_hid,hid_generic,usbhid
>> >> >> > > i2c_dev 5739 0
>> >> >> > > i2c_designware_platform 3189 0
>> >> >> > > i2c_i801 13732 0
>> >> >> > > i2c_designware_core 6045 1 i2c_designware_platform
>> >> >> > > i2c_algo_bit 5351 1 i915
>> >> >> > > i2c_core 35216 11
>> >> >> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
>> >> >> > >
>> >> >> > > - in the HID /sys directory, there are three devices. Two are related to
>> >> >> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
>> >> >> > > touchpad:
>> >> >> > >
>> >> >> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
>> >> >> > > total 0
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
>> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
>> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
>> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
>> >> >> >
>> >> >> > This is the HID over I2C touchpad.
>> >> >> >
>> >> >> > >
>> >> >> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
>> >> >> > > in dmesg:
>> >> >> > >
>> >> >> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
>> >> >> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
>> >> >> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
>> >> >> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
>> >> >> > > 00
>> >> >> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
>> >> >> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
>> >> >> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> >> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> >> > > 08
>> >> >> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
>> >> >> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> >> > > 01
>> >> >> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
>> >> >> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
>> >> >> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
>> >> >> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
>> >> >> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
>> >> >> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
>> >> >> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
>> >> >> > > ff 09 01 a1 01 85 09 09 02 15 00 26
>> >> >> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> >> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
>> >> >> > > 08
>> >> >> >
>> >> >> > Everything is fine, this is the normal behavior while connecting a
>> >> >> > i2c_hid device.
>> >> >> > Normally, we should have then hid-rmi asking for more things and then
>> >> >> > it will eventually set up the input device.
>> >> >> >
>> >> >> > >
>> >> >> > > I am aware this information probably is not sufficient to draw any
>> >> >> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
>> >> >> > > in detail what steps I should take next. For me the last command timed
>> >> >> > > out or got stuck, but I haven't checked the code to see if it's the
>> >> >> > > case. Anyway, if it was a timeout case, it should have something logged
>> >> >> > > after the time expired.
>> >> >> >
>> >> >> > There is no answer from the device when a SET_POWER is emitted. So
>> >> >> > this is not a timeout problem.
>> >> >> >
>> >> >> > If hid-rmi is compiled and is not taking the device, we have a big
>> >> >> > problem, but for now, the symptoms look like you do not have this
>> >> >> > driver compiled and hid-generic does not bind the device because it
>> >> >> > waits for hid-rmi to handle it.
>> >> >> >
>> >> >>
>> >> >> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
>> >> >> dmesg output (relevant lines):
>> >> >>
>> >> >> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
>> >> >> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
>> >> >> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
>> >> >> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
>> >> >> 00
>> >> >> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
>> >> >> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
>> >> >> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> >> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> >> 08
>> >> >> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
>> >> >> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
>> >> >> 01
>> >> >> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
>> >> >> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
>> >> >> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
>> >> >> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
>> >> >> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
>> >> >> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
>> >> >> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
>> >> >> ff 09 01 a1 01 85 09 09 02 15 00 26
>> >> >> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
>> >> >> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
>> >> >> 08
>> >> >>
>> >> >> I included lines like:
>> >> >>
>> >> >> printk(KERN_ERR "hid_rmi_probe(): called\n");
>> >> >> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
>> >> >>
>> >> >> in the beginning and at the end of the routine rmi_probe(). These lines
>> >> >> didn't
>> >> >> appear in dmesg (those pictured above). I don't know if "probe" is to be
>> >> >> called
>> >> >> in this case, or not. Is there any other condition to make hid-rmi be
>> >> >> "instantiated",
>> >> >> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
>> >> >> from userland,
>> >> >> or even echoing something to the "bind" file at /sys/...?
>> >> >>
>> >> >> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
>> >> >>
>> >> >> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
>> >> >> /sys/bus/hid/drivers/hid-rmi/
>> >> >> total 0
>> >> >> --w------- 1 root root 4096 Out 30 08:03 bind
>> >> >> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
>> >> >> ../../../../module/hid_rmi
>> >> >> --w------- 1 root root 4096 Out 30 08:03 new_id
>> >> >> --w------- 1 root root 4096 Out 30 07:48 uevent
>> >> >> --w------- 1 root root 4096 Out 30 08:03 unbind
>> >> >>
>> >> >> One thing I didn't still did is to reboot the machine. I found it was
>> >> >> not the case,
>> >> >> but this type of action use to work a lot in IT/IS, right? :-)
>> >> >>
>> >> >> > >
>> >> >> > > I have some programming skills, and so if it's the case of applying any
>> >> >> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
>> >> >> > > up to.
>> >> >> >
>> >> >> > Cool, thanks.
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Benjamin
>> >> >>
>> >> >> Many thanks,
>> >> >>
>> >> >> Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About Dell Inspiron 3442 touchpad
2014-11-06 2:03 ` Andrew Duggan
@ 2014-11-07 9:33 ` Luiz Carlos Ramos
0 siblings, 0 replies; 10+ messages in thread
From: Luiz Carlos Ramos @ 2014-11-07 9:33 UTC (permalink / raw)
To: Andrew Duggan, Benjamin Tissoires; +Cc: linux-input
Hello, Andrew and Benjamin,
I managed to sync the working directory with git, and noticed there were
some experiments I've made which were "live" in the working directory.
So, I was wrong when I told the kernel was pure vanilla 3.16.3. One of
the changes may explain what happened with the touchpad.
After resync'ing the working directory with git, rebuilding the kernel
and
restarting the laptop, I could make the touchpad work for the first
time.
Now there are problems with the right button, but much probably it is
some kind of Xorg configuration issue.
So, the main issue is solved.
I'd like to thank you for the assistance, and apologize somehow for that
mistake.
Thanks,
Luiz
On Thu, Nov 6, 2014, at 00:03, Andrew Duggan wrote:
> On Wed, Nov 5, 2014 at 3:09 PM, Luiz Carlos Ramos
> <lramos.prof@yahoo.com.br> wrote:
> > Hi, Benjamin.
> >
> > I'm just using vanilla 3.16.3, no patches, with .config built from the
> > one from Slackware stable (kernel 3.10.17). Anyway, I'll try to upgrade
> > it to the lastest 3.16.
> >
>
> I pulled 3.16.3 from linux-stable and tested with a similar touchpad.
> Everything worked as expected and the touchpad was assigned to
> HID_GROUP_RMI and hid-rmi bound to it. The touchpad in this Dell
> system looks like it should be similar to the touchpads in other Dell
> systems which we have tested with hid-rmi. Like those other systems it
> does also have a PS/2 interface. But, I don't think that this is
> significant because i2c_hid is talking to the touchpad and is
> successfully reading the report descriptor. That would not interfere
> with the group assignment.
>
> The only thing that I can think of is either the hid module is being
> loaded with the ignore_special_drivers parameter set, or somehow an
> entry got added to the hid_have_special_driver list. I would guess the
> ignore_special_drivers parameter is set since there would not be an
> entry for our VID in hid_have_special_driver in a vanilla kernel.
>
> > As soon as I have something to inform, I'll keep you informed.
> >
> > Let me ask you one thing. What exactly is the "g" number in the device
> > id? The comments at the file include/linux/hid.h suggest it is a kind of
> > "group", but this "group" seems to be a special word in HID world, with
> > a meaning different than the common sense.
> >
>
> The hid-core driver parses the HID report descriptor and assigns the
> device a group based on the fields in the descriptor. Later, hid-core
> uses the group to determine which subdriver to bind to the device and
> the group number is included in modalias. Since, your touchpad has the
> Synaptics vendor id hid_scan_report should be assigning it the group
> HID_GROUP_RMI (g0100 in modalias since HID_GROUP_RMI is defined as
> 0x0100 in include/linux/hid.h). But, according to your modalias no
> group is being assigned.
>
> > Thanks again,
> >
> > Luiz
> >
> >
> > On Wed, Nov 5, 2014, at 13:35, Benjamin Tissoires wrote:
> >> Hi Luiz,
> >>
> >> On Wed, Nov 5, 2014 at 3:09 AM, Luiz Carlos Ramos
> >> <lramos.prof@yahoo.com.br> wrote:
> >> > Hi, Benjamin,
> >> >
> >> > Thanks again!
> >> >
> >> > Here it is an excerpt from $(udevadm info --export-db), I think the
> >> > relevant one:
> >> >
> >> > P:
> >> > /devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> >> > E:
> >> > DEVPATH=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> >> > E: HID_ID=0018:000006CB:00002985
> >> > E: HID_NAME=DLL0652:00 06CB:2985
> >> > E: MODALIAS=hid:b0018g0000v000006CBp00002985
> >> > E: SUBSYSTEM=hid
> >> > E: UDEV_LOG=3
> >> >
> >> > Also, this is the same information, from
> >> > /sys/bus/hid/devices/0018:06CB:2985.0005/modalias:
> >> >
> >> > root@giustizia:/sys/bus/hid/devices/0018:06CB:2985.0005# cat modalias
> >> > hid:b0018g0000v000006CBp00002985
> >>
> >> So this is definitively wrong. g0000 means that your device has not
> >> been scanned for the reports. However, there is no way a vanilla
> >> kernel will not scan a Synaptics HID device.
> >> My guess is that your arch kernel has some crappy patches which
> >> prevent your touchpad to be bound to hid-rmi.
> >>
> >> Can you point out to the patches that has been added to the kernel
> >> tree by your distribution? (I never managed to find this information
> >> for arch)
> >>
> >> >
> >> > And, finally, the device descriptor:
> >> >
> >> > root@giustizia:/sys/kernel/debug/hid/0018:06CB:2985.0005# cat rdesc
> >> > 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01
> >> > 95 02 81 02 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06
> >> > c0 c0 06 00 ff 09 01 a1 01 85 09 09 02 15 00 26 ff 00 75 08 95 14 91 02
> >> > 85 0a 09 03 15 00 26 ff 00 75 08 95 14 91 02 85 0b 09 04 15 00 26 ff 00
> >> > 75 08 95 1d 81 02 85 0c 09 05 15 00 26 ff 00 75 08 95 1d 81 02 85 0f 09
> >> > 06 15 00 26 ff 00 75 08 95 01 b1 02 c0
> >>
> >> Thanks. So after injecting this in my boxes, (which are currently a
> >> plain 3.16.3-200.fc20 from fedora 20, and a somewhat vanilla 3.18-rc3
> >> + Jiri's upstream hid patches for 3.19), hid-rmi picks up the device.
> >>
> >> Please try to use a vanilla kernel and see if things are better.
> >>
> >> >
> >> > Yesterday, after sending my reply, I figured out that vendor 06CB means
> >> > Synaptics; am I right?
> >>
> >> You are right.
> >>
> >> >
> >> > Also, again, if you'd like to me to code/patch/test anything, fell free
> >> > to ask me.
> >>
> >> Well, please try a vanilla kernel (3.16.7 if you want to keep your
> >> current config file, or a 3.17.2), and check if it does not magically
> >> works.
> >>
> >> Cheers,
> >> Benjamin
> >>
> >> >>
> >> >> On Tue, Nov 4, 2014 at 8:11 PM, Luiz Carlos Ramos
> >> >> <lramos.prof@yahoo.com.br> wrote:
> >> >> > Hi, Benjamin,
> >> >> >
> >> >> > I think I just wrote the email below in a way it suggests everything had
> >> >> > gone well and the issue was resolved... but unfortunately it's not the
> >> >> > case. In my reply, I wrote some remarks in the text body in that email,
> >> >> > but I think they weren't noticed at all given the first paragraph.
> >> >>
> >> >> Apologies for that. I read it, thought about it, and forgot it.
> >> >>
> >> >> >
> >> >> > Only to recall, the problem is with a Dell Inspiron 3442, that has a
> >> >> > touchpad which doesn't show up. It seems like it is a Synaptics I2C
> >> >> > device. Your last advice was to insmod hid-rmi, which would hopefully
> >> >> > make things go on after I2C basic device handshake. However, it didn't
> >> >> > happen.
> >> >>
> >> >> Yeah, so given the state of the 3.16 kernel and your tests, the group
> >> >> associated to the device is simply not the RMI one.
> >> >> Which is weird.
> >> >>
> >> >> >
> >> >> > I managed also to put some "printk" at the beginning and at the end of
> >> >> > the "probe" function of hid-rmi, and it seems both were not called. I
> >> >> > don't know if some kind of ioctl() should be issued, or if udevd should
> >> >> > be configured some special way, but my feeling is that I am missing
> >> >> > something really really important and obvious.
> >> >> >
> >> >>
> >> >> No, I think your device is in a black hole. If the device declares
> >> >> nothing special, it should be handled by hid-rmi. But given that it is
> >> >> not the case, it might declares itself as a multitouch capable, and
> >> >> should be handled by hid-multitouch. But if hid-multitouch does not
> >> >> drive it properly, that is weird.
> >> >>
> >> >> Can you provide the modalias of the HID device: in "udevadm info
> >> >> --export-db", look for the device attached to i2c_hid, and find its
> >> >> son which has a modalias in the form of
> >> >> MODALIAS=hid:b0018gXXXXv000006cbp00002985. I am interested in what is
> >> >> after the "g".
> >> >>
> >> >> Also, can you export the content of the report descriptor of your
> >> >> device. You can find it in
> >> >> /sys/kernel/debug/hid/0018\:06CB\:2985.*/rdesc assuming you have
> >> >> debugfs mounted under /sys/kernel/debug
> >> >>
> >> >> Cheers,
> >> >> Benjamin
> >> >>
> >> >> >
> >> >> >
> >> >> > On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
> >> >> >> Hi Benjamin,
> >> >> >>
> >> >> >> Thanks for the assistance and quick reply.
> >> >> >>
> >> >> >> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
> >> >> >> > Hi Luiz,
> >> >> >> >
> >> >> >> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
> >> >> >> > <lramos.prof@yahoo.com.br> wrote:
> >> >> >> > > Hello,
> >> >> >> > >
> >> >> >> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
> >> >> >> > >
> >> >> >> > > Some details:
> >> >> >> > >
> >> >> >> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
> >> >> >> > > tests
> >> >> >> > >
> >> >> >> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
> >> >> >> > > adapter and the laptop's keyboard:
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/hid/devices# xinput
> >> >> >> > > Virtual core pointer id=2 [master pointer
> >> >> >> > > (3)]
> >> >> >> > > Virtual core XTEST pointer id=4 [slave
> >> >> >> > > pointer (2)]
> >> >> >> > > Generic USB K/B id=12 [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=9 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Sleep Button id=10 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Integrated_Webcam_HD id=13 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > AT Translated Set 2 keyboard id=14 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Dell WMI hotkeys id=15 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Video Bus id=8 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Generic USB K/B id=11 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > >
> >> >> >> > > - it seems Ubuntu certified this machine (check
> >> >> >> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
> >> >> >> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
> >> >> >> > > even loading psmouse.ko, or doing other tricks
> >> >> >> > >
> >> >> >> > > - some articles lists some tips for making it work (like
> >> >> >> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
> >> >> >> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
> >> >> >> > > them carefully, made some tests, and they didn't work. One article says
> >> >> >> > > I could blacklist i2c_hid or like in order to make the bring up the
> >> >> >> > > touchpad in PS/2 mode, but I couldn't succeed doing so
> >> >> >> > >
> >> >> >> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
> >> >> >> > > almost obsolete. It seems to be just merged into the kernel
> >> >> >> > >
> >> >> >> > > - from Windows 8.1, which runs in the same machine (dual boot), I
> >> >> >> > > concluded the proper way of making it work is to use HID over I2C. It
> >> >> >> > > seems that there are two components loaded; one I2CHID, and a Synaptics
> >> >> >> > > HID. This makes me hint it may be a Synaptics device
> >> >> >> >
> >> >> >> > Well, if this is a Synaptics HID over I2C device, it should be handled
> >> >> >> > by hid-rmi in recent kernels (or hid-multitouch but I would say
> >> >> >> > hid-rmi in your case).
> >> >> >> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
> >> >> >> > if there is any problem?
> >> >> >> >
> >> >> >> > >
> >> >> >> > > - it seems there are two I2C busses in the machine. One is related to
> >> >> >> > > the Intel video graphics subsystem (i801). The other seems to be linked
> >> >> >> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
> >> >> >> > > (i2c_designware_platform) is the right one to be used in this case, but
> >> >> >> > > it appears to be working:
> >> >> >> >
> >> >> >> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
> >> >> >> > > total 0
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
> >> >> >> >
> >> >> >> > This one is the touchpad.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
> >> >> >> > > i2c_hid 10682 0
> >> >> >> > > hid 94632 3 i2c_hid,hid_generic,usbhid
> >> >> >> > > i2c_dev 5739 0
> >> >> >> > > i2c_designware_platform 3189 0
> >> >> >> > > i2c_i801 13732 0
> >> >> >> > > i2c_designware_core 6045 1 i2c_designware_platform
> >> >> >> > > i2c_algo_bit 5351 1 i915
> >> >> >> > > i2c_core 35216 11
> >> >> >> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
> >> >> >> > >
> >> >> >> > > - in the HID /sys directory, there are three devices. Two are related to
> >> >> >> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
> >> >> >> > > touchpad:
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
> >> >> >> > > total 0
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
> >> >> >> >
> >> >> >> > This is the HID over I2C touchpad.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
> >> >> >> > > in dmesg:
> >> >> >> > >
> >> >> >> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> >> >> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> >> >> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> >> >> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> >> >> > > 00
> >> >> >> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> >> >> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> >> >> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> > > 08
> >> >> >> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
> >> >> >> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> > > 01
> >> >> >> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> >> >> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> >> >> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> >> >> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> >> >> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> >> >> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> >> >> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> >> >> > > ff 09 01 a1 01 85 09 09 02 15 00 26
> >> >> >> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> >> >> > > 08
> >> >> >> >
> >> >> >> > Everything is fine, this is the normal behavior while connecting a
> >> >> >> > i2c_hid device.
> >> >> >> > Normally, we should have then hid-rmi asking for more things and then
> >> >> >> > it will eventually set up the input device.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > I am aware this information probably is not sufficient to draw any
> >> >> >> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
> >> >> >> > > in detail what steps I should take next. For me the last command timed
> >> >> >> > > out or got stuck, but I haven't checked the code to see if it's the
> >> >> >> > > case. Anyway, if it was a timeout case, it should have something logged
> >> >> >> > > after the time expired.
> >> >> >> >
> >> >> >> > There is no answer from the device when a SET_POWER is emitted. So
> >> >> >> > this is not a timeout problem.
> >> >> >> >
> >> >> >> > If hid-rmi is compiled and is not taking the device, we have a big
> >> >> >> > problem, but for now, the symptoms look like you do not have this
> >> >> >> > driver compiled and hid-generic does not bind the device because it
> >> >> >> > waits for hid-rmi to handle it.
> >> >> >> >
> >> >> >>
> >> >> >> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
> >> >> >> dmesg output (relevant lines):
> >> >> >>
> >> >> >> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> >> >> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> >> >> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> >> >> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> >> >> 00
> >> >> >> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> >> >> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> >> >> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> 08
> >> >> >> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
> >> >> >> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> 01
> >> >> >> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> >> >> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> >> >> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> >> >> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> >> >> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> >> >> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> >> >> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> >> >> ff 09 01 a1 01 85 09 09 02 15 00 26
> >> >> >> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> >> >> 08
> >> >> >>
> >> >> >> I included lines like:
> >> >> >>
> >> >> >> printk(KERN_ERR "hid_rmi_probe(): called\n");
> >> >> >> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
> >> >> >>
> >> >> >> in the beginning and at the end of the routine rmi_probe(). These lines
> >> >> >> didn't
> >> >> >> appear in dmesg (those pictured above). I don't know if "probe" is to be
> >> >> >> called
> >> >> >> in this case, or not. Is there any other condition to make hid-rmi be
> >> >> >> "instantiated",
> >> >> >> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
> >> >> >> from userland,
> >> >> >> or even echoing something to the "bind" file at /sys/...?
> >> >> >>
> >> >> >> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
> >> >> >>
> >> >> >> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
> >> >> >> /sys/bus/hid/drivers/hid-rmi/
> >> >> >> total 0
> >> >> >> --w------- 1 root root 4096 Out 30 08:03 bind
> >> >> >> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
> >> >> >> ../../../../module/hid_rmi
> >> >> >> --w------- 1 root root 4096 Out 30 08:03 new_id
> >> >> >> --w------- 1 root root 4096 Out 30 07:48 uevent
> >> >> >> --w------- 1 root root 4096 Out 30 08:03 unbind
> >> >> >>
> >> >> >> One thing I didn't still did is to reboot the machine. I found it was
> >> >> >> not the case,
> >> >> >> but this type of action use to work a lot in IT/IS, right? :-)
> >> >> >>
> >> >> >> > >
> >> >> >> > > I have some programming skills, and so if it's the case of applying any
> >> >> >> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
> >> >> >> > > up to.
> >> >> >> >
> >> >> >> > Cool, thanks.
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Benjamin
> >> >> >>
> >> >> >> Many thanks,
> >> >> >>
> >> >> >> Luiz
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-11-07 9:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-29 1:00 About Dell Inspiron 3442 touchpad Luiz Carlos Ramos
2014-10-29 1:40 ` Benjamin Tissoires
2014-10-30 10:06 ` Luiz Carlos Ramos
2014-11-05 1:11 ` Luiz Carlos Ramos
2014-11-05 2:49 ` Benjamin Tissoires
2014-11-05 8:09 ` Luiz Carlos Ramos
2014-11-05 15:35 ` Benjamin Tissoires
2014-11-05 23:09 ` Luiz Carlos Ramos
2014-11-06 2:03 ` Andrew Duggan
2014-11-07 9:33 ` Luiz Carlos Ramos
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.