On 2015-05-20 10:19, Mauro Carvalho Chehab wrote:
Em Tue, 19 May 2015 22:34:42 +0200
David Härdeman <da...@hardeman.nu> escreveu:
On Thu, May 14, 2015 at 01:51:23PM -0300, Mauro Carvalho Chehab wrote:
>Em Thu, 19 Mar 2015 21:50:15 +0000
>Sean Young <s...@mess.org> escreveu:
>
>> Since the lirc bridge is not a decoder we can remove its protocol. The
>> keymap existed only to select the protocol.
>
>This changes the userspace interface, as now it is possible to enable/disable
>LIRC handling from a given IR via /proc interface.
I guess I meant to say: "as now it is not possible"
I still like the general idea though.
Yeah, LIRC is not actually a decoder, so it makes sense to have it
handled differently.
If we expose the protocol in the
set/get keymap ioctls, then we need to expose the protocol enum to
userspace (in which point it will be set in stone)...removing lirc
from
that list before we do that is a worthwhile cleanup IMHO (I have a
similar patch in my queue).
I think we should be able to at least not break userspace by still
accepting (and ignoring) commands to enable/disable lirc.
Well, ignoring is not a good idea, as it still breaks userspace, but
on a more evil way. If one is using this feature, we'll be receiving
bug reports and fixes for it.
I disagree it's more "evil" (or at least I fail to see how it would be).
Accepting but ignoring "lirc" means that the same commands as before
will still be accepted (so pre-existing userspace scripts won't have to
change which they would if we made "lirc" an invalid protocol to echo to
the sysfs file).
And saying that the change will "break" userspace is still something of
a misnomer. You'd basically expect userspace to open /sys/blabla, write
"-lirc" (which would disable the lirc output but the device node is
still in /dev), then later open /dev/lircX and be surprised that it's
still receiving lirc events on the lirc device it just opened? I think
that's a rather artificial scenario...
That lirc won't actually be disabled/enabled is (imho) a lesser
problem...is there any genuine use case for disabling lirc on a
per-device basis?
People do weird things sometimes. I won't doubt that someone would
be doing that.
In any case, keep supporting disabling LIRC is likely
simple, even if we don't map it internally as a protocol anymore.
I could write a different patch that removes the protocol enum but still
allows lirc to be disabled/enabled. I doubt it'll be that simple though
(ugly hack rather), and I still don't see the benefits of doing so (or
downsides or "breakage" of not doing it).
Another option would be to commit the change a see if anyone screams (I
very much doubt it).
--
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
