Mauro,
On Mon, Aug 31, 2009 at 02:47:41AM -0300, Mauro Carvalho Chehab wrote:
> Em Sat, 29 Aug 2009 15:45:28 -0300
> Mauro Carvalho Chehab escreveu:
>
> > Ok, I've did several changes on both V4L and dvb-usb IR implementations.
> > They
> > scancode tables are now implemented at the same way, a
Em Sat, 29 Aug 2009 15:45:28 -0300
Mauro Carvalho Chehab escreveu:
> Ok, I've did several changes on both V4L and dvb-usb IR implementations. They
> scancode tables are now implemented at the same way, at:
> http://linuxtv.org/hg/~mchehab/IR
Ok, I've also updated the V4L2 API spec with the
Em Fri, 28 Aug 2009 09:30:42 -0300
Mauro Carvalho Chehab escreveu:
> Em Fri, 28 Aug 2009 12:50:27 +0200 (CEST)
> Patrick Boettcher escreveu:
>
> > Hi Mauro,
> >
> > On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:
> >
> > > Em Fri, 28 Aug 2009 00:46:28 -0300
> > > Mauro Carvalho Chehab escr
2009/8/28 Peter Brouwer :
>
> Would like to add one more dimension to the discussion.
>
> The situation of having multiple DVB type boards in one system.
>
> Using one remote would be enough to control the system. So we should have a
> mechanism/kernel config option, to enable/disable an IR device
Em Fri, 28 Aug 2009 00:00:54 -0400
Jarod Wilson escreveu:
> On Thursday 27 August 2009 18:06:51 Devin Heitmueller wrote:
> > On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> > Chehab wrote:
> > > Em Thu, 27 Aug 2009 21:36:36 +0300
> > > Ville Syrjälä escreveu:
> > >
> > >
> > >> I welcome this
Em Fri, 28 Aug 2009 07:41:22 -0400
Andy Walls escreveu:
> On Thu, 2009-08-27 at 18:06 -0400, Devin Heitmueller wrote:
> > On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> > Chehab wrote:
> > > Em Thu, 27 Aug 2009 21:36:36 +0300
> > > Ville Syrjälä escreveu:
>
> > Since we're on the topic of IR
Em Fri, 28 Aug 2009 11:13:33 +0100
Peter Brouwer escreveu:
>
> Would like to add one more dimension to the discussion.
>
> The situation of having multiple DVB type boards in one system.
>
> Using one remote would be enough to control the system. So we should have a
> mechanism/kernel config
Em Fri, 28 Aug 2009 12:50:27 +0200 (CEST)
Patrick Boettcher escreveu:
> Hi Mauro,
>
> On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:
>
> > Em Fri, 28 Aug 2009 00:46:28 -0300
> > Mauro Carvalho Chehab escreveu:
> >
> >> So, we need a sort of TODO list for IR changes. A start point (on a rand
On Thu, 2009-08-27 at 18:06 -0400, Devin Heitmueller wrote:
> On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> Chehab wrote:
> > Em Thu, 27 Aug 2009 21:36:36 +0300
> > Ville Syrjälä escreveu:
> Since we're on the topic of IR support, there are probably a couple of
> other things we may want to b
Hi Mauro,
On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:
Em Fri, 28 Aug 2009 00:46:28 -0300
Mauro Carvalho Chehab escreveu:
So, we need a sort of TODO list for IR changes. A start point (on a random
order) would be something like:
2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCOD
Would like to add one more dimension to the discussion.
The situation of having multiple DVB type boards in one system.
Using one remote would be enough to control the system. So we should have a
mechanism/kernel config option, to enable/disable an IR device on a board.
For multiple boards of
Em Fri, 28 Aug 2009 00:46:28 -0300
Mauro Carvalho Chehab escreveu:
> So, we need a sort of TODO list for IR changes. A start point (on a random
> order) would be something like:
>
> 2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE;
> 3) use a different arrangement for IR tables to not
On Thursday 27 August 2009 18:06:51 Devin Heitmueller wrote:
> On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> Chehab wrote:
> > Em Thu, 27 Aug 2009 21:36:36 +0300
> > Ville Syrjälä escreveu:
> >
> >
> >> I welcome this effort. It would be nice to have some kind of consistent
> >> behaviour betw
Em Thu, 27 Aug 2009 18:06:51 -0400
Devin Heitmueller escreveu:
> Since we're on the topic of IR support, there are probably a couple of
> other things we may want to be thinking about if we plan on
> refactoring the API at all:
>
> 1. The fact that for RC5 remote controls, the tables in ir-keym
On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
Chehab wrote:
> Em Thu, 27 Aug 2009 21:36:36 +0300
> Ville Syrjälä escreveu:
>
>
>> I welcome this effort. It would be nice to have some kind of consistent
>> behaviour between devices. But just limiting the effort to IR devices
>> doesn't make sense
Em Thu, 27 Aug 2009 13:15:12 -0700
Dmitry Torokhov escreveu:
> On Thu, Aug 27, 2009 at 09:36:36PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote:
> > > After years of analyzing the existing code and receiving/merging patches
> > > related to
Em Thu, 27 Aug 2009 21:36:36 +0300
Ville Syrjälä escreveu:
> I welcome this effort. It would be nice to have some kind of consistent
> behaviour between devices. But just limiting the effort to IR devices
> doesn't make sense. It shouldn't matter how the device is connected.
Agreed.
>
> FASTW
On Thu, 27 Aug 2009 19:06:13 +0200, Peter Brouwer
wrote:
After years of analyzing the existing code and receiving/merging patches
related to IR, and taking a looking at the current scenario, it is
clear to me
that something need to be done, in order to have some standard way to
map and
to
On Thu, Aug 27, 2009 at 06:06:13PM +0100, Peter Brouwer wrote:
> Mauro Carvalho Chehab wrote:
>
> Hi Mauro, All
>
> Would it be an alternative to let lirc do the mapping and just let the
> driver pass the codes of the remote to the event port.
I don't think that blindly passing IR codes through i
On Thu, Aug 27, 2009 at 09:36:36PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote:
> > After years of analyzing the existing code and receiving/merging patches
> > related to IR, and taking a looking at the current scenario, it is clear to
> > m
Em Thu, 27 Aug 2009 13:17:57 -0400
Devin Heitmueller escreveu:
> On Thu, Aug 27, 2009 at 1:06 PM, Peter
> Brouwer wrote:
> > Mauro Carvalho Chehab wrote:
> >
> > Hi Mauro, All
> >
> > Would it be an alternative to let lirc do the mapping and just let the
> > driver pass the codes of the remote to
> I recognize that lirc can support multiple remotes. However, at a
> minimum the lirc receiver should work out of the box with the remote
> the product comes with. And that means there needs to be some way in
> the driver to associate the tuner with some remote control profile
> that has its lay
On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote:
> After years of analyzing the existing code and receiving/merging patches
> related to IR, and taking a looking at the current scenario, it is clear to me
> that something need to be done, in order to have some standard way to
On Thu, Aug 27, 2009 at 2:29 PM, Trent Piepho wrote:
> On Thu, 27 Aug 2009, Devin Heitmueller wrote:
>> The biggest challenge with that approach is that lirc is still
>> maintained out-of-kernel, and the inputdev solution does not require
>> lirc at all (which is good for inexperienced end users wh
On Thu, 27 Aug 2009, Devin Heitmueller wrote:
> The biggest challenge with that approach is that lirc is still
> maintained out-of-kernel, and the inputdev solution does not require
> lirc at all (which is good for inexperienced end users who want their
> product to "just work").
If distros starte
On Thu, Aug 27, 2009 at 1:06 PM, Peter
Brouwer wrote:
> Mauro Carvalho Chehab wrote:
>
> Hi Mauro, All
>
> Would it be an alternative to let lirc do the mapping and just let the
> driver pass the codes of the remote to the event port.
> That way you do not need to patch the kernel for each new card
On Aug 27, 2009, at 1:06 PM, Peter Brouwer wrote:
Mauro Carvalho Chehab wrote:
Hi Mauro, All
Would it be an alternative to let lirc do the mapping and just let
the driver pass the codes of the remote to the event port.
That way you do not need to patch the kernel for each new card/
remote t
Mauro Carvalho Chehab wrote:
Hi Mauro, All
Would it be an alternative to let lirc do the mapping and just let the driver
pass the codes of the remote to the event port.
That way you do not need to patch the kernel for each new card/remote that comes
out.
Just release a different map file for
After years of analyzing the existing code and receiving/merging patches
related to IR, and taking a looking at the current scenario, it is clear to me
that something need to be done, in order to have some standard way to map and
to give precise key meanings for each used media keycode found on
inc
29 matches
Mail list logo
