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]
Message-ID: <20161230133030.GA7861@gofer.mess.org>
Date:   Fri, 30 Dec 2016 13:30:30 +0000
From:   Sean Young <sean@...s.org>
To:     Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
Cc:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        Timo Kokkonen <timo.t.kokkonen@....fi>,
        Pavel Machek <pavel@....cz>,
        Pali Rohár <pali.rohar@...il.com>
Subject: Re: [PATCH 1/5] [media] ir-rx51: port to rc-core


On Fri, Dec 30, 2016 at 01:07:52PM +0000, Sean Young wrote:
> Hi Ivo,,
> 
> On Fri, Dec 30, 2016 at 01:30:01PM +0200, Ivaylo Dimitrov wrote:
> > On 20.12.2016 19:50, Sean Young wrote:
> > >This driver was written using lirc since rc-core did not support
> > >transmitter-only hardware at that time. Now that it does, port
> > >this driver.
> > >
> > >Compile tested only.
> > >
> > 
> > I guess after that change, there will be no more /dev/lircN device, right?
> > Neither will LIRC_XXX IOCTL codes be supported?
> 
> Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be
> supported through ir-lirc-codec.c.
> 
> By using rc-core, the driver will be more succinct, and some latent bugs
> will be fixed. For example, at the moment it is possible to write hours
> of IR data and keep the n900 from suspending.
> 
> I'm working on lirc scancode sending and receiving using the IR encoders,
> and when that is in place, any rc-core driver will get it for free.
> 
> > That looks to me as a completely new driver, not a port to new API.
> > 
> > Right now there are applications using the current behaviour (pierogi for
> > example), which will be broken by the change.
> 
> Nothing should break.

Speaking of which, if you would please test this, that would be great. My
N900 died many years ago.

Many thanks,

Sean

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ