On 2015-05-20 11:08, Mauro Carvalho Chehab wrote:
Em Wed, 20 May 2015 10:53:59 +0200
David Härdeman <da...@hardeman.nu> escreveu:
On 2015-03-19 22:50, Sean Young wrote:
> The send mode has to be switched to LIRC_MODE_SCANCODE and then you can
> send one scancode with a write. The encoding is the same as for
> receiving
> scancodes.
Why do the encoding in-kernel when it can be done in userspace?
I'd understand if it was hardware that accepted a scancode as input,
but
that doesn't seem to be the case?
IMO, that makes the interface clearer. Also, the encoding code is
needed
anyway, as it is needed to setup the wake up keycode on some hardware.
So, we already added encoder capabilities at some decoders:
I know.
But with the proposed API userspace would have to first try to send a
scancode + protocol, then see what the error code was, and if it
indicated that the kernel couldn't encode the scancode, userspace would
anyway have to encode it itself and then try again with raw events?
I think that's a bad API (to put it mildly).
There's simply no need to encode the scancodes in kernel (even if the
code happens to be present for a random and fluctuating set of
protocols) and any well-written userspace would have to include code to
encode to any protocol it wants to support (since it can't rely on the
kernel supporting any given protocol)....what does that buy you except a
hairy API and added complexity?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
