On Wed, Dec 20, 2023 at 02:39:14PM +0100, Paul Cercueil wrote: > Hi Dmitry, > > Le mardi 19 décembre 2023 à 17:53 -0800, Dmitry Torokhov a écrit : > > Hi Paul, > > > > On Wed, Dec 20, 2023 at 01:38:39AM +0100, Paul Cercueil wrote: > > > Hi Peter, > > > > > > Le mercredi 20 décembre 2023 à 09:51 +1000, Peter Hutterer a > > > écrit : > > > > On Mon, Dec 18, 2023 at 11:16:53AM -0600, Chris Morgan wrote: > > > > > From: Chris Morgan <macromorgan@xxxxxxxxxxx> > > > > > > > > > > Stop checking if the minimum abs value is greater than the > > > > > maximum > > > > > abs > > > > > value. When the axis is inverted this condition is allowed. > > > > > Without > > > > > relaxing this check, it is not possible to use uinput on > > > > > devices in > > > > > userspace with an inverted axis, such as the adc-joystick found > > > > > on > > > > > many handheld gaming devices. > > > > > > > > As mentioned in the other thread [1] a fair bit of userspace > > > > relies > > > > on > > > > that general assumption so removing it will likely cause all > > > > sorts of > > > > issues. > > > > > > There is some userspace that works with it though, so why restrict > > > it > > > artificially? > > > > > > The fact that some other userspace code wouldn't work with it > > > sounds a > > > bit irrelevant. They just never encountered that min>max usage > > > before. > > > > > > And removing this check won't cause all sort of issues, why would > > > it? > > > It's not like the current software actively probes min>max and > > > crash > > > badly if it doesn't return -EINVAL... > > > > It will cause weird movements because calculations expect min be the > > minimum, and max the maximum, and not encode left/right or up/down. > > Putting this into adc joystick binding was a mistake. > > I don't see why it was a mistake, it's only one of the ways to specify > that the axis is inverted. This information is between the firmware > (DT) and the kernel, that doesn't mean the information has to be > relayed as-is to the userspace. > > Unlike what you wrote in your other answer, when talking about input > the kernel doesn't really normalize anything - it gives you the min/max > values, and the raw samples, not normalized samples (they don't get > translated to a pre-specified range, or even clamped). > > I don't really like the idea of having the driver tamper with the > samples, but if the specification really is that max>min, then it would > be up to evdev/joydev (if the individual drivers are allowed min>max) > or adc-joystick (if they are not) to process the samples. > > Cheers, > -Paul Forgive me for such a naive question, but what would it take to get a bool of `inverted` added to the struct input_absinfo, and then an ioctl to get the inverted status? I'm honestly not sure of the ramifications of what this may do to userspace (good/bad/ugly?) >From what I am seeing thus far it sounds like we should not be setting the values as inverted for now because it can cause problems. We can either fix this in the adc-joystick driver, or my honest preference is to just set the range as defined as min < max and add a comment stating that the axis is inverted. If we can't handle reversed values throughout the stack I don't see any reason to handle it special just for the adc-joystick driver. Thank you, Chris > > > This is the definition of absinfo: > > > > /** > > * struct input_absinfo - used by EVIOCGABS/EVIOCSABS ioctls > > * @value: latest reported value for the axis. > > * @minimum: specifies minimum value for the axis. > > * @maximum: specifies maximum value for the axis. > > * @fuzz: specifies fuzz value that is used to filter noise from > > * the event stream. > > * @flat: values that are within this value will be discarded by > > * joydev interface and reported as 0 instead. > > * @resolution: specifies resolution for the values reported for > > * the axis. > > * > > * Note that input core does not clamp reported values to the > > * [minimum, maximum] limits, such task is left to userspace. > > ... > > */ > > > > (We should change wording of the last sentence to "... does not > > always > > clamp ..." since when we do inversion/swap we do clamp values.) > > > > And note that the userspace that can handle swapped min and max will > > work fine if the kernel provides normalized data, but other software > > will/may not work. > > > > Thanks. > > >
