On 11/27/2010 09:15 AM, Dmitry Torokhov wrote:
> 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 ;)
Alright, neither abstraction is perfect, but I agree the resolution has its
virtues. :-)
>>
>> 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.
>
I'll see if I can fit that (minus physical dimensions) into the upcoming patch sets.
Cheers,
Henrik
--
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
