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
