On Wed, Aug 17, 2011 at 11:53:55AM +0200, Éric Piel wrote: > Op 17-08-11 08:43, Dmitry Torokhov schreef: > >Hi JJ, > > > >>As far as I know, this doesn't fix a bug. I just want to make sure the > >>driver and what the firmware sends are consistent. > > > >As Éric mentioned, simply extending range to 12 bits is dangerous > >because we might cause overflows. Blindly increasing ETP_YMAX_V2 is not > >a good idea either as userspace would expect much larger device and > >reports would only cover fraction of its surface. We need to separate > >ETP_YMAX_V2 as absolute maximum from reported coordinates range, like it > >is done in synaptics driver. > Hi Dmitry, > Concerning this point, I was wondering if it'd be ok to only send > negative values? Such as min/max are between -768 and 0. So that, if > the hardware actually has a bigger resolution, it can go down to > -4095 without any overflow? Theoretically it should be possible, at least nothing in evdev protocol says that absolute coordinates shoudl be positive. It is certainly not true for joystick-like devvices. But I am concerned about users (as in applications/drivers) getting negative coordinates for touchpad/touchscreen like devices. I believe first reaction is to expect non-negative values. > It sounds the simplest way to report the > coordinate for a device which has an opposite axis. Or is it safer > to stay in the positive numbers, with min/max between 3328 and 4095, > and in case of bigger resolution the values go down to 0? I think this is the best way. EVIOCGABS gives the "window" into the expected range of coordinates emitted by the device, so as long as we keep the scale (i.e. not reporting min/max as 0-4096 while actual coordinates go only 0-768) it should work fine. -- Dmitry -- 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
