Hi Sebastian, > Am 18.02.2017 um 04:22 schrieb Sebastian Reichel <sre@xxxxxxxxxx>: > > Hi, > > On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote: >>> AFAIK there is no mainline board using the DT except ours (and the upcoming >>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this >>> compatibility property. We don't need it for our devices. > > $ cd linux.git/arch > $ git grep -l tsc2004 > arm/boot/dts/imx6qdl-nit6xlite.dtsi > arm/boot/dts/imx7d-nitrogen7.dts > arm/boot/dts/logicpd-torpedo-37xx-devkit.dts > arm/boot/dts/omap4-var-som-om44.dtsi > $ git grep -l tsc2005 > arm/boot/dts/omap3-n900.dts Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't share code. Hence the N900 is not influenced by this patch series. If it has a similar issue, it should be fixed of course. > $ git grep -l tsc2007 > arm/boot/dts/imx28-tx28.dts > arm/boot/dts/imx35-eukrea-cpuimx35.dtsi > arm/boot/dts/imx51-eukrea-cpuimx51.dtsi > arm/boot/dts/imx53-tx53-x03x.dts > arm/boot/dts/imx6qdl-tx6.dtsi > arm/boot/dts/imx6ul-tx6ul.dtsi > arm/boot/dts/omap3-gta04.dtsi > sh/boards/mach-ecovec24/setup.c Sorry, I was a little imprecise here, because I looked for the min/max properties. Of course, the imx devices use the tsc2007 as well. Maybe we should edit all these DTS and set the "ti,report-resistance" property by default. Then, no user should notice a difference. Is any user/maintainer of these devices following this discussion and can comment? > >> You seem to be treating DT data as something very fluid, which is wrong. >> You need to treat it as a firmware, unlikely to change once device is >> shipped. Unlike legacy platform data, the fact that DTS files are not >> present in mainline does not mean that we can ignore such users and >> change behavior at will. >> >> That said, if driver behavior is out of line from the subsystem >> expectations, we need to fix it. >> >> >>> That the function name is wrong is a second issue and this double negation might >>> confuse a litte. >>> >>> Please test on a real device if the patched driver reports pressure now (unless >>> ti,report-resistance is specified). >> >> I unfortunately can not test this driver as I do not have the hardware. >> So all my observations are from code and data sheets. >> >> That said, what is the values emitted as ABS_PRESSURE when finger is not >> touching the device, barely touching the device, or pressing firmly? >> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have >> confusion as to what is being reported. > > As far as I can see all calculate Rtouch and ADS7846 reports > (Rmax - Rtouch), which looks sensible. I don't see where this subtraction from Rmax takes place for the tsc2007: http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131 > >> I am adding a few more folks to the CC so we can try and soft this out. >> Sebastian, Pali, Pavel, any input here? > > I think tsc200x works, since usually userspace is Xorg and I think > it only cares for x/y coordinates + boolean pressure. Since > no-pressure is correctly reported as 0, everything works as > expected. No pressure is usually treated as a special case in these drivers, so reduction to "boolean" in user-space works well by accident and might still hide a bug. > I currently don't have X running on my N900 due some > omapdrm bug, so I can't test this, sorry. I usually look with evtest if ABS_PRESSURE is monotonic. > > I suggest to put the resistance vs pressure thing in its own patch, > that also fixes tsc200x-core and merge it to linux-next after the > merge window. > > -- Sebastian BR and thanks, Nikolaus
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
