From mboxrd@z Thu Jan 1 00:00:00 1970 From: David =?iso-8859-1?Q?H=E4rdeman?= Subject: Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins Date: Sat, 24 Apr 2010 07:12:06 +0200 Message-ID: <20100424051206.GA3101@hardeman.nu> References: <20100401145632.5631756f@pedra> <20100402102011.GA6947@hardeman.nu> <20100407093205.GB3029@hardeman.nu> 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]:57779 "EHLO palpatine.hardeman.nu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751893Ab0DXFML (ORCPT ); Sat, 24 Apr 2010 01:12:11 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Jarod Wilson Cc: Jon Smirl , Mauro Carvalho Chehab , linux-input@vger.kernel.org, Linux Media Mailing List On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote: > So now that I'm more or less done with porting the imon driver, I > think I'm ready to start tackling the mceusb driver. But I'm debating > on what approach to take with respect to lirc support. It sort of > feels like we should have lirc_dev ported as an ir "decoder" > driver/plugin before starting to port mceusb to ir-core, so that we > can maintain lirc compat and transmit support. Alternatively, I could > port mceusb without lirc support for now, leaving it to only use > in-kernel decoding and have no transmit support for the moment, then > re-add lirc support. I'm thinking that porting lirc_dev as, say, > ir-lirc-decoder first is probably the way to go though. Anyone else > want to share their thoughts on this? I think it would make sense to start with a mce driver without the TX=20 and lirc bits first. Adding lirc rx support can be done as a separate=20 "raw" decoder later (so its scope is outside the mce driver anyway) and= =20 TX support is not implemented in ir-core yet and we haven't had any=20 discussion yet on which form it should take. > (Actually, while sharing thoughts... Should drivers/media/IR become > drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become > rc-keytable.c and so on?) It will happen...and on a related note, I still think rc-core should in= =20 the end expose an API where drivers create "rc" devices and the input=20 device(s) are kept as an internal detail in rc-core rather than the way= =20 it works now (where drivers create input devices and use ir-core to=20 create a kind of addon device). But that change is about as disruptive as the ir-core -> rc-core change= ,=20 so it can also wait to a more convenient time. --=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