Re: v4.1 to v4.7: regression in tsc2005 driver

[Peter Hutterer]

On Wed, Jul 20, 2016 at 03:20:02PM -0700, Dmitry Torokhov wrote:
> On Thu, Jul 21, 2016 at 07:47:36AM +1000, Peter Hutterer wrote:
> > On Wed, Jul 20, 2016 at 09:23:56AM -0700, Dmitry Torokhov wrote:
> > > On Wed, Jul 20, 2016 at 08:25:58AM +0200, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > > > > > > > > drivers/input/touchscreen/tsc2005.c:	  input_dev->name = "TSC2005
> > > > > > > > > > > touchscreen";
> > > > > > > > > > > 
> > > > > > > > > > > to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> > > > > > > > > > > name to userspace, where it is needed to be able to do
> > > > > 
> > > > > Technically X _is_ userspace.
> > > > 
> > > > There's "userspace running as root" and "userspace userspace" :-).
> > > 
> > > I do not really see any difference form the kernel POW. 
> > > 
> > > > 
> > > > > > > > > > > 
> > > > > > > > > > > xinput --set-prop --type=int ...
> > > > > > > > > > > 
> > > > > > > > > > > with the right arguments to calibrate touchscreen. (Touchscreen is
> > > > > > > > > > > unusable without calibration).
> > > > > > > > > > > 
> > > > > > > > > > > What to do with that?
> > > > > 
> > > > > Hmm, I do not think we ever committed for the device names to be stable.
> > > > > You are supposed to locate touchscreen device based on its properties
> > > > > and you might need some heuristic if you encounter a system with more
> > > > > than one such touchscreen.
> > > > 
> > > > Well, you are commited now, like it or not, X people did it for you
> > > > :-(.
> > > > 
> > > > Because there's no other reasonable way to use xinput --set-prop...
> > > 
> > > Well, X is going to have to fix it. How am I supposed to control my
> > > devices in multi-seat environment if I use the same hardware (or if I
> > > have device with multiple touchscreens)? They all will have the same
> > > name (well, all mice, then all keyboards, etc). Let's add Peter to the
> > > fold...
> > > 
> > > In the mean time you can adjust the name or use XID instead.
> > 
> > X has partially fixed this a few years ago. All input drivers (that
> > matter) export a Device Node property that sets the device node for each
> > device.
> > 
> >  $ xinput list-props "SynPS/2 Synaptics TouchPad" | grep "Device Node"
> >         Device Node (261):      "/dev/input/event4"
> > 
> > Based on that you can get the udev device and work your way into any of the
> > sysfs tree. Or do whatever else you want.
> 
> The issue is not that I can't figure out sysfs path for a device, the
> issue is that xinput does not accept anything but name or XID and I may
> have multiple devices with the same name in the system.

fwiw, the main reason why I don't want this in xinput is that anything
sysfs related (or elsewhere) is platform specific. On BSD the Device
Node isn't an evdev node and other efforts are required. xinput is an X tool
itself and I don't want non-X functionality in it because you'll quickly
unleash pandora's box here about stuffing custom features in that only apply
to a tiny fraction of setups.

even the case where you have more than one device with the same name is
quite unusal (note: we do support a "pointer:" and "keyboard:" prefix for
those where a device has a pointer and a keyboard device with the same
name like many of the mouse/keyboard combos do).

> > But other than that there isn't anything in X to fix. xinput is primarily a
> > debugging tool and it does name resolution for convenience. But it's not a
> > tool for complex configurations. It does exactly what it needs to do, if you
> 
> OK, I do not believe that this information was conveyed clearly enough.
> Apparently some setups use it for real configuration.

yeah. I've been saying "get your DE to implement support" for 7-8 years
now but saying things and being listened too are two different entities :)
xinput's main problem is that it works for the majority of use-cases, so
people use it. That's largely fine for most cases, but not when it comes to
anything even remotely sophisticated.

Cheers,
   Peter

 
> > need something that's more complicated and relies on information not
> > available to the X device itself then you'll need to write a custom tool
> > that does what you need. sorry.
> 
> Pavel, ^^^^
> 
> 
> Thanks.
> 
> -- 
> Dmitry