On Wed, May 20, 2015 at 09:16:32PM +0200, David Härdeman wrote:
>On Wed, May 20, 2015 at 11:06:06AM +0200, David Härdeman wrote:
>>On 2015-05-20 11:01, Mauro Carvalho Chehab wrote:
>>>Em Wed, 20 May 2015 10:49:34 +0200
>>>David Härdeman <da...@hardeman.nu> escreveu:
>>>
>>>>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:
>>>>>> 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).
>>>
>>>Because the Kernel would be lying to userspace. If one tells the Kernel to
>>>disable something, it should do it, or otherwise return an error explaining
>>>why disabling was not possible.
>>
>>Would really you be happier with a patch so that writing "-lirc" to the sysfs
>>file returns an error?
>
>Actually that would be very weird in case userspace writes e.g. "rc5" to
>the sysfs file (since that implies disabling lirc which would then
>return an error as well).
>
>So, that won't work. I still think just ignoring "+lirc" and "-lirc" is
>the best solution...(and the usecase you suggested of disabling lirc so
>that lircd won't get any events while an app reads only decoded
>events...seems very far-fetched)...do you have any other suggestion?
I've done some more checking.
Not changing protocols even though user-space asked for it is actually
already part of the rc-core API.
struct rc_dev contains:
int (*change_protocol)(struct rc_dev *dev, u64 *rc_type);
The reason rc_type is a pointer is that it is used to pass the requested
protocols to the change_protocol function and the function can then
update it to reflect what the actual result was.
Examples:
drivers/media/usb/em28xx/em28xx-input.c
drivers/media/rc/img-ir/img-ir-hw.c
Both of these drivers will pick *one* protocol to enable...so if you'd
write "+rc5 +nec" to their sysfs protocols file, it'd just enable one
protocol (and the file would read e.g. "[rc5] nec" afterwards).
With that in mind, userspace could never expect the list of enabled
protocols to match what it just wrote, even if no error was returned.
--
David Härdeman
--
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
