- User Since
- Jun 3 2017, 8:47 AM (119 w, 1 d)
Thu, Sep 12
Mon, Sep 9
Fri, Aug 23
iichid device is a child of acpi bus also, so it can be rephrased as "how to get the acpi stuff to automatically add acpi device with given CID"
(3) How to cope with resume and resets not being quite right for the ig4.
It is not clear which reset is mentioned:
- IG4 controller reset (set designware specific parameters like timing counters and so on)
- iicbus reset - FIFO flushing, setting of symbol speed and slave address
- I2C hid device reset - performed with special I2C command
If it is mentioned in context of @johalun suspend/resume patch, then most probably it misses iicbus reset as it is performed by ig4 driver in a lazy way at a start of next xfer. sc->slave_valid bool variable should be reset to trigger it and I do not see that in @johalun resume method.
Would we make better progress with we split those three issues up into their own reviews?
Sun, Aug 18
Aug 14 2019
Finally, I made separate small kernel module ng_ubt_intel which shares object file with ng_ubt.
It inherits device methods from ng_ubt while overriding it's probe() method.
That allows move vendor-specific code out of ng_ubt and avoid code duplication the same time.
Firmware is still downloaded with libusb as I don't see any benefits from moving one-shot driver to kernelspace.
Aug 12 2019
I wrote iicbus(4) extension which performs ACPI-based enumeration of I2C devices connected to a controller. It is not limited to HID devices and fires at iicbus attach stage.
Jul 30 2019
Jul 29 2019
Jul 28 2019
Jul 27 2019
Jul 25 2019
Jul 22 2019
I enabled debugging output in imt.c so please:
Jul 21 2019
I fixed one bug, so try one more time
it generates nothing with libinput debug-events, and no events in xev.
libinput debug-events is not the right tool to debug evdev. evemu-record from devel/evemu port is better
That is expected as it ignored any touchpads
Jul 19 2019
just unpack it at your $HOME. Than
make && sudo kldload ./iichid.ko
leaving all other modules built from the source of this thread?
drivers from this review should be at least unloaded from kernel. There is no need to revert D16698 patch. Just don't try to kldload both modules in between reboots.
Should I remove evdev support from the kernel?
No need. It links with evdev unconditionally
Can you please share your xorg configuration?
I do not have any specific xorg.conf options. Any evdev-awared autoconfiguration backend should work out of box. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 for example.
Jul 18 2019
OS driver or userland applications just do not have enough information as finger coords or count to support doublefinger scroll or multifinger taps.
I wrote a simple util to dump report descriptor from I2C HID device.
It accepts 3 input parameters: iic device path, i2c bus address and i2c HID register and prints report descriptor of given I2C device on stdout. This report descriptor can be further analyzed with any tool (e.g. web-based http://eleccelerator.com/usbdescreqparser/) to examine HID device capabilities.
Jul 8 2019
I don't object to acpi_iichid module existence. It just adds an extra requirements for module load order which I was not able to solve quickly.
I think it would be best to try and base the ims driver on top of your code. Are you interested in trying to integrate them?
Yes, I am going to submit this code to the project when it will be ready, so it is better to have it insync with ims
I wrote a driver for I2C MT touchscreens https://github.com/wulf7/iichid which is heavily based on the code in this review.
It does not require dedicated ACPI module at all and has some I2C/HID layers separation which is missed in current review.
So I think it may have sense to join efforts and codebases
Jun 29 2019
Jun 8 2019
Jun 5 2019
Synaptics and Elantech probe() does not depend on loader tuneables at all. Magic knock and capability queries are always performed regardless of kernel boot parameters so it cannot be called "too intrusive".
But IBM trackpoint probe() is different thing. It is performed in different ways depending on 'synaptics_support' variable value.
Browsing through the commit log shows me that there were several patches submitted by you to fix various trackpoint issues circa 2015 so it's worth trying to enable it by default again as support of this device is definitely changed since 2013.
Jun 4 2019
I doubt it can produce side effects. Albeit psm packet parser is replaced with Xorg`s one, PS/2 device recognition is still relies on in-kernel probe() function. So Xorg can not handle any PS/2 devices unknown to base system.
I think this is the solution to adopt: if we want touchpads to work out of the box, we can not ask users to start moused before xorg. Of course, they can add moused_enable="YES" to their rc.conf, but if we can make a small change to the xf86-input-mouse port it looks much easier: it affects only users of xorg and avoids to run a daemon on the system.
Better solution is to run moused from devd exactly like it is done for ums(4), but it does not work for me now.
After some digging it appeared that xf86-input-mouse unconditionally enables so called "native operation level" being attached to /dev/psm0 device node. It means that it effectively replaces our kernel driver with his own PS/2 packet parser.
So we have 2 choices:
- Forbid enabling of "native operation level" in xf86-input-mouse driver. It looks like commenting out one #define line
- Force all touchpad users to run moused to grab /dev/psm0 device and reroute its packets via /dev/sysmouse before Xorg is started.
Jun 3 2019
Count this "accept" as "commit approval"
Given the fact that horizontal scrolling with sysmouse protocol is not supported by userland software out of boх, I joined both hor & ver sysctls into common "natural_scroll" one to not confuse users.
Jun 2 2019
Jun 1 2019
One more question:
May 29 2019
May 28 2019
Could you upload the diff as fullcontext diff next time. See https://wiki.freebsd.org/Phabricator
git diff -U999999 other-branch > change.diff git show -U999999 <commit-hash> > change.diff svn diff --diff-cmd=diff -x -U999999 > change.diff`
It is not necessary to reupload current diff
Apr 20 2019
Mar 27 2019
Mar 11 2019
Mar 10 2019
Feb 25 2019
Feb 24 2019
Feb 15 2019
I hope you won't mind if I change sysctl name from "input_id" to "id" and disable exposure of optional properties like "uniq" and "phys" if they are not set. Just to be consistent with ioctl interface.
Feb 10 2019
Jan 22 2019
Jan 21 2019
One thing I dislike in this patch is a native/cuse evdev handling inconsistency.
To handle native device creation one should listen for EVDEV devd events while to handle cuse devices CDEV devd events should be processed.
You can not just listen for CDEV devd events as there is a race window between cdev and sysctl creation.
I think this can be fixed with using of single sysctl node. See kern.geom.confxml or kern.geom.conftxt for example.
Jan 18 2019
Jan 9 2019
linux/input.h is a list of magic numbers required at build time only. It should be kept in BUILD_DEPENDS IMO.
Jan 6 2019
I am AFK for now and will be for ~2 weeks
Dec 31 2018
I am objecting to EvdevProbe()-derived part (device type autodetection). It is better to add a KPI to set device type directly rather then via execution of libmagic. We have about 10 evdev drivers in source tree so it's possible to update them all. EvdevProbe()-derived part could be used as (deprecated) fallback option in that case.
Dec 30 2018
I hope -1700 value is tested. It does not work for my "softbuttons bar at a bottom" laptop leaving softbutton area outside reportable region so I have to use -2200 to make it working. But "softbuttons bar at a top" touchpad should behave differently here.
Dec 29 2018
Please assign hw.psm.synaptics.softbuttons_y sysctl some negative value so /dev/psm0 users get benefits from this change too.
Nov 25 2018
Nov 24 2018
Nov 17 2018
Nov 10 2018
Nov 9 2018
I am unaware of any current ill effects
Oct 31 2018
D17687 committed as r339917 made remaining parts of this revision senseless.