Re: IR raw input is not sutable for input system

On Wed, Nov 25, 2009 at 01:32:51AM +0200, Maxim Levitsky wrote:
Folks, I really want to tell everyone that doing all the mapping from
raw codes to keypresses in kernel is wrong.

Why is this wrong? Doing simple translation is easy and it does not
require having all the tables for all possible remotes in the kernel. We
have appropriate interfaces to load keymaps at runtime (for the devices
whose drivers support this feature).

This idea keeps showing up, because many users think that remotes send
some universal codes that you can just 'parse' and feed back to input
system.


Well, they send some data that can be parsed and thus fed to whatever we
want to feed it.


Its not the case.
There are many protocols, I know that by experimenting with my universal
remote. There are many receivers, and all have different accuracy.
Most remotes aren't designed to be used with PC, thus user has to invent
mapping between buttons and actions.
Its is not possible to identify remotes accurately, many remotes send
just a 8 bit integer that specifies the 'model' thus many remotes can
share it.
Some don't send anything.

There are some weird remotes that send whole packet of data will all
kind of states.

Think about it, video capture device is also an input device, a scanner
is an input device too, sound card can work as input device too.

You are stretching. There are no button presses involved with sound (not
unless you go all the way down to keys on a piano ;) )

But we aren't doing any parsing, even we don't support deflating of many
proprietary and standard video/image encoding formats.
We let userspace do it.

Kernel job is to take the information from device and present it to
userspace using uniform format, that is kernel does 1:1 translating, but
doesn't parse the data.

Should we return to the times where we had raw PS/2 data streams sent to
userspace, separately from HID and other formats? I don't think it is a
good idea.

Uniform format doesn't mean kernel always converts to one format, its
not like sound card always recording in 32 bit 96000 Khz format, even if
underlying device doesn't support that.


So, device that decode IR code are presented to userspace as pure input
devices. I agree that creating fake raw codes from that is bad.

But devices that send raw data pass it to lirc.
lirc is well capable to decode it, and its not hard to add
auto-detection based on existing configuration drivers, so IR devices
will work with absolutely no configuration.
All you will have to do is ensure that lirc is installed.
Then udev can even start it automatically.
Then as soon as you press a key, lirc can scan its config database, and
find a config file to use. combine that with a GUI for unknown remotes
and you get an awesome usability.


Why can't the same be done in kernalspace though?

Also don't forget that there are pure userspace drivers. They won't have
access to in-kernel decoder so they will still have to parse protocols,
so will have code duplication, and will still need lirc thus.


So why to burden the kernel with protocols, etc..

We do burden it with TCP, shall we take it out?

--
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/

Relevant Pages

  • IR raw input is not sutable for input system
    ... raw codes to keypresses in kernel is wrong. ... Most remotes aren't designed to be used with PC, ... Kernel job is to take the information from device and present it to ... But devices that send raw data pass it to lirc. ...
    (Linux-Kernel)
  • Re: [RFC v2] Another approach to IR
    ... KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent ... On those remotes, if you press TV and then press for example Channel UP ... to implement Jon's filter idea of splitting one evdev interface into ...
    (Linux-Kernel)
  • Re: [PATCH 1/2] ftrace: make dynamic ftrace more robust
    ... but maybe we should just use the standard kernel return codes. ... warning so a kernel developer can debug it. ... there's no justification given for this in the changelog and the change ...
    (Linux-Kernel)
  • Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
    ... API already in the kernel. ... subsystem' for IR. ... Whilst having remotes come through the input subsystem might be 'the correct ... whereas remotes are often controlling ...
    (Linux-Kernel)
  • Re: In-kernel IR remote control support
    ... Decoding IR protocols in-kernel is the wrong way IMHO and this will not be ... With the in-kernel decoding approach these remotes cannot be ... I'm not willing to sacrifice the support for these even though ... Can we merge the common ones into the kernel, ...
    (Linux-Kernel)