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@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
