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