On Wed, Nov 5, 2014 at 3:09 PM, Luiz Carlos Ramos <lramos.prof@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
