On Thu, Nov 25, 2010 at 03:05:30PM +0100, Henrik Rydberg wrote:
> Hi,
>
> Reading through this thread, I think Dmitry's EVIOCGDEVTYPE is a great way to
> resolve this. We should expect some changes in userland to correctly interpret
> direct/indirect devices, and this seems a good way to go. The physical size of
> the surface would also be great to retrieve this way. The recent resolution
> addition is semantically odd, since we have only one physical surface, not one
> per axes.
1 for each of 2 major axes, at least. We might need resolution for
pressure/distance as well, although it certainly won't be unit/mm ;)
>
> In short, my suggestion is to build a struct for device properties, like this:
>
> struct input_devinfo {
> __u32 type; /* bitmask of possible dev types */
> __u32 capabilities; /* bitmask of special device caps */
> __u32 phys_abs_width; /* physical width of surface (mm) */
> __u32 phys_abs_height; /* physical height of surface (mm) */
> };
>
> Adding more stuff here seems plausible. For instance, special devices like
> clickpads or integrated buttons would fit nicely in capabilities. The call would
> be very similar, like
>
> ioctl(fd, EVIOCGDEVINFO, &info);
>
Yep, should work, although the dimensions could be retrieved from
absinfo.
--
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
