On May 3, 2011, at 4:21 PM, Heiko Baums wrote:
> Am Tue, 3 May 2011 13:16:57 -0400
> schrieb Jarod Wilson :
>
>> A quick look at the code suggests the 800i should indeed behave
>> more or less the same, barring any hardware-specific implementation
>> differences. Sure, might as well send one my w
On May 3, 2011, at 5:52 PM, Devin Heitmueller wrote:
> On Tue, May 3, 2011 at 4:46 PM, Jarod Wilson wrote:
>> Yeah, good to have confirmation its got the same issue (and that
>> it doesn't appear to be a simple case of flat batteries)
>>
>>> Jarod, send me your mailing address off-list, and I'll
On Tue, May 3, 2011 at 4:46 PM, Jarod Wilson wrote:
> Yeah, good to have confirmation its got the same issue (and that
> it doesn't appear to be a simple case of flat batteries)
>
>> Jarod, send me your mailing address off-list, and I'll get a package
>> into the mail this week.
>
> Will do, comin
Am Tue, 3 May 2011 16:46:09 -0400
schrieb Jarod Wilson :
> Yeah, good to have confirmation its got the same issue (and that
> it doesn't appear to be a simple case of flat batteries)
I've got a battery tester and some new batteries. ;-)
And my IR plug adapter still reacts perfectly on this RC, o
On May 3, 2011, at 4:34 PM, Devin Heitmueller wrote:
> On Tue, May 3, 2011 at 4:21 PM, Heiko Baums wrote:
>> Am Tue, 3 May 2011 13:16:57 -0400
>> schrieb Jarod Wilson :
>>
>>> A quick look at the code suggests the 800i should indeed behave
>>> more or less the same, barring any hardware-specific
On Tue, May 3, 2011 at 4:21 PM, Heiko Baums wrote:
> Am Tue, 3 May 2011 13:16:57 -0400
> schrieb Jarod Wilson :
>
>> A quick look at the code suggests the 800i should indeed behave
>> more or less the same, barring any hardware-specific implementation
>> differences. Sure, might as well send one m
Am Tue, 3 May 2011 13:16:57 -0400
schrieb Jarod Wilson :
> A quick look at the code suggests the 800i should indeed behave
> more or less the same, barring any hardware-specific implementation
> differences. Sure, might as well send one my way and I'll see what
> I can see.
This RC indeed has the
Am Tue, 3 May 2011 11:40:06 -0400
schrieb Jarod Wilson :
> So there are really two issues here. First up, the default keymap
> isn't correct for this device, and second, the behavior of the
> hardware and/or driver is terrible, as only ~20% of keypresses
> are getting though. The first is easy eno
On May 3, 2011, at 11:47 AM, Devin Heitmueller wrote:
> On Tue, May 3, 2011 at 11:40 AM, Jarod Wilson wrote:
>> So there are really two issues here. First up, the default keymap
>> isn't correct for this device, and second, the behavior of the
>> hardware and/or driver is terrible, as only ~20% o
On Tue, May 3, 2011 at 11:40 AM, Jarod Wilson wrote:
> So there are really two issues here. First up, the default keymap
> isn't correct for this device, and second, the behavior of the
> hardware and/or driver is terrible, as only ~20% of keypresses
> are getting though. The first is easy enough
On Apr 27, 2011, at 4:28 PM, Heiko Baums wrote:
...
>> However, I think I do at least see why you have no active protocols.
>> It looks like the v4l-utils ir-keytable rule is loading a new map
>> (probably the terratec_cinergy_xs one), which doesn't have a specific
>> protocol listed, so no protoco
Am Wed, 27 Apr 2011 22:28:55 +0200
schrieb Heiko Baums :
> It already said "type: NEC". But I ran `sed -i
> "s:x14:x4eb:g" /etc/rc_keymaps/nec_terratec_cinergy_xs` so that it
> says e.g. 0x4eb02 KEY_1 instead of 0x1402 KEY_1.
>
> And now it spits out a bit more, but I'm still getting scancodes on
Am Wed, 27 Apr 2011 15:19:16 -0400
schrieb Jarod Wilson :
> Heh, we'll get there...
I hope so.
> I meant dmesg output after pressing the button that results in the
> ir-keytable 4eb02 output... If I had to guess though, that was from
> the "1" key on your remote, and the issue here we're facing
On Apr 27, 2011, at 3:19 PM, Jarod Wilson wrote:
> On Apr 27, 2011, at 2:47 PM, Heiko Baums wrote:
>
>> Am Wed, 27 Apr 2011 14:28:41 -0400
>> schrieb Jarod Wilson :
> ...
>>> Hrm, ok, so *something* is resulting in scancodes... This is progress!
>>> (I think...) :)
>>
>> I'm not too optimistic.
On Apr 27, 2011, at 2:47 PM, Heiko Baums wrote:
> Am Wed, 27 Apr 2011 14:28:41 -0400
> schrieb Jarod Wilson :
...
>> Hrm, ok, so *something* is resulting in scancodes... This is progress!
>> (I think...) :)
>
> I'm not too optimistic. ;-)
Heh, we'll get there...
>>> This is one line of the ir-k
Am Wed, 27 Apr 2011 14:28:41 -0400
schrieb Jarod Wilson :
> Moving this over to linux-media, this stuff is all rc-core and is
> more of what I meant should be discussed over here/there. :)
> Hrm, ok, so *something* is resulting in scancodes... This is progress!
> (I think...) :)
I'm not too opti
Moving this over to linux-media, this stuff is all rc-core and is
more of what I meant should be discussed over here/there. :)
On Apr 27, 2011, at 9:16 AM, Heiko Baums wrote:
> Am Wed, 27 Apr 2011 00:28:40 -0400
> schrieb Jarod Wilson :
>
>> Setting it as the only active protocol decoder when st
I've got a problem since a few days after a system update. I don't know
what was updated exactly, if it was the kernel, udev or lirc. I'm using
Arch Linux with kernel 2.6.38.4.
I've got a Terratec Cinergy 1400 DVB-T (a cx88 card). Its IR remote
control has worked perfectly with lirc for many years
18 matches
Mail list logo
