linux-kernel - Re: [RFC 5/7] [media] ir-lirc-codec: do not handle any buffer for raw transmitters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Jul 2016 15:43:13 +0100
From:	Sean Young <sean@...s.org>
To:	Andi Shyti <andi.shyti@...sung.com>
Cc:	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andi Shyti <andi@...zian.org>
Subject: Re: [RFC 5/7] [media] ir-lirc-codec: do not handle any buffer for
 raw transmitters

Hi Andi,

On Thu, Jul 21, 2016 at 09:48:12AM +0900, Andi Shyti wrote:
> > > Raw transmitters receive the data which need to be sent to
> > > receivers from userspace as stream of bits, they don't require
> > > any handling from the lirc framework.
> > 
> > No drivers of type RC_DRIVER_IR_RAW_TX should handle tx just like any
> > other device, so data should be provided as an array of u32 alternating
> > pulse-space. If your device does not handle input like that then convert
> > it into that format in the driver. Every other driver has to do some
> > sort of conversion of that kind.
> 
> I don't see anything wrong here, that's how it works for example
> in Tizen or in Android for the boards I'm on: userspace sends a
> stream of bits that are then submitted to the IR as they are.

This introduces a new, incompatible api with no way of detecting it.

It's not a good format. For example the leading pulse (9ms) for nec ir
with a carrier of 38000 will be 342 bits. With the pulse-space format
it will be 32 bits.

Doing the conversion in kernel space will be cheap.

> If I change it to only pulse-space domain, then I wouldn't
> provide support for those platforms. Eventually I can add a new
> protocol.

But this is forcing an new, incompatible api onto the rest of us. 

This is the code in tizen:

https://build.tizen.org/package/rdiff?linkrev=base&package=device-manager-plugin-exynos5433&project=Tizen%3AIVI&rev=2

If this patch was merged as-is tizen would have to be changed anyway
to use different ioctls. If that is true, can it switch to use 
pulse-space format in the same change? If LIRC_GET_FREQUENCY fails then
it would be a main-line kernel, else the existent driver.

I could not find the code in android. It might be useful to see so we
can find a solution that works for everyone.

Sean