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 <david@xxxxxxxxxxx> escreveu: >>> >>>>On 2015-05-20 10:19, Mauro Carvalho Chehab wrote: >>>>> Em Tue, 19 May 2015 22:34:42 +0200 >>>>> David Härdeman <david@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
