Re: [RFC][PATCH] input: Introduce device information ioctl

[Dmitry Torokhov]

On Tue, Dec 07, 2010 at 08:57:14PM +0100, Henrik Rydberg wrote:
> On 12/07/2010 10:16 AM, Dmitry Torokhov wrote:
> 
> > Hi Henrik,
> > 
> > On Tue, Dec 07, 2010 at 08:25:26AM +0100, Henrik Rydberg wrote:
> >> Today, userspace sets up an input device based on the data it emits.
> >> This is not always enough; a tablet and a touchscreen may emit exactly
> >> the same data, for instance, but the former should be set up with a
> >> pointer whereas the latter does not need to. Recently, a new type of
> >> touchpad has emerged where the buttons are under the pad, which changes
> >> handling logic without changing the emitted data. This patch introduces
> >> a new ioctl, EVIOCGDEVINFO, which allows userspace to extract information
> >> about the device resulting in proper setup.
> > 
> > If we agree that the new ioctl is suitable we'llalso need to wireit up
> > through sysfs. Also, can we keep all definitions to INPUT_ namespace?
> > 
> > Thanks.
> > 
> 
> 
> Thanks all for the comments, this is what I extract from them:
> 
> * Split struct into separate calls, although this still seems debated.
> 
> * Use INPUT_ namespace
> 
> * Add sysfs version
> 
> * Keep bitmask for types. Is the list of types complete?

Most likely not but it can be easily extended on as-needed basis.

> 
> * Still only one data point for capabilities. Anything else?

Again, no need to define everything upfront.

One concern is that while 32 distinct device types should be enough
should we plan for larger capability array? Should we use variable
length ioctl - like EVIOCGKEY(len) - even though Arnd does not like
them?

Also, we already have /sys/class/input/input0/capabilities/ so should we
call new data item something else? Quirks maybe?

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/