Hi Oldrich,
On Thu, 9 Apr 2009 21:15:30 +0200, Oldrich Jedlicka wrote:
> I've tried your patches with AverMedia Cardbus Hybrid (E506R) and they works
> fine.
Thanks for testing and reporting, and sorry for the late answer.
> My current experience with AverMedia's IR chip (I don't know which one
Hi!
Am Sonntag, den 12.04.2009, 13:37 -0400 schrieb CityK:
> Mauro Carvalho Chehab wrote:
> > On Tue, 07 Apr 2009 23:02:43 -0400
> > CityK wrote:
> >
> >
> >> Regarding the KS003 (& KS007; the other "mystery" chip):
> >>
> >> Upon further investigation of some info from a post from last year
>
Mauro Carvalho Chehab wrote:
> On Tue, 07 Apr 2009 23:02:43 -0400
> CityK wrote:
>
>
>> Regarding the KS003 (& KS007; the other "mystery" chip):
>>
>> Upon further investigation of some info from a post from last year
>> (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html),
>>
On Monday 06 of April 2009 at 23:10:36, hermann pitton wrote:
> Hi Jean,
>
> Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare:
> > On Sun, 05 Apr 2009 23:22:03 +0200, drunk and tired hermann pitton wrote:
>
> don't tell me the French vine is always better.
> You likely know who introduce
On Tue, 07 Apr 2009 23:02:43 -0400
CityK wrote:
> Regarding the KS003 (& KS007; the other "mystery" chip):
>
> Upon further investigation of some info from a post from last year
> (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html),
> it appears that these (assuming that they a
Jean Delvare wrote:
> On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote:
>
>> Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare:
>>
>>> Anyone out there with a MSI t...@nywhere Plus that could help with
>>> testing?
>>>
>> Here is a link to one of the initial reports
On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote:
> Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare:
> > Anyone out there with a MSI t...@nywhere Plus that could help with
> > testing?
>
> Here is a link to one of the initial reports by Henry, others are close
> to it.
>
> htt
Hi Jean,
Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare:
> On Sun, 05 Apr 2009 23:22:03 +0200, drunk and tired hermann pitton wrote:
don't tell me the French vine is always better.
You likely know who introduced that currency once :)
> > Hmm, I'm still "happy" with the broken DVB-T
On Sunday 05 April 2009 14:31:54 Janne Grunau wrote:
> On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote:
> > On Sun, 2009-04-05 at 16:37 +0200, Janne Grunau wrote:
> > >
> > > I would guess that it won't work. There is an effort to merge lirc. It's
> > > currently stalled though.
> >
>
On Sun, 05 Apr 2009 08:44:15 -0400
Andy Walls wrote:
> The scope of a complete kernel IR infrastructure goes a bit beyond I2C
> bus devices that are only input devices.
>
> What's the scope of what you want to tackle here?
>
> I certainly don't want to reinvent something that's going to look ju
On Sun, 5 Apr 2009 21:52:31 -0500 (CDT)
Mike Isely wrote:
> On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
>
> > On Sun, 05 Apr 2009 18:00:04 -0400
> > Andy Walls wrote:
> >
> > > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb
On Mon, 2009-04-06 at 11:04 +0200, Jean Delvare wrote:
> Hi Andy,
> I'm all for adding
> support for more boards, however I'd rather do this _after_ the i2c
> model conversion is done, so that we have a proper changelog entry
> saying that we added support for the PVR-150, and that it gets proper
On Sun, 5 Apr 2009 13:48:02 -0500 (CDT)
Mike Isely wrote:
> My impression (at least for pvrusb2-driven devices) is that the later IR
> receivers require a completely different driver to work properly; one
> can't just bolt additional features into ir-kbd-i2c for this.
This is the old approac
On Sun, 5 Apr 2009 22:35:25 -0700 (PDT)
Uri Shkolnik wrote:
>
>
>
> --- On Mon, 4/6/09, Mauro Carvalho Chehab wrote:
>
> > From: Mauro Carvalho Chehab
> > Subject: Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding
> > model
> > To
Hi Andy,
On Sun, 05 Apr 2009 15:35:52 -0400, Andy Walls wrote:
> --- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c2009-04-04
> 10:53:08.0 +0200
> +++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
> 10:58:36.0 +0200
> [snip]
> -
> + const un
On Sun, 05 Apr 2009 23:22:03 +0200, drunk and tired hermann pitton wrote:
> Hmm, I'm still "happy" with the broken DVB-T for saa7134 on 2.6.29,
> tasting some Chianti vine now and need to sleep soon, but I'm also not
> that confident that your saa7134 MSI t...@nywhere Plus i2c remote does
> work ad
--- On Mon, 4/6/09, Mauro Carvalho Chehab wrote:
> From: Mauro Carvalho Chehab
> Subject: Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding
> model
> To: "Andy Walls"
> Cc: "hermann pitton" , "Jean Delvare"
> , "
On Sun, 5 Apr 2009, Mike Isely wrote:
> 1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently
> implicitly trying to assume a particular type of remote based on the I2C
> address of the IR receiver it's talking to. Yuck. That's really not
> right at all. The IR receiver used does not
Jean:
Here's a description of what I've got on the front burner right now:
1. The pvrusb2 driver now can unambiguously know if it is dealing with a
device that is known to have ir-kbd-i2c compatible IR capabilities.
2. There is a new module option, "disable_autoload_ir_kbd", which if
present
On Sun, 5 Apr 2009, Andy Walls wrote:
>
> Here is where LIRC may be its own worst enemy. LIRC has filled some
> shortcomings in the kernel for support of IR device functions for so
> long (LWN says LIRC is 10 years old), that large numbers of users have
> come to depend on its operation, while at
Am Sonntag, den 05.04.2009, 21:52 -0500 schrieb Mike Isely:
> On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
>
> > On Sun, 05 Apr 2009 18:00:04 -0400
> > Andy Walls wrote:
> >
> > > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrie
On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
> On Sun, 05 Apr 2009 18:00:04 -0400
> Andy Walls wrote:
>
> > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrot
Hi Andy,
Am Sonntag, den 05.04.2009, 18:00 -0400 schrieb Andy Walls:
> On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
>
>
> > What can not be translated to the
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls wrote:
> On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
>
>
> > What can not be translated to the input system I
Am Sonntag, den 05.04.2009, 18:00 -0400 schrieb Andy Walls:
> On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
>
>
> > What can not be translated to the input sys
On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> What can not be translated to the input system I would like to know.
> Andy seems to have closer looked into that.
Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> > On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote:
> > > I have devices for lirc_zilog (which should probably be merged with
> > > lirc_i2c)
> >
> > Hmmm. Following Jean'
On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote:
> > I have devices for lirc_zilog (which should probably be merged with
> > lirc_i2c)
>
> Hmmm. Following Jean's reasoning, that may be the wrong way to go, if
> you want to avoid probin
On Sun, 2009-04-05 at 13:33 -0500, Mike Isely wrote:
> Also, lirc makes it possible to userspace map the underlying
> IR codes to keybindings and associate multiple different remotes - all
> of that is apparently hardcoded in ir-kbd-i2c.
Yes. My first remote for my PC was an HP OEM'ed and cus
On Sun, 2009-04-05 at 16:05 +0200, Jean Delvare wrote:
> Hi Hans,
Hi Jean,
> Updated patch set is available at:
> http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/
>
--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/me
On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote:
> On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote:
> > If one focuses on satisfying the LKML comments to lirc_dev and the
> > Makefile to get that kernel module in the kernel, then, at least for
> > video card hosted IR devices, the
On Sun, 5 Apr 2009, Hans Verkuil wrote:
[...]
>
> Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those
> drivers that did not autoload this module. The driver author can refine
> things later (I'll definitely will do that for ivtv).
Yes, and I will do the same for pvrusb2.
Jean:
More comments interspersed below...
On Sun, 5 Apr 2009, Jean Delvare wrote:
[...]
>
> > Remember
> > that the pvrusb2 driver did not autoload ir-kbd-i2c before this patch.
> > Before this change, a user could elect not to use ir-i2c-kbd simply by
> > not loading it.
>
> Which wa
On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote:
> On Sun, 2009-04-05 at 16:37 +0200, Janne Grunau wrote:
> >
> > I would guess that it won't work. There is an effort to merge lirc. It's
> > currently stalled though.
>
> Perhaps you and Jarrod and Christopher have already discussed thi
On Sun, 2009-04-05 at 15:08 +0200, Jean Delvare wrote:
> Hi Andy,
>
> > > If IR on the cx18 is not supported (by the ir-kbd-i2c driver) then I
> > > can simplify my patch set and omit the cx18 entirely.
>
> Which I just did...
>
> > The HVR-1600 could have been supported by ir-kbd-i2c.
> >
> >
Hi Janne,
On Sun, 2009-04-05 at 16:37 +0200, Janne Grunau wrote:
> On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
> >
> > Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those
> > drivers that did not autoload this module. The driver author can refine
> > things la
On Sun, Apr 05, 2009 at 06:37:43PM +0200, Jean Delvare wrote:
> Hi Janne,
>
> On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote:
> > On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
> > >
> > > Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those
> > > drivers th
Hi Janne,
On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote:
> On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
> >
> > Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those
> > drivers that did not autoload this module. The driver author can refine
> > things la
On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
>
> Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those
> drivers that did not autoload this module. The driver author can refine
> things later (I'll definitely will do that for ivtv).
>
> It will be interesting if
Hi Mike,
Selected answers, as most points have already been discussed elsewhere
meanwhile...
On Sat, 4 Apr 2009 18:29:35 -0500 (CDT), Mike Isely wrote:
> On Sun, 5 Apr 2009, Jean Delvare wrote:
> > This is excellent news. As I said in the header comment of the patch,
> > avoiding probing when we
Hi Hans,
On Sun, 5 Apr 2009 07:46:47 +0200, Hans Verkuil wrote:
> Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those
> drivers that did not autoload this module. The driver author can refine
> things later (I'll definitely will do that for ivtv).
I'd rather name the parameter
Hi Andy,
On Sat, 04 Apr 2009 21:50:08 -0400, Andy Walls wrote:
> On Sun, 2009-04-05 at 00:51 +0200, Jean Delvare wrote:
> > On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote:
> > > I think this is way out of date for cx18 based boards. The only IR chip
> > > I know of so far is the Zilog Z8F08
On Sun, 2009-04-05 at 06:14 -0300, Mauro Carvalho Chehab wrote:
>
> IMO, doing all those tricks to support an out-of-tree driver is the wrong
> approach. This is just postponing a more serious discussion about what should
> be done in kernel, in order to better support IR's.
The "tricks" were to
On Sun, 5 Apr 2009 07:46:47 +0200
Hans Verkuil wrote:
> On Sunday 05 April 2009 01:05:39 Jean Delvare wrote:
> > Hi Mike,
> >
> > On Sat, 4 Apr 2009 10:51:01 -0500 (CDT), Mike Isely wrote:
> > > Nacked-by: Mike Isely
> > >
> > > This will interfere with the alternative use of LIRC drivers (which
On Sunday 05 April 2009 01:05:39 Jean Delvare wrote:
> Hi Mike,
>
> On Sat, 4 Apr 2009 10:51:01 -0500 (CDT), Mike Isely wrote:
> > Nacked-by: Mike Isely
> >
> > This will interfere with the alternative use of LIRC drivers (which
> > work in more cases that ir-kbd).
>
> Why then is ir-kbd in the ke
On Sun, 2009-04-05 at 00:51 +0200, Jean Delvare wrote:
> Hi Andy,
>
> On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote:
> > On Sat, 2009-04-04 at 14:28 +0200, Jean Delvare wrote:
> > > Let card drivers probe for IR receiver devices and instantiate them if
> > > found. Ultimately it would be be
On Sun, 5 Apr 2009, Jean Delvare wrote:
> Hi Mike,
>
> On Sat, 4 Apr 2009 10:51:01 -0500 (CDT), Mike Isely wrote:
> >
> > Nacked-by: Mike Isely
> >
> > This will interfere with the alternative use of LIRC drivers (which work
> > in more cases that ir-kbd).
>
> Why then is ir-kbd in the kerne
Hi Mike,
On Sat, 4 Apr 2009 10:51:01 -0500 (CDT), Mike Isely wrote:
>
> Nacked-by: Mike Isely
>
> This will interfere with the alternative use of LIRC drivers (which work
> in more cases that ir-kbd).
Why then is ir-kbd in the kernel tree and not LIRC drivers?
> It will thus break some peopl
Hi Andy,
On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote:
> On Sat, 2009-04-04 at 14:28 +0200, Jean Delvare wrote:
> > Let card drivers probe for IR receiver devices and instantiate them if
> > found. Ultimately it would be better if we could stop probing
> > completely, but I suspect this wo
On Sat, 2009-04-04 at 18:25 -0400, Andy Walls wrote:
> On Sat, 2009-04-04 at 11:05 -0500, Mike Isely wrote:
> So my rough outline of an idea (which probably runs slightly afoul of
> Hans' media_controller device, but we don't have it yet):
>
> 1. Add a function to the v4l2 framework to iterate ov
On Sat, 2009-04-04 at 11:05 -0500, Mike Isely wrote:
> On Sat, 4 Apr 2009, Andy Walls wrote:
>
>[...]
>
> >
> > I have an I2C related question. If the cx18 or ivtv driver autoloads
> > "ir-kbd-i2c" and registers an I2C client on the bus, does that preclude
> > lirc_i2c, lirc_pvr150 or lirc_
On Sat, 4 Apr 2009, Andy Walls wrote:
[...]
>
> I have an I2C related question. If the cx18 or ivtv driver autoloads
> "ir-kbd-i2c" and registers an I2C client on the bus, does that preclude
> lirc_i2c, lirc_pvr150 or lirc_zilog from using the device? LIRC users
> may notice, if it does.
>
Nacked-by: Mike Isely
This will interfere with the alternative use of LIRC drivers (which work
in more cases that ir-kbd). It will thus break some peoples' use of the
driver. Also we have better information on what i2c addresses needed to
be probed based on the model of the device - and som
On Sat, 2009-04-04 at 14:28 +0200, Jean Delvare wrote:
> Let card drivers probe for IR receiver devices and instantiate them if
> found. Ultimately it would be better if we could stop probing
> completely, but I suspect this won't be possible for all card types.
>
> There's certainly room for clea
Let card drivers probe for IR receiver devices and instantiate them if
found. Ultimately it would be better if we could stop probing
completely, but I suspect this won't be possible for all card types.
There's certainly room for cleanups. For example, some drivers are
sharing I2C adapter IDs, so t
55 matches
Mail list logo
