support for key repeat with dib0700 ir receiver

Hi, my last messages have been almost ignored.. so I'm opening a new thread. Please refer to the other thread [wintv nova-t stick, dib0700 and remote controllers] for more info.

Here is a brief summary of the problem as far as I can understand:
- when a keypress event is received the device stores its data somewhere
- every 150ms dib0700_rc_query reads this data
- since there is nothing that resets device memory if no key is being pressed anymore device still stores the data from the last keypress event
- to prevent having false keypresses the driver reads rc5 toggle bit that changes from 0 to 1 and viceversa when a new key is pressed or when the same key is released and pressed again. So it ignores everything until the toggle bit changes. The right behavior should be "repeat last key until toggle bit changes", but cannot be done since last data still stored would be considered as a repeat even if nothing is pressed.
- this way it ignores even repeated key events (when a key is holded down)
- this approach is wrong because it works just for rc5 (losing repeat feature..) but doesn't work for example with nec remotes that don't set the toggle bit and use a different system.

The patch solves it calling dib0700_rc_setup after each poll resetting last key data from the device. I've also implemented repeated key feature (with repeat delay to avoid unwanted double hits) for rc-5 and nec protocols. It also contains some keymap for the remotes I've used for testing (a philipps compatible rc5 remote and a teac nec remote). They are far from being complete since I've used them just for testing.

Thanks for reading this,
Let me know what do you think about it,
Greets,

Filippo

diff -r f89d5927677a linux/drivers/media/dvb/dvb-usb/dib0700.h
@@ -37,6 +37,7 @@ struct dib0700_state {
 	u8 channel_state;
 	u16 mt2060_if1[2];
 	u8 rc_toggle;
+	u8 rc_counter;
 	u8 is_dib7000pc;
 };
 

@@ -44,12 +45,15 @@ extern int dib0700_ctrl_clock(struct dvb
 extern int dib0700_ctrl_clock(struct dvb_usb_device *d, u32 clk_MHz, u8 clock_out_gp3);
 extern int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8 txlen, u8 *rx, u8 rxlen);
 extern int dib0700_download_firmware(struct usb_device *udev, const struct firmware *fw);
+extern int dib0700_rc_setup(struct dvb_usb_device *d);
 extern int dib0700_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff);
 extern struct i2c_algorithm dib0700_i2c_algo;
 extern int dib0700_identify_state(struct usb_device *udev, struct dvb_usb_device_properties *props,
 			struct dvb_usb_device_description **desc, int *cold);
 
 extern int dib0700_device_count;
+extern int dvb_usb_dib0700_ir_proto;
 extern struct dvb_usb_device_properties dib0700_devices[];
 extern struct usb_device_id dib0700_usb_id_table[];
+
 #endif

diff -r f89d5927677a linux/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -13,7 +13,7 @@ module_param_named(debug,dvb_usb_dib0700
 module_param_named(debug,dvb_usb_dib0700_debug, int, 0644);
 MODULE_PARM_DESC(debug, "set debugging level (1=info,2=fw,4=fwdata,8=data (or-able))." DVB_USB_DEBUG_STATUS);
 
-static int dvb_usb_dib0700_ir_proto = 1;
+int dvb_usb_dib0700_ir_proto = 1;
 module_param(dvb_usb_dib0700_ir_proto, int, 0644);
 MODULE_PARM_DESC(dvb_usb_dib0700_ir_proto, "set ir protocol (0=NEC, 1=RC5 (default), 2=RC6).");
 

@@ -261,7 +261,7 @@ int dib0700_streaming_ctrl(struct dvb_us
 	return dib0700_ctrl_wr(adap->dev, b, 4);
 }
 
-static int dib0700_rc_setup(struct dvb_usb_device *d)
+int dib0700_rc_setup(struct dvb_usb_device *d)
 {
 	u8 rc_setup[3] = {REQUEST_SET_RC, dvb_usb_dib0700_ir_proto, 0};
 	int i = dib0700_ctrl_wr(d, rc_setup, 3);

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I'm quite interested in testing this patch, key repeats have been a nagging thing in the back of my mind.

I'll be testing this patch, and I'll document it in the wiki here:

http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500

I have a question about the quoted part.

Will this mess in any way with the current keycodes of my Nova-T-500 remote?

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Il giorno mar, 19/02/2008 alle 17.21 +0000, Nicolas Will ha scritto:

As far as I can tell the answer is no since the remotes I've mapped uses address 0x00 (standard philipps adress for TVs) and 0x72 that are not used in other keymaps. I cannot test it because I don't have a Hauppauge remote but I think nothing messy should happen.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Now this is rich!

I love it!

Key repeat works!

And the log flooding has stopped without the manual patch that was needed previously.

I hope you live in Aberdeen, Scotland, because I want to buy you a few beers right here and now! (though your name suggest a very different origin)

The patch applies cleanly on a fresh tree from 20mn ago. No warning while compiling. No weird stuff in the messages.

Done.

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

dib0700 users, please test as well and report.

v4l-dvb people, please review.

This, or an equivalent, needs to get inside the mainline.

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Hi all... I'm seeing exactly the same problems everyone else is (log flooding etc) except that I can't seem to get any keys picked by lirc or /dev/input/event7 at all...

Would this patch help in this case?

Cheers,

Matt

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

It would help with the flooding, most probably, though there was a patch for that available before.

As for LIRC not picking up the event, I would be tempted to say no, it won't help.

Are you certain that your LIRC is configured properly? Are you certain that your event number is the right one?

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I believe so... in so far as I can tell... I sent an email to this list about a week ago describing my problems, but there was no response. (subject: Compro Videomate U500). I've copied it below:

Hi all,

I've still been trying to get the inluded remote with my USB DVB-T Tuner working. It's a Compro Videomate U500 - it useses the dibcom 7000 chipset. After upgrading to Ubuntu 8.04 (hardy) I can now see the remote when I do a "cat /proc/bus/input/devices":

I: Bus=0003 Vendor=185b Product=1e78 Version=0100
N: Name="IR-receiver inside an USB DVB receiver"
P: Phys=usb-0000:00:02.1-4/ir0
S: Sysfs=/devices/pci0000:00/0000:00:02.1/usb1/1-4/input/input7
U: Uniq=
H: Handlers=kbd event7
B: EV=3
B: KEY=10afc332 2842845 0 0 0 4 80018000 2180 40000801 9e96c0 0 800200 ffc

However, I get now output running irrecord:

matthew@matthew-desktop:~$ sudo irrecord -H dev/input -d /dev/input/event7
lircd.conf

irrecord - application for recording IR-codes for usage with lirc

Copyright (C) 1998,1999 Christoph Bartelmus([email protected])

irrecord: initializing '/dev/input/event7'
This program will record the signals from your remote control and create a config file for lircd.

[SNIP]

Press RETURN to continue.

Hold down an arbitrary button.
irrecord: gap not found, can't continue
irrecord: closing '/dev/input/event7'

Likewise, if I start lirc with the following: "sudo /usr/sbin/lircd -H dev/input -d /dev/input/event7 -n" and then run irw, it will run fine but there will be no output at all.

Just looking through /var/log/syslog and noticed that it is filled with messages such as this:

Feb 10 14:00:17 matthew-desktop kernel: [ 6549.313822] dib0700: Unknown
remote controller key : 1E 42
Feb 10 14:00:18 matthew-desktop kernel: [ 6549.389724] dib0700: Unknown
remote controller key : 1E 42
Feb 10 14:00:18 matthew-desktop kernel: [ 6549.465623] dib0700: Unknown
remote controller key : 1E 42
Feb 10 14:00:18 matthew-desktop kernel: [ 6549.542087] dib0700: Unknown
remote controller key : 1E 42
Feb 10 14:00:18 matthew-desktop kernel: [ 6549.617927] dib0700: Unknown

remote controller key : 1E 42

There seems to be about 5 such messages every second, and the controller key listed at the end (1E 42 in this case) changes depending on the last button pressed on the remote. The same messages appear on dmesg. Obviously, as the code changes, the remote is being picked up by the kernel, but not being acted upon correctly. Is this normal, and does this mean something is working/not working? As stated above, I am still unable to get irrecord to show anything etc... I can't get it to work with or without lirc...

Any ideas?

Cheers,

Matt

Matthew Vermeulen
http://www.matthewv.id.au/
MatthewV @ irc.freenode.net

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Weird.

You went through all this, I guess:

http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500#Remote_control

And you are running a recent v4l-dvb tree, I assume.

I was never too lucky with irrecord on my system, IIRC.

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Ok - just thought I'd try the patch on the latest tree and see what happens... as expected, it put an end to the syslog flooding - but nothing really has improved... I still see a single error line in the syslog every time I press a key - so obviously the kernel is seeing something happen, but deciding it's unknown and not taking it any further. Something must be wrong with some mappings somewhere.. :S Here's the syslog output anyway - there is one line for every key press:

Feb 20 22:07:07 matthew-desktop kernel: [38161.388548] dib0700: Unknown
remote controller key: 12 7E  1  0
Feb 20 22:07:09 matthew-desktop kernel: [38162.678839] dib0700: Unknown
remote controller key: 18 7C  1  0
Feb 20 22:07:10 matthew-desktop kernel: [38162.906413] dib0700: Unknown
remote controller key: 18 7C  1  0
Feb 20 22:07:14 matthew-desktop kernel: [38165.183338] dib0700: Unknown
remote controller key: 1C 4D  1  0
Feb 20 22:07:18 matthew-desktop kernel: [38167.156040] dib0700: Unknown
remote controller key: 1F 7D  1  0
Feb 20 22:07:21 matthew-desktop kernel: [38168.598632] dib0700: Unknown

remote controller key: 19 43 1 0

This is very annoying because it seems that polling the syslog every 150ms might even give you something if you could work it out ;) Anyway.. any ideas where to now...?

Cheers,

Matt

Matthew Vermeulen
http://www.matthewv.id.au/
MatthewV @ irc.freenode.net

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Il giorno mer, 20/02/2008 alle 06.10 +0900, Matthew Vermeulen ha scritto:

Are you sure that the input device is receiving the events? Did you try evtest /dev/input/event7?
Is LIRC properly configured?
Are you using this file for lircd.conf
[http://linux.bytesex.org/v4l2/linux-input-layer-lircd.conf]?
Does irw catch some event?

Regarding log flooding, that should be fixed with this patch. Regards,
Filippo

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Il giorno mer, 20/02/2008 alle 09.22 +0100, Filippo Argiolas ha scritto:

I forgot to say to not use irrecord with dev/input driver since it's thinked to record raw events from remotes and doesn't work with input devices (usually it ends up with a lircd.conf file that interprets key press and release as separated events doubling each event). Just use the proper input-layer-lircd.conf.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I've got that file all set up, my hardware.conf for lirc is pasted below:

# /etc/lirc/hardware.conf
#
#Chosen Remote Control
REMOTE="Compro Videomate U500"
REMOTE_MODULES=""
REMOTE_DRIVER="devinput"
REMOTE_DEVICE="/dev/input/event7"
REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"
REMOTE_LIRCD_ARGS=""

#Chosen IR Transmitter
TRANSMITTER="None"
TRANSMITTER_MODULES=""
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""

#Enable lircd
START_LIRCD="true"

#Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false"

#Try to load appropriate kernel modules
LOAD_MODULES="true"

# Default configuration files for your hardware if any LIRCMD_CONF=""

#Forcing noninteractive reconfiguration
#If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""

My /etc/lirc/lircd.conf contains the contents of the lircd.conf file you linked to. Like I said previously, the only way I know the thing is seeing keypresses is by looking at dmesg or the syslog - evtest and irw pick up nothing, nor does xev or anything else I know to test with. I think lirc is properly configured, insofar as i can change the device to point to my multimedia keyboard using the devinput driver which can then be picked up by lirc...

I do know the actual tuner is receiving the remote keypresses because of the changes to the codes listed in syslog...

Hope this helps you (help me ;) )

Cheers,

Matt

Matthew Vermeulen
http://www.matthewv.id.au/
MatthewV @ irc.freenode.net

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I'm running Ubuntu Gutsy and my /etc/lirc/hardware.conf has wildly different variable names.

See what I have here:

http://www.youplala.net/~will/htpc/LIRC/

You are running Hardy, but I would't expect conf files to change so dramatically. I may be wrong, so I'll check.

Ah, yes they are... oh well, I'm wrong.

shouldn't that be dev/input, instead?

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Sorry forgot to reply to teh list....

On Feb 20, 2008 10:34 PM, Filippo Argiolas <[email protected]> wrote:
2008/2/20, Matthew Vermeulen <[email protected]>:

but

wrong

is

ideas

Ok, I didn't take a look at your previous messages, so I was thinking you were trying to make a hauppauge remote work. As far as I can see from this output and from dib0700 code your remote is not supported, hence there is no keymap hardcoded for it, hence the drivers outputs "unknow key" since it really doesn't know what to do with the key received.
Looking at your log it seems even that your remote is not an rc5 standard one since the toggle bit is always set to 1. Please try to press the same key many times (do not hold it down) and look if the unknown key is always the same and if the 3rd value changes alternatively from 0 to 1. If everything is ok you can start to take note of the values outputed by your keys and try to add a keymap on your own or send the results here. Note that if toggle bit is not working properly it the repeat feature would not work perfectly. I cannot do anything more since I don't have that remote control to make some test.

Filippo
Hmm...

Maybe you can make more sense of this - the is the result of pressing the same key repeatedly very rapidly (ie as fast as i can ;) )

Feb 20 22:39:48 matthew-desktop kernel: [39332.403671] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:48 matthew-desktop kernel: [39332.555469] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:48 matthew-desktop kernel: [39332.631930] dib0700: Unknown
remote controller key: 1F  A  1  0
Feb 20 22:39:48 matthew-desktop kernel: [39332.707392] dib0700: Unknown
remote controller key:  F 39  0  0
Feb 20 22:39:48 matthew-desktop kernel: [39332.783229] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:49 matthew-desktop kernel: [39332.859565] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:49 matthew-desktop kernel: [39333.010863] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:49 matthew-desktop kernel: [39333.086825] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:49 matthew-desktop kernel: [39333.238810] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:49 matthew-desktop kernel: [39333.315022] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:50 matthew-desktop kernel: [39333.390859] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:50 matthew-desktop kernel: [39333.542656] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:50 matthew-desktop kernel: [39333.618559] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:50 matthew-desktop kernel: [39333.694392] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:51 matthew-desktop kernel: [39333.846254] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:51 matthew-desktop kernel: [39333.922152] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:51 matthew-desktop kernel: [39333.998053] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:51 matthew-desktop kernel: [39334.149849] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:51 matthew-desktop kernel: [39334.225750] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:51 matthew-desktop kernel: [39334.301647] dib0700: Unknown
remote controller key: 1F  A  1  0
Feb 20 22:39:52 matthew-desktop kernel: [39334.453384] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:52 matthew-desktop kernel: [39334.529281] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:52 matthew-desktop kernel: [39334.681017] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:53 matthew-desktop kernel: [39334.832815] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:53 matthew-desktop kernel: [39334.908277] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:53 matthew-desktop kernel: [39335.060139] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:53 matthew-desktop kernel: [39335.136473] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:53 matthew-desktop kernel: [39335.211810] dib0700: Unknown
remote controller key: 13 7E  1  0
Feb 20 22:39:54 matthew-desktop kernel: [39335.364108] dib0700: Unknown

remote controller key: 13 7E 1 0

Not sure if that's what we were hoping for...

If it's going to help i can write out exactly what keys map to what code...

Cheers,

MAtt

Matthew Vermeulen
http://www.matthewv.id.au/
MatthewV @ irc.freenode.net

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Il giorno mer, 20/02/2008 alle 22.43 +0900, Matthew Vermeulen ha scritto:

It seems that your remote does not use the toggle bit. I don't know why since afaik it is a feature of the rc5 protocol.
By the way you can try to make some test writing the keymap on your own. Just edit dib0700_devices.c about at line 400, look at the other keymaps to have a model:
for example if the key you logged was the UP key you have to add a line like:
{ 0x13, 0x7E, KEY_UP },
and so on for the other keys, after that see if the keymap works with evtest.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Just got the latest v4l-dvb and used the patch and compiled. Yea, now holding down the button works! :)
Nice Job!

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Ok thanks I'll give that a shot and see what happens :)

Thanks a lot

Cheers,

Matt

Matthew Vermeulen
http://www.matthewv.id.au/
MatthewV @ irc.freenode.net

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Ok I just tried this with a few keys - and I know have volume control working on the remote... :D :D

Thanks so much... will let you know how the rest of it turns out!

Cheers,

Matt

Matthew Vermeulen
http://www.matthewv.id.au/
MatthewV @ irc.freenode.net

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Il giorno mar, 19/02/2008 alle 19.19 +0000, Nicolas Will ha scritto:

Great :)!

Nice, fixing this was not my first purpose but I'm glad it's solved.

Thanks! I'm pleased that someone else finds this useful!
I'm sorry I'm not from Scotland, I live in Italy but thank you for your offer, if I will travel to Aberdeen a beer would be great :D! Thanks also for mentioning me in the wiki.
Greets,
Filippo

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

That indeed looks OK to my eyes. I have to admit that I never took a look into the IR-code from DiBcom...

In any case, especially to that problem with "unknown key code" I think it is time to change the IR-behavior of the DVB-USB.

My problem is, I don't know how.

My naive idea would be, that the IR-code is reporting each key (as raw as possible) without mapping it to an event to the event interface and then someone, somewhere is interpreting it. Also forward any repeat-attribute.

Those endless tables in a lot of dvb-usb drivers are annoying me, firstly because they are endless and huge, and secondly, they are never complete. If there is an adequate replacement from userspace (somehow loading key-lists to the event-layer or in the worst case, to the dvb-usb-framework) would be a good solution.

Filippo, it seems you understand quite some thing around that. Do you know if what I'm saying is somehow possible?

Thanks,
Patrick.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I would suggest creating a netlink device which lircd (or similar) can read from. I haven't really looked further into it since I never really intended on having the IR support from the DVB devices; my brewing mythtv frontend system is both diskless and tunerless so I have a USB MCE IR dongle instead.

// J

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Be ready to discount my opinion, I'm not too good at those things.

Wouldn't going away from an event interface kill a possible direct link between the remote and X?

The way I see it, LIRC is an additional layer that may be one too many in most cases. From my point of view, it is a relative pain I could do without. But I may have tunnel vision by lack of knowledge.

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Hi,

I agree with you. I'm more looking for a solution with existing things. LIRC is not in kernel. I don't think we should do something specific, new. If there is nothing which can be done with the event system I think we should either extend it or just drop this idea.

What about HID?

Patrick.

--
Mail: [email protected]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

<ding>

That's the sound I made when you've pushed me to the limit of my competencies and clever remarks...

Others should jump in.

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Am Dienstag, den 19.02.2008, 23:29 +0100 schrieb Patrick Boettcher:

Hi,

for what we have ir-common then already?

Did not look in any details, but we have a hook there, also for RC5 remotes.

Cheers,
Hermann

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

I have an Gigabyte U8000 USB device, but can't find any linux support for it, wither by googling or following this list for several weeks.

lsusb output:
ID 1044:7002 Chu Yuen Enterprise Co., Ltd

According to this, this device is based on the Dibcom chipset.
http://murga-linux.com/puppy/viewtopic.php?t=24065
However, nothing seems to identify the device after following all the instructions.

I've tried the v4l suite, as well as a mythbuntu installation that works with a Dvico Fusion card.

Any better pointers or tips?

Thanks
lyalc

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.20.7/696 - Release Date: 16/02/2008
12:00 AM
 

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Yes, it would.

IMHO, the event interface does not match well with the reduced key set on a remote control. The keys are mapped in the driver which makes it difficult to customize. I'm not talking about the current problem with the mappings being hardcoded -- that could probably be solved without too much work.

The problem I see with the mapping taking place in the driver, is that the interpretation of the key presses and releases should be application-specific. If I'm in MythTV, I want one interpretation. In Evolution, the same keypress should be interpreted differently. Firefox has a third set of mappings. Lircd solves this problem for me, while the event interface creates one static mapping.

// J

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I demand that Patrick Boettcher may or may not have written...

However it's done, it should involve ir-common.

[snip]

| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Lobby friends, family, business, government.    WE'RE KILLING THE PLANET.

Try `stty 0' - it works much better.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Il giorno mar, 19/02/2008 alle 22.14 +0100, Patrick Boettcher ha scritto:

Patrick, your doubts are the same that I've felt when, a few days ago, I started looking at the dib0700 code.
I thinked why the driver decode events and binds them to a keymap instead of passing them raw to a user space tool (lirc?)? This prevents me to easily add a custom keymap for commercial remotes or even add a keymap for the remotes I have. So my device can decode most of my remote controllers but I cannot use them without editing the kernel code from development branch.
Later I understood the idea behind all this:
as Nicolas said binding keypress to an event interface turns the remote into a common input interface that works everywhere without additional user space tools and without difficult per-app configurations. So I think that current behavior is somewhat sane even if it lacks of a simple system (from a user point of view) to add more keymaps or edit current ones.
Please note that this behavior does not conflict with having different settings for different application, since this is achievable configuring lirc.

Another problem (as far as I understood with a quick look at the code) is that each different driver, being written by different people, faces the whole thing in different ways. As you said almost each driver has its own keymaps and its own methods to present events to the input interface.
For example I've seen some effort towards a unified system in dvb-usb-remote.c but dib0700 seems not to use it.

Regarding ir-common (as Darren suggested), after a quick look it seems more a framework for decoding remote events but it cannot be extended to all the devices since many of them do the decoding stuff on their own outputting directly decoded data that only has to be binded to a keymap and to an event device.
I think that all the drivers should output keypress decoded data in a common format to be passed to a common framework that binds it to common keymaps (better if user customizable in some way) and generates input events.

I don't know yet how this could be done and maybe it involves some work rewriting the ir stuff. So I think in the meanwhile my patch could be merged (if you think it's good) waiting for this work to be done. I'll take a deeper look at the code but I don't know if I'm able to do this thing, I've read kernel code a few days ago for the very first time and I've written the patch just because a I needed the repeat feature :)

Regards,

Filippo

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I second that.

I'm all for the greater good and Doing Things The Right Way (tm), but could this effort be spawned in a separate process for grander things?

Scratched an itch, heh? ;o)

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

2008/2/20, Nicolas Will <[email protected]>:

eheh, the best thing of free software is that you can always take the source and change it to reflect your needs :)

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Il giorno mer, 20/02/2008 alle 10.29 +0100, Filippo Argiolas ha scritto:

Hi all,
it's been a while since I've posted this patch. Looking at the whole thread the overall impression is that it works properly. No one complained about it causing any trouble. Many users tested it and reported it works good. I've been using it during this time and it seems fine to me. It also fixed the annoying bug that flooded syslog with unknown key messages.
So what does it need to be merged? Is a post in this list the proper way to ask for inclusion? I'm not familiar to mercurial so I've created the patch as I would do with a svn with "hg diff", it something wrong with it? Is there a better way to produce a patch for submission? I've attached a new patch where I've removed the keymaps I've used for testing since these are not complete and I doubt anyone could find them useful.
Please let me know what you think about it, thanks!
Best regards,

Filippo

diff -r 127f67dea087 linux/drivers/media/dvb/dvb-usb/dib0700.h
@@ -37,6 +37,7 @@ struct dib0700_state {
 	u8 channel_state;
 	u16 mt2060_if1[2];
 	u8 rc_toggle;
+	u8 rc_counter;
 	u8 is_dib7000pc;
 };
 

@@ -44,12 +45,15 @@ extern int dib0700_ctrl_clock(struct dvb
 extern int dib0700_ctrl_clock(struct dvb_usb_device *d, u32 clk_MHz, u8 clock_out_gp3);
 extern int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8 txlen, u8 *rx, u8 rxlen);
 extern int dib0700_download_firmware(struct usb_device *udev, const struct firmware *fw);
+extern int dib0700_rc_setup(struct dvb_usb_device *d);
 extern int dib0700_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff);
 extern struct i2c_algorithm dib0700_i2c_algo;
 extern int dib0700_identify_state(struct usb_device *udev, struct dvb_usb_device_properties *props,
 			struct dvb_usb_device_description **desc, int *cold);
 
 extern int dib0700_device_count;
+extern int dvb_usb_dib0700_ir_proto;
 extern struct dvb_usb_device_properties dib0700_devices[];
 extern struct usb_device_id dib0700_usb_id_table[];
+
 #endif

diff -r 127f67dea087 linux/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -13,7 +13,7 @@ module_param_named(debug,dvb_usb_dib0700
 module_param_named(debug,dvb_usb_dib0700_debug, int, 0644);
 MODULE_PARM_DESC(debug, "set debugging level (1=info,2=fw,4=fwdata,8=data (or-able))." DVB_USB_DEBUG_STATUS);
 
-static int dvb_usb_dib0700_ir_proto = 1;
+int dvb_usb_dib0700_ir_proto = 1;
 module_param(dvb_usb_dib0700_ir_proto, int, 0644);
 MODULE_PARM_DESC(dvb_usb_dib0700_ir_proto, "set ir protocol (0=NEC, 1=RC5 (default), 2=RC6).");
 

@@ -261,7 +261,7 @@ int dib0700_streaming_ctrl(struct dvb_us
 	return dib0700_ctrl_wr(adap->dev, b, 4);
 }
 
-static int dib0700_rc_setup(struct dvb_usb_device *d)
+int dib0700_rc_setup(struct dvb_usb_device *d)
 {
 	u8 rc_setup[3] = {REQUEST_SET_RC, dvb_usb_dib0700_ir_proto, 0};
 	int i = dib0700_ctrl_wr(d, rc_setup, 3);

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Filippo,

I have just read that:

hybrid).

I'll commit.

Maybe you will want to do it.

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Hi all,

I believe that we could we agree that this patch
* does not break anything,
* does what it says it should do,
* works fine,
* is coded properly wrt the v4l-dvb guideline,
* got enough feedback.

Could the powers that be merge it?

Many thanks.

Nico

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb