All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: Sean Young <sean@mess.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL for v5.18-rc1] media updates
Date: Wed, 25 May 2022 12:46:14 +0200	[thread overview]
Message-ID: <e17cab70-66cf-492a-fb8a-dca091768345@kernel.org> (raw)
In-Reply-To: <Yo3yfIim58IWf64z@gofer.mess.org>

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

      reply	other threads:[~2022-05-25 10:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22  9:14 [GIT PULL for v5.18-rc1] media updates Mauro Carvalho Chehab
2022-03-22  9:21 ` [GIT PULL for v5.18-rc1] media updates (#81961) Jenkins
2022-03-23 23:36 ` [GIT PULL for v5.18-rc1] media updates pr-tracker-bot
2022-05-25  6:42 ` Jiri Slaby
2022-05-25  6:44   ` lirc build broken [was: [GIT PULL for v5.18-rc1] media updates] Jiri Slaby
2022-05-25  8:57     ` Sean Young
2022-05-25  7:40   ` [GIT PULL for v5.18-rc1] media updates Sean Young
2022-05-25  8:09     ` Jiri Slaby
2022-05-25  8:49       ` Sean Young
2022-05-25  9:10       ` Sean Young
2022-05-25 10:46         ` Jiri Slaby [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e17cab70-66cf-492a-fb8a-dca091768345@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sean@mess.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.