From mboxrd@z Thu Jan 1 00:00:00 1970 From: David =?iso-8859-1?Q?H=E4rdeman?= Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? Date: Fri, 26 Mar 2010 20:21:17 +0100 Message-ID: <20100326192117.GA9290@hardeman.nu> References: <20091215195859.GI24406@elf.ucw.cz> <9e4733910912151214n68161fc7tca0ffbf34c2c4e4@mail.gmail.com> <20091215201933.GK24406@elf.ucw.cz> <9e4733910912151229o371ee017tf3640d8f85728011@mail.gmail.com> <20091215203300.GL24406@elf.ucw.cz> <9e4733910912151245ne442a5dlcfee92609e364f70@mail.gmail.com> <9e4733910912151338n62b30af5i35f8d0963e6591c@mail.gmail.com> <4BAB7659.1040408@redhat.com> <20100326122317.GC5387@hardeman.nu> <4BACD00E.7040401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from 1-1-12-13a.han.sth.bostream.se ([82.182.30.168]:37064 "EHLO palpatine.hardeman.nu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426Ab0CZTVW (ORCPT ); Fri, 26 Mar 2010 15:21:22 -0400 Content-Disposition: inline In-Reply-To: <4BACD00E.7040401@redhat.com> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Mauro Carvalho Chehab Cc: Jon Smirl , Pavel Machek , Dmitry Torokhov , Krzysztof Halasa , hermann pitton , Christoph Bartelmus , awalls@radix.net, j@jannau.net, jarod@redhat.com, jarod@wilsonet.com, kraxel@redhat.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, superm1@ubuntu.com On Fri, Mar 26, 2010 at 12:17:34PM -0300, Mauro Carvalho Chehab wrote: > David H=E4rdeman wrote: > > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wro= te: > >>> 2) add current_protocol support on other drivers; > >> Done. Patch were already merged upstream. > >> > >> The current_protocol attribute shows the protocol(s) that the devi= ce is accepting > >> and allows changing it to another protocol.=20 > >> > >> In the case of the em28xx hardware, only one protocol can be activ= e, since the decoder > >> is inside the hardware.=20 > >> > >> On the raw IR decode implementation I've done at the saa7134, all = raw pulse events are > >> sent to all registered decoders, so I'm thinking on using this sys= fs node to allow > >> disabling the standard behavior of passing the IR codes to all dec= oders, routing it > >> to just one decoder. > >> > >> Another alternative would be to show current_protocol only for dev= ices with hardware > >> decoder, and create one sysfs node for each decoder, allowing enab= ling/disabling each > >> decoder individually. > >=20 > > You're eventually going to want to add ioctl's to set a lot of TX o= r RX=20 > > parameters in one go (stuff like active receiver(s) and transmitter= (s),=20 > > carrier frequency, duty cycle, timeouts, filter levels and resoluti= on -=20 > > all of which would need to be set in one operation since some hardw= are=20 > > will need to be reset after each parameter is changed). >=20 > TX is a completely different history. It has nothing to do with input= event > subsystem. So, another approach should be taken for it. I suggest (though I might not have been clear on that point) that irrcv= =20 devices create a char node...ir specifics are handled via that node=20 (with read/write/ioctl...see the other mail I just send). > I haven't seen yet a hardware decoder with such parameters, but maybe= I just > don't have enough specs here to adjust them. The entire idea is to have a common API for hardware decoders and=20 decoders which provide raw pulse/space timings. That, to me, is one of=20 the major points of having in-kernel IR decoders - being able to provid= e=20 a consistent interface for both hardware decoders and pulse/space=20 hardware. > Anyway, one simple way to avoid > resetting the hardware for every new parameter change would be to use= a timer > for reset. This way, an userspace application or script that is touch= ing on=20 > several parameters would just send the complete RX init sequence and > after some dozens of milliseconds, the hardware will load the new par= ameters. And I do not think that sounds like a good interface. > > Then you'll end up with a few things being controlled via sysfs and= some=20 > > being controlled via ioctls. Maybe it's a good idea to have a bitma= sk of=20 > > supported and enabled protocols in those ioctls instead? >=20 > There's an interesting discussion about bitmasks x a list of enumerat= ed values > as a way to represent a bitmask into a series of values on sysfs, > at http://lwn.net/Articles/378219/ (see "A critical look at sysfs at= tribute values" > article there). Not really relevant...that's just the minor detail of how a sysfs file=20 might be represented. > That's said, I'm starting to think that the better is to have some di= fferentiation > there between hardware and software decoders. IMO, software decoders = are better > handled with an "enabled" attribute, per software decoder, inside eac= h irrcv. I think we can create an interface which obscures the differences: Software decoders will export all in-kernel IR decoders in a bitmask in= =20 the "supported_protocols" sysfs file or ioctl struct member. Hardware decoders will export the hardware supported protocol(s) in the= =20 same file/member. In addition, a sysfs file or ioctl member for "enabled_protocols" will=20 control either the enabled in-kernel IR decoders or hardware decoder(s)= =2E As should be quite obvious by now...I suggest ioctls (on a irrcv=20 specific chardev) for controlling this :) --=20 David H=E4rdeman -- To unsubscribe from this list: send the line "unsubscribe linux-input" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html