Re: [GIT PULL for v5.18-rc1] media updates

[Jiri Slaby <jirislaby@kernel.org>]

On 25. 05. 22, 9:40, Sean Young wrote:
> Hi,
> 
> On Wed, May 25, 2022 at 08:42:26AM +0200, Jiri Slaby wrote:
>> On 22. 03. 22, 10:14, Mauro Carvalho Chehab wrote:
>>> Hi Linus,
>>>
>>> Please pull from:
>>>     git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.18-1
>> ...
>>> Sean Young (10):
>> ...
>>>         media: lirc: remove unused lirc features
>>
>> Hi,
>>
>> this breaks lirc build:
>>> [   59s] lircd.cpp:489:49: error: 'LIRC_CAN_SET_REC_FILTER' was not declared in this scope; did you mean 'LIRC_CAN_SET_REC_CARRIER'?
>>> [   59s]   489 |                     || (curr_driver->features & LIRC_CAN_SET_REC_FILTER)) {
>>> [   59s]       |                                                 ^~~~~~~~~~~~~~~~~~~~~~~
>>> [   59s]       |                                                 LIRC_CAN_SET_REC_CARRIER
>>> [   59s] lircd.cpp: In function 'void loop()':
>>> [   59s] lircd.cpp:2069:82: error: 'LIRC_CAN_NOTIFY_DECODE' was not declared in this scope; did you mean 'DRVCTL_NOTIFY_DECODE'?
>>> [   59s]  2069 |                         if (curr_driver->drvctl_func && (curr_driver->features & LIRC_CAN_NOTIFY_DECODE))
>>> [   59s]       |                                                                                  ^~~~~~~~~~~~~~~~~~~~~~
>>> [   59s]       |                                                                                  DRVCTL_NOTIFY_DECODE
>>
>> So the uapi header defines should be brought back, IMO.
> 
> The lirc.h uapi defines the lirc chardev uapi. The uapi has not changed in
> any way, for old or new kernels.
> 
> So the lirc header used to have feature flags LIRC_CAN_SET_REC_FILTER and
> LIRC_CAN_NOTIFY_DECODE which were defined the in the lirc.h header, but
> never implemented by any out of tree or in tree driver.
> 
> Neither feature was or will be ever implemented in the kernel;
> LIRC_CAN_NOTIFY_DECODE is handled via the led subsytem, and it is unknown
> what LIRC_CAN_SET_REC_FILTER is even supposed to mean. Again, I have not
> found any implementation anywhere.
> 
> You are trying to build lirc user space daemon which is no longer maintained.
> The last time the lirc daemon git repo had any commits was in 2019. User
> space tooling has been replaced with daemon-less ir-ctl and ir-keytable,
> which uses BPF for IR decoding.
> 
> The right fix is to simply delete the offending lines in lircd.cpp and all
> will be well. Sometimes source code needs a little maintainence.
> 
> These changes in the lirc uapi do not change the uapi in any way, just the
> ability the build some unmaintained software without trivial changes.

Hi,

I don't understand how inability to build software is not an uapi 
breakage -- care to elaborate?

Be it umaintained or not, it's still in distributions (the above is from 
opensuse build system) and it is broken now. Every single distributor 
now would have to go and fix this.

So either you fix it (e.g. re-add only the entries as I suggested) or I 
will post a revert of your patch. Sorry, no excuses.

thanks,
-- 
js
suse labs