[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e17cab70-66cf-492a-fb8a-dca091768345@kernel.org>
Date: Wed, 25 May 2022 12:46:14 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Sean Young <sean@...s.org>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL for v5.18-rc1] media updates
On 25. 05. 22, 11:10, Sean Young wrote:
> On Wed, May 25, 2022 at 10:09:38AM +0200, Jiri Slaby wrote:
>> I don't understand how inability to build software is not an uapi breakage
>> -- care to elaborate?
>
> So here is a good compromise suggested by Mauro.
>
> 1. We add the following to the lirc.h uapi header.
>
> #define LIRC_CAN_NOTIFY_DECODE 0
> #define LIRC_CAN_SET_REC_FILTER 0
The code would do "if (x & 0)" or alike, so I'm not sure this won't
result in a warning. But as soon as that thing compiles, I don't really
care much. If it produces no warning, in fact, the code could be
optimized away out thanks to "& 0".
Just looked up those defs in the debian code search, only lirc and
v4l-utils care about the defines. ANd the latter seems to define their
own copies.
> 2. Since lirc daemon is unmaintained, I am happy to take on maintainership.
>
> This may require forking, depending on what the maintainer says.
>
> How does that sound?
Great.
thanks,
--
js
suse labs
Powered by blists - more mailing lists