From: "David Härdeman" <david@hardeman.nu>
To: Jarod Wilson <jarod@wilsonet.com>
Cc: Jon Smirl <jonsmirl@gmail.com>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
linux-input@vger.kernel.org,
Linux Media Mailing List <linux-media@vger.kernel.org>
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 [thread overview]
Message-ID: <20100424051206.GA3101@hardeman.nu> (raw)
In-Reply-To: <z2hbe3a4a1004231040uce51091fnf24b97de215e3ef1@mail.gmail.com>
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
and lirc bits first. Adding lirc rx support can be done as a separate
"raw" decoder later (so its scope is outside the mce driver anyway) and
TX support is not implemented in ir-core yet and we haven't had any
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
the end expose an API where drivers create "rc" devices and the input
device(s) are kept as an internal detail in rc-core rather than the way
it works now (where drivers create input devices and use ir-core to
create a kind of addon device).
But that change is about as disruptive as the ir-core -> rc-core change,
so it can also wait to a more convenient time.
--
David Härdeman
--
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
WARNING: multiple messages have this Message-ID (diff)
From: "David Härdeman" <david@hardeman.nu>
To: Jarod Wilson <jarod@wilsonet.com>
Cc: Jon Smirl <jonsmirl@gmail.com>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
linux-input@vger.kernel.org,
Linux Media Mailing List <linux-media@vger.kernel.org>
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 [thread overview]
Message-ID: <20100424051206.GA3101@hardeman.nu> (raw)
In-Reply-To: <z2hbe3a4a1004231040uce51091fnf24b97de215e3ef1@mail.gmail.com>
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
and lirc bits first. Adding lirc rx support can be done as a separate
"raw" decoder later (so its scope is outside the mce driver anyway) and
TX support is not implemented in ir-core yet and we haven't had any
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
the end expose an API where drivers create "rc" devices and the input
device(s) are kept as an internal detail in rc-core rather than the way
it works now (where drivers create input devices and use ir-core to
create a kind of addon device).
But that change is about as disruptive as the ir-core -> rc-core change,
so it can also wait to a more convenient time.
--
David Härdeman
next prev parent reply other threads:[~2010-04-24 5:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-01 17:56 [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins Mauro Carvalho Chehab
2010-04-01 17:56 ` Mauro Carvalho Chehab
2010-04-02 1:44 ` Jon Smirl
2010-04-02 1:44 ` Jon Smirl
2010-04-02 10:20 ` David Härdeman
2010-04-05 20:49 ` Jarod Wilson
2010-04-05 20:49 ` Jarod Wilson
2010-04-07 9:32 ` David Härdeman
2010-04-07 9:32 ` David Härdeman
2010-04-23 17:40 ` Jarod Wilson
2010-04-23 18:06 ` Jon Smirl
2010-04-23 18:29 ` Mauro Carvalho Chehab
2010-04-23 22:20 ` Andy Walls
2010-04-24 5:22 ` David Härdeman
2010-04-24 5:22 ` David Härdeman
2010-04-24 12:35 ` Jon Smirl
2010-04-24 12:35 ` Jon Smirl
2010-04-24 14:15 ` David Härdeman
2010-04-24 15:07 ` Jon Smirl
2010-04-24 21:23 ` David Härdeman
2010-04-24 21:23 ` David Härdeman
2010-04-24 21:59 ` Jon Smirl
2010-04-24 21:59 ` Jon Smirl
2010-04-24 5:12 ` David Härdeman [this message]
2010-04-24 5:12 ` David Härdeman
2010-04-28 4:32 ` Jarod Wilson
2010-05-25 21:05 ` Jarod Wilson
2010-05-25 21:05 ` Jarod Wilson
2010-05-26 18:28 ` Jarod Wilson
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=20100424051206.GA3101@hardeman.nu \
--to=david@hardeman.nu \
--cc=jarod@wilsonet.com \
--cc=jonsmirl@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
/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.