On Fri, Apr 28, 2017 at 08:31:33AM -0300, Mauro Carvalho Chehab wrote:
>Em Thu, 27 Apr 2017 22:34:23 +0200
>David Härdeman <da...@hardeman.nu> escreveu:
...
>> This patch changes how the "input_keymap_entry" struct is interpreted
>> by rc-core by casting it to "rc_keymap_entry":
>>
>> struct rc_scancode {
>> __u16 protocol;
>> __u16 reserved[3];
>> __u64 scancode;
>> }
>>
>> struct rc_keymap_entry {
>> __u8 flags;
>> __u8 len;
>> __u16 index;
>> __u32 keycode;
>> union {
>> struct rc_scancode rc;
>> __u8 raw[32];
>> };
>> };
>>
...
>
>Nack.
That's not a very constructive approach. If you have a better approach
in mind I'm all ears. Because you're surely not suggesting that we stay
with the current protocol-less approach forever?
>No userspace breakages are allowed.
That's a gross oversimplification. A cursory glance at the linux-api
mailing list shows plenty of examples of changes that might not be 100%
backwards-compatible. Here's an example:
http://marc.info/?l=linux-fsdevel&m=149089166918069
That's the kind of discussion we need to have - i.e. the best way to go
about this and to minimize the damage to userspace. In that vein, I'll
post an alternative approach shortly as the basis for further
discussion.
>There's no way to warrant that
>ir-keytable version is compatible with a certain Kernel version.
I know. But we know when an ioctl() is made whether it is a
protocol-aware one or not.
--
David Härdeman
