Hi there, for the last few days I've been playing around with the
P7131 remote control, with the incalculable help of Nickolay V.
Shmyrev (aka. nshm) we managed to get saa7134 to read the events and
borrowed some code from bttv-input.c in order to get an RC5 decoder
(yes, the remote seems to be rc5). Things went fine until we tested
it, it seems that the RC5 decoder is not working fine So here's a
patch (done against kernel 2.6.17 source tree) with all the work done
until now, maybe somebody can correct the rc5 decoder!!
Note: In case mailman doesn't play nice with the patch I uploaded it
here: http://golfos.net/~marc/p7131-remote.patch
Thanks for all,
Marc F.
Here's some output of dmesg for you to see ;)
("key released" appears more or less randomly, and key codes repeat on
more than one key).
If you quickly press "rec"
time=1156950224.703287 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
instruction 1, toggle 0
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x01 raw=0x01 down=1
time=1156950224.815297 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
key released
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x01 raw=0x01 down=0
If you press and hold "rec" for a while
time=1156950271.150895 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950271.262903 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950271.374912 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950271.486920 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950271.598930 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950271.710940 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950271.822947 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950271.934956 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.46964 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.158973 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.270982 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.382990 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.494998 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.603010 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.715019 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.827026 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950272.939033 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950273.51052 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950273.163051 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950273.275060 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950273.387070 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
key released
Two key presses of "rec"
time=1156950293.484628 code=2001, rc5=2545514, start=2, toggle=0,
address=0, instr=1
time=1156950293.596636 code=2001, rc5=2545514, start=2, toggle=0,
address=0, instr=1
time=1156950294.424702 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
time=1156950294.536716 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
key released
Quickly pressing "1"
time=1156950305.953598 code=2004, rc5=1245514, start=2, toggle=0,
address=0, instr=4
time=1156950306.65605 code=2004, rc5=1245514, start=2, toggle=0,
address=0, instr=4
Quickly pressing "2"
time=1156950317.382484 code=3000, rc5=1145512, start=3, toggle=0,
address=0, instr=0
instruction 0, toggle 0
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=1
key released
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=0
Quickly pressing "stop"
time=1156950332.247637 code=2001, rc5=2515514, start=2, toggle=0,
address=0, instr=1
time=1156950332.359646 code=2001, rc5=2515514, start=2, toggle=0,
address=0, instr=1
Quickly pressing "back"
time=1156950341.648371 code=3000, rc5=1151512, start=3, toggle=0,
address=0, instr=0
time=1156950341.760376 code=3000, rc5=1151512, start=3, toggle=0,
address=0, instr=0
key released
Quickly pressing "video"
time=1156950350.757075 code=2010, rc5=1125514, start=2, toggle=0,
address=0, instr=10
time=1156950350.869084 code=2010, rc5=1125514, start=2, toggle=0,
address=0, instr=10
time=1156950350.981092 code=2010, rc5=1125514, start=2, toggle=0,
address=0, instr=10

Am Mittwoch, den 30.08.2006, 17:06 +0200 schrieb Marc Fargas:
Hi there, for the last few days I've been playing around with the
P7131 remote control, with the incalculable help of Nickolay V.
Shmyrev (aka. nshm) we managed to get saa7134 to read the events and
borrowed some code from bttv-input.c in order to get an RC5 decoder
(yes, the remote seems to be rc5). Things went fine until we tested
it, it seems that the RC5 decoder is not working fine So here's a
patch (done against kernel 2.6.17 source tree) with all the work done
until now, maybe somebody can correct the rc5 decoder!!

Note: In case mailman doesn't play nice with the patch I uploaded it
here: http://golfos.net/~marc/p7131-remote.patch

Thanks for all,
Marc F.

Here's some output of dmesg for you to see ;)
("key released" appears more or less randomly, and key codes repeat on
more than one key).

If you quickly press "rec"
time=1156950224.703287 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
instruction 1, toggle 0
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x01 raw=0x01 down=1
time=1156950224.815297 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
key released
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x01 raw=0x01 down=0
[]

Hi Marc and Nickolay,

cool!

With some special key pressing order it is already partly usable.

Aug 31 01:57:09 pc08 kernel: time=1156982229.794730 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Aug 31 01:57:12 pc08 kernel: time=1156982232.303276 code=3000, rc5=1115512, start=3, toggle=0, address=0, instr=0
Aug 31 01:57:12 pc08 kernel: instruction 0, toggle 0
Aug 31 01:57:12 pc08 kernel: saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=1
Aug 31 01:57:12 pc08 kernel: key released
Aug 31 01:57:12 pc08 kernel: saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=0
Aug 31 01:57:16 pc08 kernel: time=1156982236.48602 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Aug 31 01:57:18 pc08 kernel: time=1156982238.35240 code=300c, rc5=1295512, start=3, toggle=0, address=0, instr=c
Aug 31 01:57:18 pc08 kernel: instruction c, toggle 0
Aug 31 01:57:18 pc08 kernel: key released

This finally sends 0x0c defined as key number 9 and switches tvtime.

With changed to mask_keyup it is also able to produce unique keys.

IR_KEYTAB_TYPE ir_codes_asus_pc39[IR_KEYTAB_SIZE] = {
/* Keys 0 to 9 */
[ 0x2a ] = KEY_0,
[ 0x16 ] = KEY_1,
[ 0x12 ] = KEY_2,
[ 0x14 ] = KEY_3,
[ 0x36 ] = KEY_4,
[ 0x32 ] = KEY_5,
[ 0x34 ] = KEY_6,
[ 0x0e ] = KEY_7,
[ 0x0a ] = KEY_8,
[ 0x0c ] = KEY_9,

[ 0x01 ] = KEY_RADI,/* radio */
[ 0x3c ] = KEY_MENU,/* dvd/menu */
[ 0x15 ] = KEY_VLUMEUP,
[ 0x26 ] = KEY_VLUMEDWN,
[ 0x08 ] = KEY_UP,
[ 0x04 ] = KEY_DWN,
[ 0x18 ] = KEY_LEFT,
[ 0x10 ] = KEY_RIGHT,
[ 0x1a ] = KEY_VIDE,/* video */
[ 0x06 ] = KEY_AUDI,/* music */

[ 0x1e ] = KEY_TV,/* tv */
[ 0x22 ] = KEY_EXIT,/* back */
[ 0x35 ] = KEY_CHANNELUP,/* channel / program + */
[ 0x24 ] = KEY_CHANNELDWN,/* channel / program - */
[ 0x25 ] = KEY_ENTER,/* enter */

[ 0x39 ] = KEY_PAUSE,/* play/pause */
[ 0x31 ] = KEY_PREVIUS,/* rew */
[ 0x05 ] = KEY_NEXT,/* forward */
[ 0x21 ] = KEY_REWIND,/* backward << */
[ 0x19 ] = KEY_FASTFRWARD,/* forward >*/
[ 0x09 ] = KEY_STP,
[ 0x11 ] = KEY_RECRD,/* recording */
[ 0x29 ] = KEY_PWER,/* the button that reads "close" */

[ 0x2e ] = KEY_ZM,/* full screen */
[ 0x2c ] = KEY_MACR,/* recall */
[ 0x1c ] = KEY_HME,/* home */
[ 0x3a ] = KEY_PVR,/* picture */
[ 0x02 ] = KEY_MUTE,/* mute */
[ 0x3e ] = KEY_DVD,/* dvd */

};

EXPRT_SYMBL_GPL(ir_codes_asus_pc39);

But they come never through, since keydown/up is not triggered at all anymore.
Hm, seems to be very close.

Cheers,
Hermann

Am Donnerstag, den 31.08.2006, 02:41 +0200 schrieb hermann pitton:
Am Mittwoch, den 30.08.2006, 17:06 +0200 schrieb Marc Fargas:
Hi there, for the last few days I've been playing around with the
P7131 remote control, with the incalculable help of Nickolay V.
Shmyrev (aka. nshm) we managed to get saa7134 to read the events and
borrowed some code from bttv-input.c in order to get an RC5 decoder
(yes, the remote seems to be rc5). Things went fine until we tested
it, it seems that the RC5 decoder is not working fine So here's a
patch (done against kernel 2.6.17 source tree) with all the work done
until now, maybe somebody can correct the rc5 decoder!!

Note: In case mailman doesn't play nice with the patch I uploaded it
here: http://golfos.net/~marc/p7131-remote.patch

Thanks for all,
Marc F.

Here's some output of dmesg for you to see ;)
("key released" appears more or less randomly, and key codes repeat on
more than one key).

If you quickly press "rec"
time=1156950224.703287 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
instruction 1, toggle 0
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x01 raw=0x01 down=1
time=1156950224.815297 code=3001, rc5=2545512, start=3, toggle=0,
address=0, instr=1
key released
saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x01 raw=0x01 down=0
[]

Hi Marc and Nickolay,

cool!

With some special key pressing order it is already partly usable.

Aug 31 01:57:09 pc08 kernel: time=1156982229.794730 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Aug 31 01:57:12 pc08 kernel: time=1156982232.303276 code=3000, rc5=1115512, start=3, toggle=0, address=0, instr=0
Aug 31 01:57:12 pc08 kernel: instruction 0, toggle 0
Aug 31 01:57:12 pc08 kernel: saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=1
Aug 31 01:57:12 pc08 kernel: key released
Aug 31 01:57:12 pc08 kernel: saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=0
Aug 31 01:57:16 pc08 kernel: time=1156982236.48602 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Aug 31 01:57:18 pc08 kernel: time=1156982238.35240 code=300c, rc5=1295512, start=3, toggle=0, address=0, instr=c
Aug 31 01:57:18 pc08 kernel: instruction c, toggle 0
Aug 31 01:57:18 pc08 kernel: key released

This finally sends 0x0c defined as key number 9 and switches tvtime.

With changed to mask_keyup it is also able to produce unique keys.
[]

But they come never through, since keydown/up is not triggered at all anymore.
Hm, seems to be very close.

Hi,

after some googling

http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm

tis is not a RC5.

According to the logs above I changed the toggle bit.

/* Code borrowed from bttv-input.c
* to support the remote of Asus P7131 Dual card
*/
static int rc5_remote_gap = 885;
module_param(rc5_remote_gap, int, 0644);
static int rc5_key_timeout = 200;
module_param(rc5_key_timeout, int, 0644);

#define RC5_START(x)(((x)>>12)&3) // >>13 sends 1
#define RC5_TGGLE(x)(((x)>>12)&1) //was >>11
#define RC5_ADDR(x)(((x)>>6)&31)
#define RC5_INSTR(x)((x)&63)

and I got once after loading on the first key press this,

Sep 1 02:47:31 pc08 kernel: saa7134[2]: registered device video2 [v4l2]
Sep 1 02:47:31 pc08 kernel: saa7134[2]: registered device vbi2
Sep 1 02:47:31 pc08 kernel: saa7134[2]: registered device radio2
Sep 1 02:48:20 pc08 kernel: time=1157071700.385222 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 02:48:20 pc08 kernel: instruction c, toggle 1
Sep 1 02:48:20 pc08 kernel: key released

what is exactly what one would like to see and worked. Note the start3.

Further it prints now key released on every press with toggle=1,

Sep 1 03:00:31 pc08 kernel: time=1157072431.284015 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Sep 1 03:00:33 pc08 kernel: time=1157072433.30698 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:00:33 pc08 kernel: key released
Sep 1 03:00:33 pc08 kernel: time=1157072433.142680 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:00:33 pc08 kernel: key released
Sep 1 03:00:42 pc08 kernel: time=1157072442.253031 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Sep 1 03:00:44 pc08 kernel: time=1157072444.641608 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:00:44 pc08 kernel: key released
Sep 1 03:00:47 pc08 kernel: time=1157072447.692046 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Sep 1 03:00:50 pc08 kernel: time=1157072450.385567 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:00:50 pc08 kernel: key released
Sep 1 03:00:50 pc08 kernel: time=1157072450.497538 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:00:50 pc08 kernel: key released
Sep 1 03:00:59 pc08 kernel: time=1157072459.858845 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Sep 1 03:01:03 pc08 kernel: time=1157072463.673155 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:01:03 pc08 kernel: key released
Sep 1 03:01:06 pc08 kernel: time=1157072466.422669 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Sep 1 03:01:08 pc08 kernel: time=1157072468.628260 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:01:08 pc08 kernel: key released
Sep 1 03:01:08 pc08 kernel: time=1157072468.740239 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:01:08 pc08 kernel: key released
Sep 1 03:01:18 pc08 kernel: time=1157072478.423489 code=2020, rc5=1449514, start=2, toggle=0, address=0, instr=20
Sep 1 03:01:18 pc08 kernel: time=1157072478.535466 code=2020, rc5=1449514, start=2, toggle=0, address=0, instr=20
Sep 1 03:01:31 pc08 kernel: time=1157072491.545117 code=3000, rc5=1445512, start=3, toggle=1, address=0, instr=0
Sep 1 03:01:31 pc08 kernel: instruction 0, toggle 1
Sep 1 03:01:31 pc08 kernel: saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=1
Sep 1 03:01:31 pc08 kernel: key released
Sep 1 03:01:31 pc08 kernel: saa7134 IR (ASUSTeK P7131 Dual): unknown key: key=0x00 raw=0x00 down=0
Sep 1 03:01:39 pc08 kernel: time=1157072499.141742 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Sep 1 03:01:41 pc08 kernel: time=1157072501.427330 code=300c, rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 03:01:41 pc08 kernel: instruction c, toggle 1
Sep 1 03:01:41 pc08 kernel: key released

but only after forcing an unknow key the second press then does the wanted again.

As start bits it counts the toggle changes ;), likely gap and other timings are also not correct.

The transmitter chip within the device has no prints on it anymore, except some half x,
the rest seems to be removed with some cleaning fluid.

The PCB has PC-LG39K-PCB-V04, nothing on the web or at lginnotek.
The 39K likely indicates that this also doesn't fit to the 36K of the RC5.

Interesting that it is such close to working.

Cheers,
Hermann

, 01/09/2006 03:20 +0200, hermann pitton :

and I got once after loading on the first key press this,

Sep 1 02:47:31 pc08 kernel: saa7134[2]: registered device video2
[v4l2]
Sep 1 02:47:31 pc08 kernel: saa7134[2]: registered device vbi2
Sep 1 02:47:31 pc08 kernel: saa7134[2]: registered device radio2
Sep 1 02:48:20 pc08 kernel: time=1157071700.385222 code=300c,
rc5=1295512, start=3, toggle=1, address=0, instr=c
Sep 1 02:48:20 pc08 kernel: instruction c, toggle 1
Sep 1 02:48:20 pc08 kernel: key released

what is exactly what one would like to see and worked. Note the
start3.

Further it prints now key released on every press with toggle=1,

Well the actual keypresses are minor problem. Below there are some
checks for bits in decoded code, so if we'll remove they keys will work.
But first of all, we need correct decoding. For example, see checks for
RC_START (rc5) = 3 and RC_ADDR (rc5)=0. Now with toggle on bit 2 instead
of bit 3 we have something wrong.

As start bits it counts the toggle changes ;), likely gap and other
timings are also not correct.

The transmitter chip within the device has no prints on it anymore,
except some half x,
the rest seems to be removed with some cleaning fluid.

The PCB has PC-LG39K-PCB-V04, nothing on the web or at lginnotek.
The 39K likely indicates that this also doesn't fit to the 36K of the
RC5.

Interesting that it is such close to working.

Cheers,

I am trying to decode the data right now. It's obviously some time-based
encoding, probably biphase-encoded, probably pulse-distance. The toggle
bit goes at start, then goes some constant value, at the end the code is
transmitted. The delay between pulses is either 178x or 26xx or 36xx,
i.e. it's close to multiplies of 885. It looks like RC5 but probably our
code has some bug that makes decoding wrong. We know toggle is in first
bit, but the problem is to extract keycode. The current algorithm fails
on that, there are keys with the same keycode.

The times, if someone interested:

http://golfos.net/~marc/times

Am Freitag, den 01.09.2006, 11:41 +0400 schrieb Nickolay V. Shmyrev:
, 01/09/2006 03:20 +0200, hermann pitton :
[]

Well the actual keypresses are minor problem. Below there are some
checks for bits in decoded code, so if we'll remove they keys will work.
But first of all, we need correct decoding. For example, see checks for
RC_START (rc5) = 3 and RC_ADDR (rc5)=0. Now with toggle on bit 2 instead
of bit 3 we have something wrong.

For unique and defined keys the remote works now :)

I have dropped the third start bit, which is not needed and now the
toggle bit doesn't count for these anymore, but is still received.

#define RC5_START(x)(((x)>>12)&2) //was &3
#define RC5_TGGLE(x)(((x)>>12)&1) //was >>11
#define RC5_ADDR(x)(((x)>>6)&31)
#define RC5_INSTR(x)((x)&63)

and here

if (RC5_START(rc5) != 2) {

As start bits it counts the toggle changes ;), likely gap and other
timings are also not correct.
[]

I am trying to decode the data right now. It's obviously some time-based
encoding, probably biphase-encoded, probably pulse-distance. The toggle
bit goes at start, then goes some constant value, at the end the code is
transmitted. The delay between pulses is either 178x or 26xx or 36xx,
i.e. it's close to multiplies of 885. It looks like RC5 but probably our
code has some bug that makes decoding wrong. We know toggle is in first
bit, but the problem is to extract keycode. The current algorithm fails
on that, there are keys with the same keycode.

The times, if someone interested:

http://golfos.net/~marc/times

Yes, to get all keys unique is the difficult part now,
but very nice progress.

Thanks for taking it up again!

Hermann

sample.

Sep 2 00:35:40 pc08 kernel: time=1157150140.665866 code=200c, rc5=1295514, start=2, toggle=0, address=0, instr=c
Sep 2 00:35:40 pc08 kernel: instruction c, toggle 0
Sep 2 00:35:40 pc08 kernel: key released
Sep 2 00:35:49 pc08 kernel: time=1157150149.9357 code=3005, rc5=2245512, start=2, toggle=1, address=0, instr=5
Sep 2 00:35:49 pc08 kernel: instruction 5, toggle 1
Sep 2 00:35:49 pc08 kernel: key released

Yes, to get all keys unique is the difficult part now,
but very nice progress.

It looks like remote doesn't pass carrier, instead is just starts with
toggle bit. After some analysis I think that the attached patch should
do the work. The key difference between it and previous one is:

code = (code << 2) | 1;

in rc5_decode instead of

code = (code << 1) | 1;

Keytable is empty for now, but values will change anyhow. The check for
middle bit and carrier don't have any sense.

Am Samstag, den 02.09.2006, 08:08 +0400 schrieb Nickolay V. Shmyrev:
Yes, to get all keys unique is the difficult part now,
but very nice progress.

It looks like remote doesn't pass carrier, instead is just starts with
toggle bit. After some analysis I think that the attached patch should
do the work. The key difference between it and previous one is:

code = (code << 2) | 1;

in rc5_decode instead of

code = (code << 1) | 1;

Keytable is empty for now, but values will change anyhow. The check for
middle bit and carrier don't have any sense.

It _seems_ to produce unique keys now. There is compile trouble with
dprintk (dev undeclared) and the not removed address bits print out.

Unfortunately toggle always 0 is back. Means you can't press a key twice
without pressing an other key first. Repeat works.

Should I fill the keytable with my current keys again to compare?

Hermann

, 02/09/2006 20:38 +0200, hermann pitton :
Am Samstag, den 02.09.2006, 08:08 +0400 schrieb Nickolay V. Shmyrev:
Yes, to get all keys unique is the difficult part now,
but very nice progress.

It looks like remote doesn't pass carrier, instead is just starts with
toggle bit. After some analysis I think that the attached patch should
do the work. The key difference between it and previous one is:

code = (code << 2) | 1;

in rc5_decode instead of

code = (code << 1) | 1;

Keytable is empty for now, but values will change anyhow. The check for
middle bit and carrier don't have any sense.

It _seems_ to produce unique keys now. There is compile trouble with
dprintk (dev undeclared) and the not removed address bits print out.

Unfortunately toggle always 0 is back. Means you can't press a key twice
without pressing an other key first. Repeat works.

Should I fill the keytable with my current keys again to compare?

Hermann

Hi Herman, greate news.

Heh, no ability to test here. Can you please try to find toggle, it
should be there, either

#define RC5_TGGLE(x) (((x)>>12)&1) should be

#define RC5_TGGLE(x) (((x)>>11)&1) or

#define RC5_TGGLE(x) (((x)>>13)&1)

course, fill the keytable with values.

Am Samstag, den 02.09.2006, 22:55 +0400 schrieb Nickolay V. Shmyrev:
, 02/09/2006 20:38 +0200, hermann pitton :
Am Samstag, den 02.09.2006, 08:08 +0400 schrieb Nickolay V. Shmyrev:
Yes, to get all keys unique is the difficult part now,
but very nice progress.

It looks like remote doesn't pass carrier, instead is just starts with
toggle bit. After some analysis I think that the attached patch should
do the work. The key difference between it and previous one is:

code = (code << 2) | 1;

in rc5_decode instead of

code = (code << 1) | 1;

Keytable is empty for now, but values will change anyhow. The check for
middle bit and carrier don't have any sense.

It _seems_ to produce unique keys now. There is compile trouble with
dprintk (dev undeclared) and the not removed address bits print out.

Unfortunately toggle always 0 is back. Means you can't press a key twice
without pressing an other key first. Repeat works.

Should I fill the keytable with my current keys again to compare?

Hermann

Hi Herman, greate news.

Heh, no ability to test here. Can you please try to find toggle, it
should be there, either

#define RC5_TGGLE(x) (((x)>>12)&1) should be

#define RC5_TGGLE(x) (((x)>>11)&1) or

#define RC5_TGGLE(x) (((x)>>13)&1)

course, fill the keytable with values.

Yup. It is on >>11.

Didn't try to fix the dprintk error, forgot how offhand.
Can't we replace the btv with saa7134 too.

Attached what currently works for me.

Nickolay, thanks a lot!

Cheers,
Hermann

If needed.
Signed-off-by: Hermann Pitton <hermann-pitton (AT) arcor (DOT) de>

Hi again,
My keycodes are exactly the same as yours, but I'm also having exactly
the same issue as you with pressing two times the same key. But also
noticed that I have to press a key *really* quick or I'll get three
input events for it. Also, if you hold it pressed you get lots of
events for it, the issue comes if you release it and press it again ;)

Some output below, you get an input event as long as the code & rc5
fields are the same, if rc5 changes without changing code then no
event is raised, inspite it still gets the 'key released', will try
further tomorrow!

Thanks for all the help!
Marc F.

code=2de7, rc5=1525514, toggle=0, instr=27
code=2de7, rc5=1525514, toggle=0, instr=27
code=25e7, rc5=1525512, toggle=0, instr=27
code=25e7, rc5=1525512, toggle=0, instr=27
code=25e7, rc5=1525512, toggle=0, instr=27
key released
code=2de7, rc5=1525514, toggle=0, instr=27
code=2de7, rc5=1525514, toggle=0, instr=27
key released
code=25e7, rc5=1525512, toggle=0, instr=27
code=25e7, rc5=1525512, toggle=0, instr=27
key released
code=2de7, rc5=1525514, toggle=0, instr=27
code=2de7, rc5=1525514, toggle=0, instr=27
key released
code=25e7, rc5=1525512, toggle=0, instr=27
code=25e7, rc5=1525512, toggle=0, instr=27
key released
code=2de7, rc5=1525514, toggle=0, instr=27
code=2de7, rc5=1525514, toggle=0, instr=27
key released
code=25e7, rc5=1525512, toggle=0, instr=27
code=25e7, rc5=1525512, toggle=0, instr=27
key released
code=2def, rc5=1545514, toggle=0, instr=2f
code=2def, rc5=1545514, toggle=0, instr=2f
key released
code=25ef, rc5=1545512, toggle=0, instr=2f
code=25ef, rc5=1545512, toggle=0, instr=2f
key released
code=2def, rc5=1545514, toggle=0, instr=2f
code=2def, rc5=1545514, toggle=0, instr=2f
key released
code=25ef, rc5=1545512, toggle=0, instr=2f
code=25ef, rc5=1545512, toggle=0, instr=2f
key released
code=2def, rc5=1545514, toggle=0, instr=2f
code=2def, rc5=1545514, toggle=0, instr=2f
key released
code=25fb, rc5=1455512, toggle=0, instr=3b
code=25fb, rc5=1455512, toggle=0, instr=3b
key released
code=2dfb, rc5=1455514, toggle=0, instr=3b
code=2dfb, rc5=1455514, toggle=0, instr=3b
code=2dfb, rc5=1455514, toggle=0, instr=3b
key released
code=25fb, rc5=1455512, toggle=0, instr=3b
code=25fb, rc5=1455512, toggle=0, instr=3b
key released
code=2dfb, rc5=1455514, toggle=0, instr=3b
code=2dfb, rc5=1455514, toggle=0, instr=3b
key released
END UTPUT

9/2/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Didn't try to fix the dprintk error, forgot how offhand.
Can't we replace the btv with saa7134 too.

Attached what currently works for me.

Nickolay, thanks a lot!

Cheers,
Hermann
--
If needed.
Signed-off-by: Hermann Pitton <hermann-pitton (AT) arcor (DOT) de>

Am Sonntag, den 03.09.2006, 05:23 +0200 schrieb Marc Fargas:
Hi again,
My keycodes are exactly the same as yours, but I'm also having exactly
the same issue as you with pressing two times the same key. But also
noticed that I have to press a key *really* quick or I'll get three
input events for it. Also, if you hold it pressed you get lots of
events for it, the issue comes if you release it and press it again ;)

Some output below, you get an input event as long as the code & rc5
fields are the same, if rc5 changes without changing code then no
event is raised, inspite it still gets the 'key released', will try
further tomorrow!

Hi Marc,

the same keys is fine!

With the toggle bit back in the recent version of the patch it is all
K.

Yes, key timing is really quick, didn't change it yet.
What about it when loading saa7134 with "rc5_key_timeout=50" ?

Thanks for all!

Cheers,
Hermann

Hi there,
It's been somedays out but here it is, almost fully working and I
tried to get the bt8xx and saa7134 rc5 toghether.

In brief, what I did:
* Moved the rc5_decode and rc5_timer_end from bt8xx to ir-functions.c
to share it among others.
* moved structs bttv_ir and saa7134_ir to a unique card_ir under
ir-common.h (rc5_timer_end expects it)
* Tried to get it working again

The only thing I'm sure isn't working are all the dprintk()'s in the
new functions in ir-functions.c so I changed them to printk()'s for
testing, but that makes a lot of noise on dmesg so if somebody know
how to put back the dprintk's ;)

And! I have no bt8xx to make sure I didn't break something, so If
anybody with a bt8xx can try his rc5 remote I'd be glad.

For the rest I thing I didn't do anything bad hope so! And if
somebody is bored (saa7134|bttv)_rc5_irq is still waitting for
somebody trying to get it into one hehe. There's another driver
which uses the *_ir struct but seems harder to move.

The patch is agains current HG.

If needed.
Signed-off-by: Marc Fargas <telenieko (AT) telenieko (DOT) com>
(don't know how to add the signed-off-by to a patch, hehe).

Cheers,
Marc Fargas

9/3/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

the same keys is fine!

With the toggle bit back in the recent version of the patch it is all
K.

Yes, key timing is really quick, didn't change it yet.
What about it when loading saa7134 with "rc5_key_timeout=50" ?

Thanks for all!

Cheers,
Hermann

Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc Fargas:
Hi there,
It's been somedays out but here it is, almost fully working and I
tried to get the bt8xx and saa7134 rc5 toghether.

In brief, what I did:
* Moved the rc5_decode and rc5_timer_end from bt8xx to ir-functions.c
to share it among others.
* moved structs bttv_ir and saa7134_ir to a unique card_ir under
ir-common.h (rc5_timer_end expects it)
* Tried to get it working again

The only thing I'm sure isn't working are all the dprintk()'s in the
new functions in ir-functions.c so I changed them to printk()'s for
testing, but that makes a lot of noise on dmesg so if somebody know
how to put back the dprintk's ;)

And! I have no bt8xx to make sure I didn't break something, so If
anybody with a bt8xx can try his rc5 remote I'd be glad.

For the rest I thing I didn't do anything bad hope so! And if
somebody is bored (saa7134|bttv)_rc5_irq is still waitting for
somebody trying to get it into one hehe. There's another driver
which uses the *_ir struct but seems harder to move.

The patch is agains current HG.

If needed.
Signed-off-by: Marc Fargas <telenieko (AT) telenieko (DOT) com>
(don't know how to add the signed-off-by to a patch, hehe).

Cheers,
Marc Fargas

Hi Marc,

doh, Mauro will really need your sign.

Mine of course was only meant for the diff to Nickolay's previous
version of this work in progress :)

Cheers,
Hermann

9/3/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

the same keys is fine!

With the toggle bit back in the recent version of the patch it is all
K.

Yes, key timing is really quick, didn't change it yet.
What about it when loading saa7134 with "rc5_key_timeout=50" ?

Thanks for all!

Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc Fargas:
Hi there,
It's been somedays out but here it is, almost fully working and I
tried to get the bt8xx and saa7134 rc5 toghether.

In brief, what I did:
* Moved the rc5_decode and rc5_timer_end from bt8xx to ir-functions.c
to share it among others.
* moved structs bttv_ir and saa7134_ir to a unique card_ir under
ir-common.h (rc5_timer_end expects it)
* Tried to get it working again

The only thing I'm sure isn't working are all the dprintk()'s in the
new functions in ir-functions.c so I changed them to printk()'s for
testing, but that makes a lot of noise on dmesg so if somebody know
how to put back the dprintk's ;)

And! I have no bt8xx to make sure I didn't break something, so If
anybody with a bt8xx can try his rc5 remote I'd be glad.

For the rest I thing I didn't do anything bad hope so! And if
somebody is bored (saa7134|bttv)_rc5_irq is still waitting for
somebody trying to get it into one hehe. There's another driver
which uses the *_ir struct but seems harder to move.

The patch is agains current HG.

If needed.
Signed-off-by: Marc Fargas <telenieko (AT) telenieko (DOT) com>
(don't know how to add the signed-off-by to a patch, hehe).

Cheers,
Marc Fargas

Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within current
defaults. Sorry, was out of the window. Seems ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who all
contributed initially, is able to confirm or not that his Nebula Digitv
is broken/unbroken with the current.

Cheers,
Hermann

9/3/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

the same keys is fine!

With the toggle bit back in the recent version of the patch it is all
K.

Yes, key timing is really quick, didn't change it yet.
What about it when loading saa7134 with "rc5_key_timeout=50" ?

Thanks for all!

Cheers,
Hermann

Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home tomorrow,
anyway the patch i currently on hands of nickolay and mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

nickolay: I added you to CC to let you know that maybe the patch needs
to be changed before getting merged, also I think I forgot to remove
some debbuing printk(), I'll check it also tomorrow at home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc Fargas:
>< previous message removed >
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within current
defaults. Sorry, was out of the window. Seems ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who all
contributed initially, is able to confirm or not that his Nebula Digitv
is broken/unbroken with the current.

Cheers,
Hermann

Hi Marc,

Am Sonntag, den 12.11.2006, 02:48 +0100 schrieb Marc Fargas:
Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home tomorrow,
anyway the patch i currently on hands of nickolay and mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

Yes, please check. The repeat function doesn't work at all for me with
ir_rc5_key_timeout=50. Hopefully we come in sync here too.

Cheers,
Hermann

nickolay: I added you to CC to let you know that maybe the patch needs
to be changed before getting merged, also I think I forgot to remove
some debbuing printk(), I'll check it also tomorrow at home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc Fargas:
>< previous message removed >
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within current
defaults. Sorry, was out of the window. Seems ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who all
contributed initially, is able to confirm or not that his Nebula Digitv
is broken/unbroken with the current.

Cheers,
Hermann

Hi,
115 and 50 seem to work fine for me, with 50 I've got some keys repeated
(not having repeat set) but 115 gives some "short code" messages, I'm using
the remote with 115 now and it goes smooth so maybe the default value could
be 115 for ir_rc5_key_timeout.

For the record, I've tried he remote with irw, irexec and mythfrontend and
all work fine! well mythtv does not read KEY_[0-9] but that's another
issue ehe

Cheers,
Marc.

11/13/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:

Hi Marc,

Am Sonntag, den 12.11.2006, 02:48 +0100 schrieb Marc Fargas:
Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home tomorrow,
anyway the patch i currently on hands of nickolay and mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

Yes, please check. The repeat function doesn't work at all for me with
ir_rc5_key_timeout=50. Hopefully we come in sync here too.

Cheers,
Hermann

nickolay: I added you to CC to let you know that maybe the patch needs
to be changed before getting merged, also I think I forgot to remove
some debbuing printk(), I'll check it also tomorrow at home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc Fargas:
>< previous message removed >
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within current
defaults. Sorry, was out of the window. Seems ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who all
contributed initially, is able to confirm or not that his Nebula
Digitv
is broken/unbroken with the current.

Cheers,
Hermann
--

Am Dienstag, den 14.11.2006, 01:21 +0100 schrieb Marc Fargas:
Hi,
115 and 50 seem to work fine for me, with 50 I've got some keys
repeated (not having repeat set) but 115 gives some "short code"
messages, I'm using the remote with 115 now and it goes smooth so
maybe the default value could be 115 for ir_rc5_key_timeout.

For the record, I've tried he remote with irw, irexec and
mythfrontend and all work fine! well mythtv does not read KEY_[0-9]
but that's another issue ehe

Cheers,
Marc.

Hi,

oh well, I just checked with tvtime and Gerd's input-utils and what
happens in a shell.

For my understanding 0-9 and enter are still the reference keys,
also working without any other layer in between on 2.4x.

Didn't even had any idea on lirc for reference at all and won't have in
the future. (or why I should?)

Cheers,
Hermann

11/13/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

Am Sonntag, den 12.11.2006, 02:48 +0100 schrieb Marc Fargas:
Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home
tomorrow,
anyway the patch i currently on hands of nickolay and
mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

Yes, please check. The repeat function doesn't work at all for
me with
ir_rc5_key_timeout=50. Hopefully we come in sync here too.

Cheers,
Hermann

nickolay: I added you to CC to let you know that maybe the
patch needs
to be changed before getting merged, also I think I forgot
to remove
some debbuing printk(), I'll check it also tomorrow at
home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc
Fargas:
>< previous message removed >
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within
current
defaults. Sorry, was out of the window. Seems
ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who
all
contributed initially, is able to confirm or not that his
Nebula Digitv
is broken/unbroken with the current.

Cheers,
Hermann

Monday 13 November 2006 19:21, Marc Fargas wrote:
Hi,
115 and 50 seem to work fine for me, with 50 I've got some keys repeated
(not having repeat set) but 115 gives some "short code" messages, I'm using
the remote with 115 now and it goes smooth so maybe the default value could
be 115 for ir_rc5_key_timeout.

For the record, I've tried he remote with irw, irexec and mythfrontend and
all work fine! well mythtv does not read KEY_[0-9] but that's another
issue ehe

Cheers,
Marc.

11/13/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

Am Sonntag, den 12.11.2006, 02:48 +0100 schrieb Marc Fargas:
Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home tomorrow,
anyway the patch i currently on hands of nickolay and mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

Yes, please check. The repeat function doesn't work at all for me with
ir_rc5_key_timeout=50. Hopefully we come in sync here too.

Cheers,
Hermann

nickolay: I added you to CC to let you know that maybe the patch needs
to be changed before getting merged, also I think I forgot to remove
some debbuing printk(), I'll check it also tomorrow at home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc Fargas:
>< previous message removed >
>
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within current
defaults. Sorry, was out of the window. Seems ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who all
contributed initially, is able to confirm or not that his Nebula

Digitv

is broken/unbroken with the current.

Cheers,
Hermann

Monday 13 November 2006 19:21, Marc Fargas wrote:
Hi,
115 and 50 seem to work fine for me, with 50 I've got some keys repeated
(not having repeat set) but 115 gives some "short code" messages, I'm using
the remote with 115 now and it goes smooth so maybe the default value could
be 115 for ir_rc5_key_timeout.

For the record, I've tried he remote with irw, irexec and mythfrontend and
all work fine! well mythtv does not read KEY_[0-9] but that's another
issue ehe

Cheers,
Marc.

11/13/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

Am Sonntag, den 12.11.2006, 02:48 +0100 schrieb Marc Fargas:
Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home tomorrow,
anyway the patch i currently on hands of nickolay and mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

Yes, please check. The repeat function doesn't work at all for me with
ir_rc5_key_timeout=50. Hopefully we come in sync here too.

Cheers,
Hermann

nickolay: I added you to CC to let you know that maybe the patch needs
to be changed before getting merged, also I think I forgot to remove
some debbuing printk(), I'll check it also tomorrow at home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc Fargas:
>< previous message removed >
>
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within current
defaults. Sorry, was out of the window. Seems ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who all
contributed initially, is able to confirm or not that his Nebula

Digitv

is broken/unbroken with the current.

Cheers,
Hermann

Has anyone had any success getting the recent Hauppauge WinTV Go-plus to work
under those distros? Here's my to date unsuccessful dmesg section

Linux video capture interface: v1.00
bttv: driver version 0.9.16 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 17) at 0000:02:00.0, irq: 17, latency: 32, mmio: 0xec000000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,insmod option]
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 0-0050: Hauppauge model 44981, rev E1B2, serial# 9905492
tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 0-0050: audio processor is None (idx 0)
tveeprom 0-0050: decoder processor is BT878 (idx 14)
tveeprom 0-0050: has no radio, has IR remote
bttv0: Hauppauge eeprom indicates model#44981
bttv0: using tuner=50
bttv0: i2c: checking for MSP34xx @ 0x80 not found
bttv0: i2c: checking for TDA9875 @ 0xb0 not found
bttv0: i2c: checking for TDA7432 @ 0x8a not found
bttv0: i2c: checking for TDA9887 @ 0x86 not found
tuner 0-0061: chip found @ 0xc2 (bt878 #0 [sw])
tuner 0-0061: type set to 50 (TCL 2002N)
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 =35468950 ok
bt878: AUDI driver version 0.0.0 loaded
bt878: Bt878 AUDI function found (0).
bt878_probe: card id=[0x13eb0070], Unknown card.
Exiting
bt878: probe of 0000:02:00.1 failed with error -22

Hi,

due to recent changes, the patches did not apply anymore and also don't
compile.

Attached is an updated patchset, which fixes those issues against v4l-
dvb master of today. I also removed remaining *btv stuff from saa7134-
input.c and added the previously proposed change of 115 ms to the
key_timeout.

For replacing some printk with dprintk in the ir-functions.c patch we
could still need help of someone experienced with the dprintk macro.

The remote works fine for me and also my other saa7134 remote is fine,
but we still have no test report for the bttv Nebula DigiTV.

Any review is highly appreciated.

For the diff against Marc's latest version from Sept. 28.
Signed-off-by: Hermann Pitton <hermann-pitton (AT) arcor (DOT) de>

Thanks,
Hermann

Am Dienstag, den 14.11.2006, 03:34 +0100 schrieb hermann pitton:
Am Dienstag, den 14.11.2006, 01:21 +0100 schrieb Marc Fargas:
Hi,
115 and 50 seem to work fine for me, with 50 I've got some keys
repeated (not having repeat set) but 115 gives some "short code"
messages, I'm using the remote with 115 now and it goes smooth so
maybe the default value could be 115 for ir_rc5_key_timeout.

For the record, I've tried he remote with irw, irexec and
mythfrontend and all work fine! well mythtv does not read KEY_[0-9]
but that's another issue ehe

Cheers,
Marc.

Hi,

oh well, I just checked with tvtime and Gerd's input-utils and what
happens in a shell.

For my understanding 0-9 and enter are still the reference keys,
also working without any other layer in between on 2.4x.

Didn't even had any idea on lirc for reference at all and won't have in
the future. (or why I should?)

Cheers,
Hermann

11/13/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

Am Sonntag, den 12.11.2006, 02:48 +0100 schrieb Marc Fargas:
Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home
tomorrow,
anyway the patch i currently on hands of nickolay and
mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

Yes, please check. The repeat function doesn't work at all for
me with
ir_rc5_key_timeout=50. Hopefully we come in sync here too.

Cheers,
Hermann

nickolay: I added you to CC to let you know that maybe the
patch needs
to be changed before getting merged, also I think I forgot
to remove
some debbuing printk(), I'll check it also tomorrow at
home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc
Fargas:
>< previous message removed >
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within
current
defaults. Sorry, was out of the window. Seems
ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who
all
contributed initially, is able to confirm or not that his
Nebula Digitv
is broken/unbroken with the current.

Cheers,
Hermann

Can anybody help, or point to you may be able to

So here's another piece of the puzzle, from lsmod

bt878 9912 0
tuner 52268 0
tvaudio 22940 0
bttv 164628 2 bt878
video_buf 21220 3 cx8800,cx88xx,bttv
ir_common 24484 2 cx88xx,bttv
compat_ioctl32 1952 2 cx8800,bttv
i2c_algo_bit 9352 4 cx88xx,ivtv,rivatv,bttv
v4l2_common 15648 3 cx8800,tuner,bttv
btcx_risc 4840 3 cx8800,cx88xx,bttv
tveeprom 14192 3 cx88xx,ivtv,bttv
i2c_core 17536 9
cx88xx,ivtv,rivatv,lirc_i2c,tuner,tvaudio,bttv,i2c _algo_bit,tveeprom
videodev 8064 5 cx8800,cx88xx,ivtv,rivatv,bttv

Friday 24 November 2006 19:44, Jim Lill wrote:
So let's try this has anyone got one of these "late-model" H
cards working with any Linux distro?

Wednesday 22 November 2006 19:02, Jim Lill wrote:
Has anyone had any success getting the recent Hauppauge WinTV Go-plus to
work under those distros? Here's my to date unsuccessful dmesg section

(see previous posts)

What I get so far

xawtv -hwscan
This is xawtv-3.95, running on Linux/i686 (2.6.17-5mdv)
looking for available devices
/dev/video0: K [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Hauppauge (bt878))
flags: overlay capture tuner

but xawtv will bomb and lock things if I run it otherwise

no sound

scantv finds channels

Monday 27 November 2006 17:04, Jim Lill wrote:

Can anybody help, or point to who may be able to

So here's another piece of the puzzle, from lsmod

Am Sonntag, den 26.11.2006, 21:56 +0100 schrieb hermann pitton:
Hi,

due to recent changes, the patches did not apply anymore and also don't
compile.

Attached is an updated patchset, which fixes those issues against v4l-
dvb master of today. I also removed remaining *btv stuff from saa7134-
input.c and added the previously proposed change of 115 ms to the
key_timeout.

For replacing some printk with dprintk in the ir-functions.c patch we
could still need help of someone experienced with the dprintk macro.

Hi,

it turned out this one needs at least debug level set and a pointer.

New patch is attached.

With this one all debug is disabled now again by default and can be
turned on with option ir-common debug=1 or
"echo 1 /"
and will appear in "dmesg" or "cat /proc/kmsg" can be used for easy
testing.

Pressing key number 1, 2 and 3 results in:

ir-common: code=25e9, rc5=4915449, start=2, toggle=0, address=17, instr=29
ir-common: instruction 29, toggle 0
saa7134 IR (ASUSTeK P7131 Dual): key event code=2 down=1
ir-common: key released
saa7134 IR (ASUSTeK P7131 Dual): key event code=2 down=0
ir-common: code=2ded, rc5=4515451, start=2, toggle=1, address=17, instr=2d
ir-common: instruction 2d, toggle 1
saa7134 IR (ASUSTeK P7131 Dual): key event code=3 down=1
ir-common: key released
saa7134 IR (ASUSTeK P7131 Dual): key event code=3 down=0
ir-common: code=25eb, rc5=5115449, start=2, toggle=0, address=17, instr=2b
ir-common: instruction 2b, toggle 0
saa7134 IR (ASUSTeK P7131 Dual): key event code=4 down=1
ir-common: key released
saa7134 IR (ASUSTeK P7131 Dual): key event code=4 down=0

The remote works fine and the instructions are correct. The also visible
saa7134 IR output is correct too and code= refers to key enumeration in
input.h.

Another sample, now for error handling, firing one press of the FV3K
remote against it.

ir-common: ir_rc5_decode(4ecd3b81) bad code
ir-common: rc5 start bits invalid: 0
ir-common: ir_rc5_decode(a6949ad1) bad code
ir-common: rc5 start bits invalid: 0
ir-common: short code: 252b5

Cheers,
Hermann

The remote works fine for me and also my other saa7134 remote is fine,
but we still have no test report for the bttv Nebula DigiTV.

Any review is highly appreciated.

For the diff against Marc's latest version from Sept. 28.
Signed-off-by: Hermann Pitton <hermann-pitton (AT) arcor (DOT) de>

Thanks,
Hermann

Am Dienstag, den 14.11.2006, 03:34 +0100 schrieb hermann pitton:
Am Dienstag, den 14.11.2006, 01:21 +0100 schrieb Marc Fargas:
Hi,
115 and 50 seem to work fine for me, with 50 I've got some keys
repeated (not having repeat set) but 115 gives some "short code"
messages, I'm using the remote with 115 now and it goes smooth so
maybe the default value could be 115 for ir_rc5_key_timeout.

For the record, I've tried he remote with irw, irexec and
mythfrontend and all work fine! well mythtv does not read KEY_[0-9]
but that's another issue ehe

Cheers,
Marc.

Hi,

oh well, I just checked with tvtime and Gerd's input-utils and what
happens in a shell.

For my understanding 0-9 and enter are still the reference keys,
also working without any other layer in between on 2.4x.

Didn't even had any idea on lirc for reference at all and won't have in
the future. (or why I should?)

Cheers,
Hermann

11/13/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Hi Marc,

Am Sonntag, den 12.11.2006, 02:48 +0100 schrieb Marc Fargas:
Hi hermann,
The 50ms works fine for me but I'll the 115 when I get home
tomorrow,
anyway the patch i currently on hands of nickolay and
mchehab but sure
they won't mind to change a line if 115 is better than 50.

I'll let you know if it works nicier.

Yes, please check. The repeat function doesn't work at all for
me with
ir_rc5_key_timeout=50. Hopefully we come in sync here too.

Cheers,
Hermann

nickolay: I added you to CC to let you know that maybe the
patch needs
to be changed before getting merged, also I think I forgot
to remove
some debbuing printk(), I'll check it also tomorrow at
home.

Cheers,
Marc.

11/11/06, hermann pitton <hermann-pitton (AT) arcor (DOT) dewrote:
Am Donnerstag, den 28.09.2006, 22:35 +0200 schrieb Marc
Fargas:
>< previous message removed >
Hi!

Marc, at least tested again.

The 50 ms key timeout disables the repeat function within
current
defaults. Sorry, was out of the window. Seems
ir_rc5_key_timeout=115
looks safe and still nice.

Since not any other single report, maybe Mark Weaver, who
all
contributed initially, is able to confirm or not that his
Nebula Digitv
is broken/unbroken with the current.

Cheers,
Hermann

I have posted a few cries for help for my 44981 problem, no responses. So now
I assume I am on the wrong list.

Which is the correct list?

Monday 27 November 2006 21:05, Jim Lill wrote:
What I get so far

xawtv -hwscan
This is xawtv-3.95, running on Linux/i686 (2.6.17-5mdv)
looking for available devices
/dev/video0: K [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Hauppauge (bt878))
flags: overlay capture tuner

but xawtv will bomb and lock things if I run it otherwise

no sound

scantv finds channels

Monday 27 November 2006 17:04, Jim Lill wrote:
Can anybody help, or point to who may be able to

So here's another piece of the puzzle, from lsmod

Am Freitag, den 01.12.2006, 20:53 -0500 schrieb Jim Lill:
I have posted a few cries for help for my 44981 problem, no responses. So now
I assume I am on the wrong list.

Which is the correct list?

Right list!

Hauppauge eeprom detection on bttv seems to have turned mad.
Nickolay catched a similar case, IIRC.

Sorry, I have nothing to test.

Hermann

Monday 27 November 2006 21:05, Jim Lill wrote:
What I get so far

xawtv -hwscan
This is xawtv-3.95, running on Linux/i686 (2.6.17-5mdv)
looking for available devices
/dev/video0: K [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Hauppauge (bt878))
flags: overlay capture tuner

but xawtv will bomb and lock things if I run it otherwise

no sound

scantv finds channels

Monday 27 November 2006 17:04, Jim Lill wrote:
Can anybody help, or point to who may be able to

So here's another piece of the puzzle, from lsmod

Thanks for reply! I'll keep hoping

Friday 01 December 2006 21:32, hermann pitton wrote:
Am Freitag, den 01.12.2006, 20:53 -0500 schrieb Jim Lill:
I have posted a few cries for help for my 44981 problem, no responses. So
now I assume I am on the wrong list.

Which is the correct list?

Right list!

Hauppauge eeprom detection on bttv seems to have turned mad.
Nickolay catched a similar case, IIRC.

Sorry, I have nothing to test.

Hermann

Monday 27 November 2006 21:05, Jim Lill wrote:
What I get so far

xawtv -hwscan
This is xawtv-3.95, running on Linux/i686 (2.6.17-5mdv)
looking for available devices
/dev/video0: K [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Hauppauge (bt878))
flags: overlay capture tuner

but xawtv will bomb and lock things if I run it otherwise

no sound

scantv finds channels

Monday 27 November 2006 17:04, Jim Lill wrote:
Can anybody help, or point to who may be able to

So here's another piece of the puzzle, from lsmod

Am Samstag, den 02.12.2006, 06:35 -0500 schrieb Jim Lill:
Thanks for reply! I'll keep hoping

Hi,

looking closer, the tuner is quite new only on your card, but was found
previously on WinTV PVR models by ivtv and should be fully operable.
Detection should be ok then, but revision E1B2 seems new, hence no reply
yet I guess. So you can look for people with this tuner also at ivtv.

Is there a chance that you are running the fglrx ATI binary driver?
Recent versions are known to cause trouble in mode,
also several chipsets don't play nice with
Hmm, you reported a well supported ATI TV Wonder VE also not working
previously. Needs tuner=2 on NTSC variants, as you probably know.

In case of overlay mode trouble bttv has a no_overlay=1 option to
disable it. You can force it also in .xawtv with "capture = grabdisplay"
to capture mode.
And "xawtv -nodga -remote -c /dev/video0" should be safe.

Both "tvtime" and "xawtv4" from cvs.bytesex.org use only capture/mmap
mode. Does scantv find channels as expected? Then the tuner works.

What ever is that rivatv for and why are ivtv and cx88 loaded? Does it
mean you have other cards working? Else I would also try with "ttv" on
runlevel 3 for a test or some recording, if X stays unstable.

The supported 44981 model has likely only the tuner changed. Sound is
MN only anyway, but was also reported.

Cheers,
Hermann

Friday 01 December 2006 21:32, hermann pitton wrote:
Am Freitag, den 01.12.2006, 20:53 -0500 schrieb Jim Lill:
I have posted a few cries for help for my 44981 problem, no responses. So
now I assume I am on the wrong list.

Which is the correct list?

Right list!

Hauppauge eeprom detection on bttv seems to have turned mad.
Nickolay catched a similar case, IIRC.

Sorry, I have nothing to test.

Hermann

Monday 27 November 2006 21:05, Jim Lill wrote:
What I get so far

xawtv -hwscan
This is xawtv-3.95, running on Linux/i686 (2.6.17-5mdv)
looking for available devices
/dev/video0: K [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Hauppauge (bt878))
flags: overlay capture tuner

but xawtv will bomb and lock things if I run it otherwise

no sound

scantv finds channels

Monday 27 November 2006 17:04, Jim Lill wrote:
Can anybody help, or point to who may be able to

So here's another piece of the puzzle, from lsmod

That's a big help, and will try those items and report results

Saturday 02 December 2006 15:50, hermann pitton wrote:
Am Samstag, den 02.12.2006, 06:35 -0500 schrieb Jim Lill:
Thanks for reply! I'll keep hoping

Hi,

looking closer, the tuner is quite new only on your card, but was found
previously on WinTV PVR models by ivtv and should be fully operable.
Detection should be ok then, but revision E1B2 seems new, hence no reply
yet I guess. So you can look for people with this tuner also at ivtv.

Is there a chance that you are running the fglrx ATI binary driver?
Recent versions are known to cause trouble in mode,
also several chipsets don't play nice with
Hmm, you reported a well supported ATI TV Wonder VE also not working
previously. Needs tuner=2 on NTSC variants, as you probably know.

In case of overlay mode trouble bttv has a no_overlay=1 option to
disable it. You can force it also in .xawtv with "capture = grabdisplay"
to capture mode.
And "xawtv -nodga -remote -c /dev/video0" should be safe.

Both "tvtime" and "xawtv4" from cvs.bytesex.org use only capture/mmap
mode. Does scantv find channels as expected? Then the tuner works.

What ever is that rivatv for and why are ivtv and cx88 loaded? Does it
mean you have other cards working? Else I would also try with "ttv" on
runlevel 3 for a test or some recording, if X stays unstable.

The supported 44981 model has likely only the tuner changed. Sound is
MN only anyway, but was also reported.

Cheers,
Hermann

Friday 01 December 2006 21:32, hermann pitton wrote:
Am Freitag, den 01.12.2006, 20:53 -0500 schrieb Jim Lill:
I have posted a few cries for help for my 44981 problem, no
responses. So now I assume I am on the wrong list.

Which is the correct list?

Right list!

Hauppauge eeprom detection on bttv seems to have turned mad.
Nickolay catched a similar case, IIRC.

Sorry, I have nothing to test.

Hermann

Monday 27 November 2006 21:05, Jim Lill wrote:
What I get so far

xawtv -hwscan
This is xawtv-3.95, running on Linux/i686 (2.6.17-5mdv)
looking for available devices
/dev/video0: K [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Hauppauge (bt878))
flags: overlay capture tuner

but xawtv will bomb and lock things if I run it otherwise

no sound

scantv finds channels

Monday 27 November 2006 17:04, Jim Lill wrote:
Can anybody help, or point to who may be able to

So here's another piece of the puzzle, from lsmod