Mauro Carvalho Chehab wrote:
> In summary,
>
> While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up to 16
> bytes
> (since a read loop for 2^16 is not that expensive), the current approach
> won't scale with bigger scancode spaces. So, it is needed expand it
> to work with bigger scancode spaces, used by more recent IR protocols.
>
> I'm afraid that any tricks we may try to go around the current limits to still
> keep using the same ioctl definition will sooner or later cause big headaches.
> The better is to redesign it to allow using different scancode spaces.
>
>
>
I second you: input layer events from drivers should be augmented with a
protocol member, allowing us to define new ioctl and new ways to
efficiently store and manage sparse scancode spaces (tree, hashtable
....). It will allow us to abstract the scancode value and to use
variable length scancode depending on the used protocol, and using the
most appropriate scheme to store the scancode/keycode mapping per protocol.
The today scancode space will be the legacy one, the default if not
specified "protocol". It will permit to progressively clean up the
actual acceptable mess in the input layer and finally using real
scancode -> keycode mappings everywhere if it is cleaner/convenient.
Best regards,
Emmanuel.
On Mon, Dec 07, 2009 at 06:54:39PM +0100, Emmanuel Fust? wrote:
> Mauro Carvalho Chehab wrote:
>
>> In summary,
>>
>> While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up
>> to 16 bytes
>> (since a read loop for 2^16 is not that expensive), the current approach
>> won't scale with bigger scancode spaces. So, it is needed expand it
>> to work with bigger scancode spaces, used by more recent IR protocols.
>>
>> I'm afraid that any tricks we may try to go around the current limits to still
>> keep using the same ioctl definition will sooner or later cause big headaches.
>> The better is to redesign it to allow using different scancode spaces.
>>
>>
>>
> I second you: input layer events from drivers should be augmented with a
> protocol member, allowing us to define new ioctl and new ways to
> efficiently store and manage sparse scancode spaces (tree, hashtable
> ....).
Userspace has no business knowing how driver maps hardware data stream
into a keycode, only what is being mapped to what. The way is is done
can change from driver-to-driver, from release to release. If I come up
with an super-smart or super-stupid way of storing key mapping I won't
want to modify userpsace tools to support it.
> It will allow us to abstract the scancode value and to use
> variable length scancode depending on the used protocol, and using the
> most appropriate scheme to store the scancode/keycode mapping per protocol.
> The today scancode space will be the legacy one, the default if not
> specified "protocol". It will permit to progressively clean up the
> actual acceptable mess in the input layer and finally using real
> scancode -> keycode mappings everywhere if it is cleaner/convenient.
>
I am unable to parse this part, sorry.
--
Dmitry
Dmitry Torokhov a ?crit :
> On Mon, Dec 07, 2009 at 06:54:39PM +0100, Emmanuel Fust? wrote:
>
>> Mauro Carvalho Chehab wrote:
>>
>>
>>> In summary,
>>>
>>> While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up
>>> to 16 bytes
>>> (since a read loop for 2^16 is not that expensive), the current approach
>>> won't scale with bigger scancode spaces. So, it is needed expand it
>>> to work with bigger scancode spaces, used by more recent IR protocols.
>>>
>>> I'm afraid that any tricks we may try to go around the current limits to still
>>> keep using the same ioctl definition will sooner or later cause big headaches.
>>> The better is to redesign it to allow using different scancode spaces.
>>>
>>>
>>>
>>>
>> I second you: input layer events from drivers should be augmented with a
>> protocol member, allowing us to define new ioctl and new ways to
>> efficiently store and manage sparse scancode spaces (tree, hashtable
>> ....).
>>
>
> Userspace has no business knowing how driver maps hardware data stream
> into a keycode, only what is being mapped to what. The way is is done
> can change from driver-to-driver, from release to release. If I come up
> with an super-smart or super-stupid way of storing key mapping I won't
> want to modify userpsace tools to support it.
>
>
But this is the point for IR. Userspace need a stable and "universal"
driver to driver way to represent the hardware data stream. This is
needed for only one but very important application: creating and
modifying exchangeable remote mappings.
The way of storing in kernel key mapping should not have any impacts on
usersapce tools. If this is the case, this is because the actual ioctl
is too tied to the way these mapping are stored. These need to changed
or be expanded for IR.
>> It will allow us to abstract the scancode value and to use
>> variable length scancode depending on the used protocol, and using the
>> most appropriate scheme to store the scancode/keycode mapping per protocol.
>> The today scancode space will be the legacy one, the default if not
>> specified "protocol". It will permit to progressively clean up the
>> actual acceptable mess in the input layer and finally using real
>> scancode -> keycode mappings everywhere if it is cleaner/convenient.
>>
>>
>
> I am unable to parse this part, sorry.
>
>
My bad, my English is awful, sorry. :-(
Best regards,
Emmanuel.