Re: IR Receiver on an Tevii S470
On Sun, 22 Nov 2009 19:17:59 -0500, Andy Walls wrote: > On Sun, 2009-11-22 at 21:32 +0100, Jean Delvare wrote: > > The fact that 0x30-0x37 and 0x50-0x5f all reply suggest that the bus > > driver erroneously returns success to "SMBus receive byte" transactions > > even when no device acks. This is a bug which should get fixed. If you > > point me to the I2C adapter driver code, I can take a look. > > Although Igor's information makes the original need for this moot, here > is the i2c adapter driver code: > > http://linuxtv.org/hg/v4l-dvb/file/8bff7e6c44d4/linux/drivers/media/video/cx23885/cx23885-i2c.c The results are not surprising: i2c_slave_did_ack() is only called for zero-length transactions. For all other transactions, no check is done. This is incorrect. I have written 3 patches for cx23885-i2c.c, the second one should fix this particular issue. The other two are cleanups. Patches are there if you want to take a look / give them a try: http://khali.linux-fr.org/devel/misc/cx23885/ These are totally untested, and I don't know anything about the hardware, so they might need some more work. But at least you should get the idea of what's missing. > Note the CX2388[578] chips have 3 I2C masters, 2 for external buses, and > 1 internal "on silicon" bus which the driver sets up as the 3rd bus. > The internal bus should at least have devices at 0x44 and 0x4c as > confirmed above. I'll note the comment in this file, that indicates the > "on silicon" I2C bus runs at 1.95 MHz: > > http://linuxtv.org/hg/v4l-dvb/file/8bff7e6c44d4/linux/drivers/media/video/cx23885/cx23885-core.c This is strange. For one thing, 1.95 MHz wouldn't be standard I2C but high-speed mode I2C. But more importantly, I fail to see how you could reach such speeds with a software-driven, byte-by-byte implementation. You need hardware buffers to reach high speeds on I2C. > The TeVii S470 card had what looked like at serial I2C EEPROM with the > A0, A1, and A2 pins all grounded, so I assume it is at 0x50 on one of > the CX23885's external I2C buses. Probably. Hopefully my patches will show you where it is. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
Hi Mario, On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote: Am Thu, 19 Nov 2009 16:37:18 +0100 (CET) schrieb Patrick Boettcher : On Sat, 7 Nov 2009, Mario Bachmann wrote: Hi there, I tried linux-2.6.31.5 and tuning still does not work: tuning to 73800 Hz video pid 0x0131, audio pid 0x0132 status 00 | signal | snr | ber 001f | unc | status 00 | signal | snr | ber 001f | unc | status 00 | signal | snr | ber 001f | unc | status 04 | signal | snr | ber 001f | unc | With some changes for the following file it works again: /usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c --- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100 +++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100 @@ -133,17 +133,14 @@ for (i = 0; i < num; i++) { /* write/read request */ - if (i+1 < num && (msg[i].flags & I2C_M_RD) == 0 - && (msg[i+1].flags & I2C_M_RD)) { + if (i+1 < num && (msg[i+1].flags & I2C_M_RD)) { if (dibusb_i2c_msg(d, msg[i].addr, msg[i].buf,msg[i].len, msg[i+1].buf,msg[i+1].len) < 0) break; i++; - } else if ((msg[i].flags & I2C_M_RD) == 0) { + } else if (dibusb_i2c_msg(d, msg[i].addr, msg[i].buf,msg[i].len,NULL,0) < 0) break; - } else - break; } Doing it is reverting a fix which avoids that uncontrolled i2c-access from userspace is destroying the USB-eeprom. I understand that this is breaking the tuning for your board. I'm just not understanding why. If you have some time to debug this issue, could you please try the following: One of the devices for your board is trying to do an I2c access which is falling into the last 'else'-branch - can you add a printk to find out which one it is? The access must be wrongly constructed and must be fixed in that driver. thanks, PS: if you don't have time to do it, please tell so. -- Patrick http://www.kernellabs.com/ I do not understand exactly. printk what? Could you please give me a complete piece of code with the printk command? Would be great! My printk-tries ends up in an "Oops". There is a } else break; sequence in dibusb_i2c_xfer instead of break, please add something like printk(KERN_ERR "- hello stupid I2C access \n"); recompile and load the new module, then check whether the line is appearing in /var/log/messages or /var/log/syslog when you tune the board. If this is the case, try to identify which device is issuing the access by printing the i2c-address of struct i2c_msg. HTH, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
flicker/jumpy at the bottom of the video
Hi , I am using latest gspca driver from dvb for camera driver. But I see bottom of the video has flickering/jumping effect. I have "Zippys" web camera, which is from Z-Star. I have loaded the following drivers. 1. gspca_zc3xx 44832 0 - Live 0xbf01f000 2. gspca_main 23840 1 gspca_zc3xx, Live 0xbf014000 3. videodev 36672 1 gspca_main, Live 0xbf006000 4. v4l1_compat 14788 1 videodev, Live 0xbf00 But otherwise there is no issue with video. I tested using gst-launch pipeline. regards Purush The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. This patch was generated and tested against v2.6.32-rc8. Similar patch was applied and tested using 2.6.27 which is similar to the latest dvb_net.c, except for network device statistical data structure. I suspect that this bug was introduced in kernel version 2.6.15, but had not verified it. Care has been taken not to introduce more bug by fixing this bug, but please scrutinize the code for I always produces buggy code. Signed-off-by: Ang Way Chuang --- diff --git a/drivers/media/dvb/dvb-core/dvb_net.c b/drivers/media/dvb/dvb-core/dvb_net.c index 0241a7c..7e0db86 100644 --- a/drivers/media/dvb/dvb-core/dvb_net.c +++ b/drivers/media/dvb/dvb-core/dvb_net.c @@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) "field: %u.\n", priv->ts_count, *from_where); /* Drop partly decoded SNDU, reset state, resync on PUSI. */ - if (priv->ule_skb) { - dev_kfree_skb( priv->ule_skb ); + if (priv->ule_skb || priv->ule_sndu_remain) { + if (priv->ule_skb) + dev_kfree_skb( priv->ule_skb ); dev->stats.rx_errors++; dev->stats.rx_frame_errors++; } @@ -533,6 +534,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) from_where += 2; } + priv->ule_sndu_remain = priv->ule_sndu_len + 2; /* * State of current TS: * ts_remain (remaining bytes in the current TS cell) @@ -542,6 +544,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) */ switch (ts_remain) { case 1: + priv->ule_sndu_remain--; priv->ule_sndu_type = from_where[0] << 8; priv->ule_sndu_type_1 = 1; /* first byte of ule_type is set. */ ts_remain -= 1; from_where += 1; @@ -555,6 +558,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) default: /* complete ULE header is present in current TS. */ /* Extract ULE type field. */ if (priv->ule_sndu_type_1) { + priv->ule_sndu_type_1 = 0; priv->ule_sndu_type |= from_where[0]; from_where += 1; /* points to payload start. */ ts_remain -= 1; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
Am Mon, 23 Nov 2009 10:01:36 +0100 (CET) schrieb Patrick Boettcher : > Hi Mario, > > On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote: > > > Am Thu, 19 Nov 2009 16:37:18 +0100 (CET) > > schrieb Patrick Boettcher : > > > >> On Sat, 7 Nov 2009, Mario Bachmann wrote: > >> > >>> Hi there, > >>> > >>> I tried linux-2.6.31.5 and tuning still does not work: > >>> tuning to 73800 Hz > >>> video pid 0x0131, audio pid 0x0132 > >>> status 00 | signal | snr | ber 001f | unc | > >>> status 00 | signal | snr | ber 001f | unc | > >>> status 00 | signal | snr | ber 001f | unc | > >>> status 04 | signal | snr | ber 001f | unc | > >>> > >>> With some changes for the following file it works again: > >>> /usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c > >>> > >>> diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c > >>> > >>> --- dibusb-common.c-ORIGINAL 2009-11-07 10:30:43.705344308 +0100 > >>> +++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100 > >>> @@ -133,17 +133,14 @@ > >>> > >>> for (i = 0; i < num; i++) { > >>> /* write/read request */ > >>> - if (i+1 < num && (msg[i].flags & I2C_M_RD) == 0 > >>> - && (msg[i+1].flags & I2C_M_RD)) { > >>> + if (i+1 < num && (msg[i+1].flags & I2C_M_RD)) { > >>> if (dibusb_i2c_msg(d, msg[i].addr, > >>> msg[i].buf,msg[i].len, > >>> msg[i+1].buf,msg[i+1].len) < 0) > >>> break; > >>> i++; > >>> - } else if ((msg[i].flags & I2C_M_RD) == 0) { > >>> + } else > >>> if (dibusb_i2c_msg(d, msg[i].addr, > >>> msg[i].buf,msg[i].len,NULL,0) < 0) > >>> break; > >>> - } else > >>> - break; > >>> } > >> > >> Doing it is reverting a fix which avoids that uncontrolled i2c-access from > >> userspace is destroying the USB-eeprom. > >> > >> I understand that this is breaking the tuning for your board. I'm just not > >> understanding why. > >> > >> If you have some time to debug this issue, could you please try the > >> following: > >> > >> One of the devices for your board is trying to do an I2c access which is > >> falling into the last 'else'-branch - can you add a printk to find out > >> which one it is? The access must be wrongly constructed and must be fixed > >> in that driver. > >> > >> thanks, > >> > >> PS: if you don't have time to do it, please tell so. > >> > >> -- > >> > >> Patrick > >> http://www.kernellabs.com/ > > > > I do not understand exactly. printk what? Could you please give me a > > complete piece of code with the printk command? Would be great! > > > > My printk-tries ends up in an "Oops". > > There is a > } else > break; > > sequence in dibusb_i2c_xfer > > instead of break, please add something like > > printk(KERN_ERR "- hello stupid I2C access \n"); > > recompile and load the new module, then check whether the line is > appearing in /var/log/messages or /var/log/syslog when you tune the board. > > If this is the case, try to identify which device is issuing the access by > printing the i2c-address of struct i2c_msg. > > HTH, > -- > > Patrick > http://www.kernellabs.com/ Hello Patrick, I tried it with Kernel 2.6.31.6 (same as before). I made the printk-change, recompiled and reloaded the modules and pluged in my Twinhan Magic Box... It definately jumps in the last else-branch and shows "hello stupid I2C access", but no KERN_ERR ?! dmesg usb 4-2: new full speed USB device using ohci_hcd and address 4 usb 4-2: configuration #1 chosen from 1 choice dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in cold state, will try to load a firmware usb 4-2: firmware: requesting dvb-usb-dibusb-5.0.0.11.fw dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw' usbcore: registered new interface driver dvb_usb_dibusb_mb usb 4-2: USB disconnect, address 4 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. usb 4-2: new full speed USB device using ohci_hcd and address 5 usb 4-2: configuration #1 chosen from 1 choice dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 16). DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device) DVB: registering adapter 0 frontend 0 (DiBcom 3000M-B DVB-T)... dibusb: This device has the Thomson Cable onboard. Which is default. - hello stupid I2C access input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:04.0/usb4/4-2/input/input5 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device successfully initialized and connecte
Re: dibusb-common.c FE_HAS_LOCK problem
On Mon, 23 Nov 2009, Mario Bachmann wrote: sequence in dibusb_i2c_xfer instead of break, please add something like printk(KERN_ERR "- hello stupid I2C access \n"); recompile and load the new module, then check whether the line is appearing in /var/log/messages or /var/log/syslog when you tune the board. If this is the case, try to identify which device is issuing the access by printing the i2c-address of struct i2c_msg. HTH, -- Patrick http://www.kernellabs.com/ Hello Patrick, I tried it with Kernel 2.6.31.6 (same as before). I made the printk-change, recompiled and reloaded the modules and pluged in my Twinhan Magic Box... It definately jumps in the last else-branch and shows "hello stupid I2C access", but no KERN_ERR ?! KERN_ERR is a prefix for printk to define the message priority to high. (to have it in syslog or messages) dibusb: This device has the Thomson Cable onboard. Which is default. - hello stupid I2C access Hmm... where is this coming from: can you write it like that: else { printk(...); dump_stack(); } Hey, without the break-command, tuning seems to work: $ tzap pro7 -r using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/grafrotz/.tzap/channels.conf' tuning to 73800 Hz video pid 0x0131, audio pid 0x0132 status 00 | signal | snr | ber 001f | unc | status 1f | signal 0b20 | snr 008d | ber 001f | unc | FE_HAS_LOCK status 1f | signal f4dd | snr 0077 | ber 0770 | unc | FE_HAS_LOCK status 1f | signal | snr 008c | ber 0770 | unc | FE_HAS_LOCK We are close to identify the drivers in charge for the stupid I2c access. -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
Am Mon, 23 Nov 2009 12:11:40 +0100 (CET) schrieb Patrick Boettcher : > On Mon, 23 Nov 2009, Mario Bachmann wrote: > >> sequence in dibusb_i2c_xfer > >> > >> instead of break, please add something like > >> > >> printk(KERN_ERR "- hello stupid I2C access \n"); > >> > >> recompile and load the new module, then check whether the line is > >> appearing in /var/log/messages or /var/log/syslog when you tune the board. > >> > >> If this is the case, try to identify which device is issuing the access by > >> printing the i2c-address of struct i2c_msg. > >> > >> HTH, > >> -- > >> > >> Patrick > >> http://www.kernellabs.com/ > > > > Hello Patrick, > > > > I tried it with Kernel 2.6.31.6 (same as before). > > > > I made the printk-change, recompiled and reloaded the modules and pluged in > > my Twinhan Magic Box... > > It definately jumps in the last else-branch and shows "hello stupid I2C > > access", but no KERN_ERR ?! > > KERN_ERR is a prefix for printk to define the message priority to high. > (to have it in syslog or messages) > > > dibusb: This device has the Thomson Cable onboard. Which is default. > > - hello stupid I2C access > > Hmm... where is this coming from: > > can you write it like that: > > else { > printk(...); > dump_stack(); > } > > > Hey, without the break-command, tuning seems to work: > > $ tzap pro7 -r > > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > > reading channels from file '/home/grafrotz/.tzap/channels.conf' > > tuning to 73800 Hz > > video pid 0x0131, audio pid 0x0132 > > status 00 | signal | snr | ber 001f | unc | > > status 1f | signal 0b20 | snr 008d | ber 001f | unc | > > FE_HAS_LOCK > > status 1f | signal f4dd | snr 0077 | ber 0770 | unc | > > FE_HAS_LOCK > > status 1f | signal | snr 008c | ber 0770 | unc | > > FE_HAS_LOCK > > We are close to identify the drivers in charge for the stupid I2c access. > > -- > > Patrick Boettcher - Kernel Labs > http://www.kernellabs.com/ I use this code now: } else printk(KERN_ERR "- hello stupid I2C access \n"); dump_stack(); } dmesg dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device successfully deinitialized and disconnected. usbcore: deregistering interface driver dvb_usb_dibusb_mb usb 4-2: new full speed USB device using ohci_hcd and address 6 usb 4-2: configuration #1 chosen from 1 choice dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in cold state, will try to load a firmware usb 4-2: firmware: requesting dvb-usb-dibusb-5.0.0.11.fw dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw' usbcore: registered new interface driver dvb_usb_dibusb_mb usb 4-2: USB disconnect, address 6 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. usb 4-2: new full speed USB device using ohci_hcd and address 7 usb 4-2: configuration #1 chosen from 1 choice dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 16). DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device) Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1 Call Trace: [] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common] [] ? i2c_transfer+0x91/0xe0 [] ? dib3000_read_reg+0x63/0x80 [dib3000mb] [] ? dib3000mb_attach+0x52/0xd4 [dib3000mb] [] ? dibusb_dib3000mb_frontend_attach+0x28/0x50 [dvb_usb_dibusb_mb] [] ? dvb_usb_adapter_frontend_init+0x13/0x100 [dvb_usb] [] ? dvb_usb_device_init+0x357/0x630 [dvb_usb] [] ? usb_match_one_id+0x31/0xb0 [] ? dibusb_probe+0x20/0xa0 [dvb_usb_dibusb_mb] [] ? usb_probe_interface+0xa2/0x170 [] ? __device_attach+0x0/0x60 [] ? driver_probe_device+0x80/0x180 [] ? __device_attach+0x29/0x60 [] ? __device_attach+0x0/0x60 [] ? bus_for_each_drv+0x5c/0x90 [] ? device_attach+0x85/0x90 [] ? bus_probe_device+0x25/0x40 [] ? device_add+0x4d9/0x5a0 [] ? usb_set_configuration+0x4a0/0x670 [] ? __device_attach+0x0/0x60 [] ? generic_probe+0x2f/0xb0 [] ? driver_probe_device+0x80/0x180 [] ? __device_attach+0x29/0x60 [] ? __device_attach+0x0/0x60 [] ? bus_for_each_drv+0x5c/0x90 [] ? device_attach+0x85/0x90 [] ? bus_probe_device+0x25/0x40 [] ? device_add+0x4d9/0x5a0 [] ? usb_new_device+0x5a/0xd0 [] ? hub_thread+0x7e0/0x1040 [] ? dequeue_task_fair+0x46/0x190 [] ? autoremove_wake_function+0x0/0x30 [] ? hub_thread+0x0/0x1040 [] ? kthread+0x9e/0xb0 [] ? child_rip+0xa/0x20 [] ? kthread+0x0/0xb0 [] ? child_rip+0x0/0x20 Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1 Call Trace: [] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common] [] ? i2c_transfer+0x91/0xe0 [] ? dib3000_read_reg+0x63/0x80 [dib3000mb] [] ? dib3000mb_attach+0x66/0xd4 [dib3000mb] [] ? dibusb_dib3000mb_fro
Re: V4L-DVB modules not loading
Stacey wrote: I've built the module okay. It installed correctly and copied the files into /lib/modules/2.6.31-14-generic/kernel/drivers/media/dvb/dvb-usb. After that I rebooted (since it was easier for me). Then I got to the "If the Modules load correctly" section to find that nothing has worked at all. I've checked my system log and it's recognising the USB device when I enter it but it isn't doing anything with it. The tutorial says you should be able to see the modules in /proc/modules but the modules folder doesn't even exist. The /dev/dvb/ folder has not been created either. Could you post the output of dmesg (just run the command 'dmesg' from a terminal) to the list, that should give us an idea of what is going on. You might want to do this after a clean reboot (with the adapter plugged in) so that there isn't too much information to wade through. Phil -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Jarod, Jarod Wilson wrote: > Core Linux Infrared Remote Control driver and infrastructure > > -Add Kconfig and Makefile bits > -Add device driver interface and headers > > The initial Kconfig and Makefile bits were done by Mario Limonciello for > the Ubuntu kernel, but have been tweaked a bit since then. Any errors are > probably my doing. > > Changes from prior submission: > - Now uses dev_dbg instead of its own dprintk > - Dynamic device numbers used > - sleep_on() ripped out in favor of wake bits > - Kconfig text improved and simplified > - All inline keywords removed where possible > - Obfuscating #defines and wrapper functions removed > - We call 'em lirc drivers now instead of lirc plugins Sorry to not analyze the code before. -ETOOBUSY here... Some generic comments first: 1) As I said before, this code adds a new input API. So, you should get input people's ack about it. It seems fine for me; 2) It would be really cool if you could submit a patch for DocBook as well, in order to describe the API. IMO, the better is to put it together with media infrastructure docbook, since, although it is possible to use lirc code with other hardware (and were originally designed for it), the current wider usage is together with V4L/DVB devices. The Docbooks are at kernel Documentation/DocBook/ directory. Also, we have a copy of it at our development tree (http://linuxtv.org/hg/v4l-dvb) at media-specs/ directory. 3) In general, the code looks sane for me. I have just a few small sugestions for improvements: > Index: b/drivers/input/lirc/lirc.h > === > --- /dev/null > +++ b/drivers/input/lirc/lirc.h Hmm... as you're defining the kernel userspace interface, it would be better to put the header under include/linux. > +#define LIRC_GET_FEATURES _IOR('i', 0x, unsigned long) > + > +#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, unsigned long) > +#define LIRC_GET_REC_MODE _IOR('i', 0x0002, unsigned long) > +#define LIRC_GET_SEND_CARRIER _IOR('i', 0x0003, unsigned int) > +#define LIRC_GET_REC_CARRIER _IOR('i', 0x0004, unsigned int) > +#define LIRC_GET_SEND_DUTY_CYCLE _IOR('i', 0x0005, unsigned int) > +#define LIRC_GET_REC_DUTY_CYCLE_IOR('i', 0x0006, unsigned int) > +#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, unsigned int) > + > +/* code length in bits, currently only for LIRC_MODE_LIRCCODE */ > +#define LIRC_GET_LENGTH_IOR('i', 0x000f, unsigned long) > + > +#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, unsigned long) > +#define LIRC_SET_REC_MODE _IOW('i', 0x0012, unsigned long) > +/* Note: these can reset the according pulse_width */ > +#define LIRC_SET_SEND_CARRIER _IOW('i', 0x0013, unsigned int) > +#define LIRC_SET_REC_CARRIER _IOW('i', 0x0014, unsigned int) > +#define LIRC_SET_SEND_DUTY_CYCLE _IOW('i', 0x0015, unsigned int) > +#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, unsigned int) > +#define LIRC_SET_TRANSMITTER_MASK _IOW('i', 0x0017, unsigned int) > + Hmm... unsigned int/unsigned long are not portable between different architectures. It would be better to use instead __u16/__u32/__u64. This way, you won't need a 32 bits compat layer. > + > +int lirc_register_driver(struct lirc_driver *d) > +{ > + struct irctl *ir; > + int minor; > + int bytes_in_key; > + unsigned int chunk_size; > + unsigned int buffer_size; > + int err; > + > + if (!d) { > + printk(KERN_ERR "lirc_dev: lirc_register_driver: " > +"driver pointer must be not NULL!\n"); > + err = -EBADRQC; > + goto out; > + } > + > + if (MAX_IRCTL_DEVICES <= d->minor) { > + dev_err(d->dev, "lirc_dev: lirc_register_driver: " > + "\"minor\" must be between 0 and %d (%d)!\n", > + MAX_IRCTL_DEVICES-1, d->minor); > + err = -EBADRQC; > + goto out; > + } > + > + if (1 > d->code_length || (BUFLEN * 8) < d->code_length) { > + dev_err(d->dev, "lirc_dev: lirc_register_driver: " > + "code length in bits for minor (%d) " > + "must be less than %d!\n", > + d->minor, BUFLEN * 8); > + err = -EBADRQC; > + goto out; > + } > + > + dev_dbg(d->dev, "lirc_dev: lirc_register_driver: sample_rate: %d\n", > + d->sample_rate); > + if (d->sample_rate) { > + if (2 > d->sample_rate || HZ < d->sample_rate) { > + dev_err(d->dev, "lirc_dev: lirc_register_driver: " > + "sample_rate must be between 2 and %d!\n", HZ); > + err = -EBADRQC; > + goto out; > + } > + if (!d->add_to_buf) {
Re: cx18: Reprise of YUV frame alignment improvements
On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote: > On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote: > > OK, here's my second attempt at getting rid of cx18 YUV frame alignment > > and tearing issues. > > > >http://linuxtv.org/hg/~awalls/cx18-yuv2 > > Hi Andy, > > I did some testing of your tree, using the following command > > mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc > > and then in parallel run a series of make commands of the v4l-dvb tree > > make -j2 && make unload && make -j2 && make unload && make -j2 && make > unload && make -j2 && make unload > > I was definitely seeing the corruption by doing this test before your > patches (both frame alignment and colorspace problems as PCI frames > were being dropped). After your change, I no longer see those > problems. The picture never became misaligned. Great. Thanks for the test. > However, it would > appear that some sort of regression may have been introduced with the > buffer handling. > > I was seeing a continuous reporting of the following in dmesg, even > *after* I stopped generating the load by running the make commands. > > [ 5175.703811] cx18-0: Could not find MDL 106 for stream encoder YUV > [ 5175.737380] cx18-0: Could not find MDL 111 for stream encoder YUV > [ 5175.804317] cx18-0: Skipped encoder YUV, MDL 96, 3 times - it must > have dropped out of rotation > [ 5175.804324] cx18-0: Skipped encoder YUV, MDL 101, 3 times - it must > have dropped out of rotation > [ 5175.904500] cx18-0: Skipped encoder YUV, MDL 96, 2 times - it must > have dropped out of rotation > [ 5176.204507] cx18-0: Skipped encoder YUV, MDL 101, 1 times - it must > have dropped out of rotation > [ 5176.204513] cx18-0: Skipped encoder YUV, MDL 96, 1 times - it must > have dropped out of rotation > [ 5176.204518] cx18-0: Could not find MDL 111 for stream encoder YUV Congratulations, you're seeing my buffer notification consistency check and sweep-up code in action. In the early days of cx18 maintenance by me, the driver would stop "capturing" a stream after anywhere from an hour to an hour and a half - black screen in MythTV. The original (current?) problem had a few components: 1. There is only *one* CPU2EPU mailbox and all DMA_DONE notifications come through it. 2. The CX23418 firmware does not wait long, at all, for you to pick up and acknowledge the CPU2EPU mailbox. It is a shorter window when you have multiple streams running. 3. If you cleanly miss an MDL notification, you don't know which MDL you missed and you don't know how many bytes were used in it. You drop it. 4. If you get a half written mailbox, like in your MDL 111 message above, then you have a mailbox consistency problem which is logged, but you also drop the MDL. 5. If you don't give an MDL back to the firmware, it never uses it again. That's why you see the sweep-up log messages. As soon as an MDL is skipped *on the order of the depth* of q_busy times, when looking for the currently DMA_DONE'd MDL, that skipped MDL must have been dropped. It is picked up and put back into rotation then. I will note that skipping an MDL 1 time and sweeping it up indicates the CX23418 firmware (q_busy) doesn't have a lot of MDLs to work with for that stream. You need to devote more memory to that stream or have the application read them off faster (so the MDL goes from q_full to q_free to q_busy). > I would expect to see frame drops while the system was under high > load, but I would expect that the errors would stop once the load fell > back to something reasonable. However, they continue to accumulate > even after the make commands stop and the only thing running on the > system is mplayer (with a CPU load of around 10%). You likely have: 1. a system-level interrupt handler latency problem and/or 2. the cx18-NN-out/M workrer threads aren't being woken up often enough to give MDL's back to the CX23418 firmware fast enough. For #1, if there is a linux driver sharing the CX23418 interrupt line (as shown by cat /proc/interrupts) then try unloading that driver, moving the CX23418 to another PCI slot, or somehow else keeping some other linux device driver from masking the CX23418's IRQ line for too long. The ahci disk controller driver is a known culprit with a time consuming error path in the top half of its IRQ handler. The easy solution to #2 is give enough memory for a few more MDLs for that stream with module parameters. > I think this tree is definitely on the right track, but it looks like > some edge case has been missed. What you see is normal. I can take a look at things, but it's generally a system level issue. One thing that can be done in the cx18 driver is to optimize the paths called by the out_work_handler, so that MDLs get back to the firmware with a minimum of delay. It's never been a big deal, with lots of MDLs for a stream, to have one or two MDLs tied up. With YUV only having very few MDLs, having an M
Re: dibusb-common.c FE_HAS_LOCK problem
On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote: [..] - hello stupid I2C access Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1 Call Trace: [] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common] [] ? i2c_transfer+0x91/0xe0 [] ? dib3000_write_reg+0x51/0x70 [dib3000mb] [] ? dvb_pll_attach+0xa9/0x238 [dvb_pll] [..] Voila. This is the access with makes the dvb-pll-driver not create the tuner driver. This is (I forgot the correct name) read-without-write-i2caccess. It is bad handled by the dibusb-driver and it can destroy the eeprom on the USB side. Please try whether the attached patch fixes the whole situation for you. If so, please send back a line like this: Tested-by: Your name thanks, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: Reprise of YUV frame alignment improvements
On Mon, 2009-11-23 at 07:12 -0500, Andy Walls wrote: > On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote: > > On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote: > > > OK, here's my second attempt at getting rid of cx18 YUV frame alignment > > > and tearing issues. > > > > > >http://linuxtv.org/hg/~awalls/cx18-yuv2 > > > > Hi Andy, > > > > I did some testing of your tree, using the following command > > > > mplayer /dev/video32 -demuxer rawvideo -rawvideo > > w=720:h=480:format=hm12:ntsc > > > > and then in parallel run a series of make commands of the v4l-dvb tree > > > > make -j2 && make unload && make -j2 && make unload && make -j2 && make > > unload && make -j2 && make unload > > > > I was definitely seeing the corruption by doing this test before your > > patches (both frame alignment and colorspace problems as PCI frames > > were being dropped). After your change, I no longer see those > > problems. The picture never became misaligned. > > Great. Thanks for the test. > > > > However, it would > > appear that some sort of regression may have been introduced with the > > buffer handling. > > > > I was seeing a continuous reporting of the following in dmesg, even > > *after* I stopped generating the load by running the make commands. > > > > [ 5175.703811] cx18-0: Could not find MDL 106 for stream encoder YUV > > [ 5175.737380] cx18-0: Could not find MDL 111 for stream encoder YUV > > [ 5175.804317] cx18-0: Skipped encoder YUV, MDL 96, 3 times - it must > > have dropped out of rotation > > [ 5175.804324] cx18-0: Skipped encoder YUV, MDL 101, 3 times - it must > > have dropped out of rotation > > [ 5175.904500] cx18-0: Skipped encoder YUV, MDL 96, 2 times - it must > > have dropped out of rotation > > [ 5176.204507] cx18-0: Skipped encoder YUV, MDL 101, 1 times - it must > > have dropped out of rotation > > [ 5176.204513] cx18-0: Skipped encoder YUV, MDL 96, 1 times - it must > > have dropped out of rotation > > [ 5176.204518] cx18-0: Could not find MDL 111 for stream encoder YUV > > Congratulations, you're seeing my buffer notification consistency check > and sweep-up code in action. > > In the early days of cx18 maintenance by me, the driver would stop > "capturing" a stream after anywhere from an hour to an hour and a half - > black screen in MythTV. The original (current?) problem had a few > components: > > 1. There is only *one* CPU2EPU mailbox and all DMA_DONE notifications > come through it. > > 2. The CX23418 firmware does not wait long, at all, for you to pick up > and acknowledge the CPU2EPU mailbox. It is a shorter window when you > have multiple streams running. > > 3. If you cleanly miss an MDL notification, you don't know which MDL you > missed and you don't know how many bytes were used in it. You drop it. > > 4. If you get a half written mailbox, like in your MDL 111 message > above, then you have a mailbox consistency problem which is logged, but > you also drop the MDL. > > 5. If you don't give an MDL back to the firmware, it never uses it > again. That's why you see the sweep-up log messages. As soon as an MDL > is skipped *on the order of the depth* of q_busy times, when looking for > the currently DMA_DONE'd MDL, that skipped MDL must have been dropped. > It is picked up and put back into rotation then. > > > I will note that skipping an MDL 1 time and sweeping it up indicates the > CX23418 firmware (q_busy) doesn't have a lot of MDLs to work with for > that stream. You need to devote more memory to that stream or have the > application read them off faster (so the MDL goes from q_full to q_free > to q_busy). > > > > > I would expect to see frame drops while the system was under high > > load, but I would expect that the errors would stop once the load fell > > back to something reasonable. However, they continue to accumulate > > even after the make commands stop and the only thing running on the > > system is mplayer (with a CPU load of around 10%). > > You likely have: > > 1. a system-level interrupt handler latency problem > > and/or > > 2. the cx18-NN-out/M workrer threads aren't being woken up often enough > to give MDL's back to the CX23418 firmware fast enough. One other possibility: 3. Once mplayer got behind, it stayed behind to render frames on a smooth timeline. That means more MDLs are intentionally being held on q_full by the application. > For #1, if there is a linux driver sharing the CX23418 interrupt line > (as shown by cat /proc/interrupts) then try unloading that driver, > moving the CX23418 to another PCI slot, or somehow else keeping some > other linux device driver from masking the CX23418's IRQ line for too > long. The ahci disk controller driver is a known culprit with a time > consuming error path in the top half of its IRQ handler. > > The easy solution to #2 is give enough memory for a few more MDLs for > that stream with module parameters. For number 3, for the YUV stream, we can make the
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Maybe my previous mail was lost.. Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 8 changesets: 01/08: gspca - pac7302: Remove redundant stream off command. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=1551c621e75f 02/08: gspca - pac7311/pac7302: Propagate error to higher level software. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=225a5744acf3 03/08: gspca - sonixj: Optimize code and add some comments. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=f174339c63cf 04/08: gspca - pac7302: Add red and blue balance control. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=4ddc02bee41d 05/08: gspca - main: Change version to 2.8.0. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=63484417ba70 06/08: gspca - main: Fix a compilation warning. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=da92c97c33c4 07/08: gspca - pac7302: Add white balance control. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=aa28984b1f48 08/08: gspca - pac7302: Handle return values in sd_start(). http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=3fd924da7091 gspca.c |6 - pac7302.c | 346 +++--- pac7311.c | 161 ++-- sonixj.c | 163 ++--- 4 files changed, 480 insertions(+), 196 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab wrote: > Jarod Wilson wrote: > 1) As I said before, this code adds a new input API. So, you should > get input people's ack about it. It seems fine for me; >> Index: b/drivers/input/lirc/lirc.h >> === >> --- /dev/null >> +++ b/drivers/input/lirc/lirc.h > > Hmm... as you're defining the kernel userspace interface, it would > be better to put the header under include/linux. It seems that I ran away from one important discussion here... In fact, it seemed better to start a thread to discuss the API issues in separate, an then adequate the code to do whatever decided. - The way the out-of-tree lirc driver works is by outputing (and inputing) a raw sequence of pulses and spaces that have several different IR protocols, like NEC, RC4, RC5, RC6 and pulse-distance protocols. On the other hand, the current Input event interface (and the IR drivers at V4L/DVB code) does is to have in-kernel code that converts those sequences or pulse/space into a keystroke representation, outputing it to userspace. To make things a little more complicated, it is also possible for some devices to output IR codes. Let's first discuss the IR input case. IMO, whatever we define for input, we should do also for output. There's some advantages and disadvantages of both strategies, being the most notable ones: Raw pulse/space allows reception of IR's from all different variations of the IR protocols. However: it means a more complex setup at userspace, since the user must use a daemon to decode IR code; user must inform the IR type and the kernel driver that will receive those keystrokes. Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. Considering the common case where the lirc driver will be associated with a media input device, the IR type can be detected automatically on kernel. However, advanced users may opt to use other IR types than what's provided with the device they bought. It should also be noticed that not all the already-existing IR drivers on kernel can provide a lirc interface, since several devices have their own IR decoding chips inside the hardware. On some cases, the hardware can be programmed to receive more than one IR protocol type, where on others, the manufacturer provides IR decoding capabilities only for the protocol they decided to provide together with their hardware. IMO, there are two different approaches that can be taken: 1) Just add lirc API as-is and let's have two different ways to get IR events on kernel, and have two different API's for IR; 2) create a lirc kernel API, and have a layer there to decode IR protocols and output them via the already existing input layer. In this case, all we need to do, in terms of API, is to add a way to set the IR protocol that will be decoded, and to enumberate the capabilities. The lirc API, will be an in-kernel API to communicate with the devices that don't have IR protocols decoding capabilities inside the hardware. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space or it would be better to standardize it to always use the existing input layer? Comments? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v2] lirc driver for Windows MCE IR transceivers
Jarod Wilson wrote: > lirc driver for Windows Media Center Ed. IR transceivers > > Successfully tested with the mce v2 transceiver and remote that shipped with a > Hauppauge HVR-1500 expresscard tuner and an mce v1 transceiver from an old HP > Media Center system. > > Changes from prior submission: > - both v1 and v2 transceivers supported by one driver now > - transmit works on the v1 devices > - support for several new devices > - now uses dev_dbg (and friends) instead of its own dprintk > > Signed-off-by: Jarod Wilson > Signed-off-by: Janne Grunau > CC: Christoph Bartelmus > Tested-by: Jarod Wilson > > --- > drivers/input/lirc/Kconfig |6 > drivers/input/lirc/Makefile |1 > drivers/input/lirc/lirc_mceusb.c | 1235 > +++ > 3 files changed, 1241 insertions(+), 1 deletion(-) > > Index: b/drivers/input/lirc/Kconfig > === > --- a/drivers/input/lirc/Kconfig > +++ b/drivers/input/lirc/Kconfig > @@ -11,6 +11,10 @@ menuconfig INPUT_LIRC > > if INPUT_LIRC > > -# Device-specific drivers go here > +config LIRC_MCEUSB > + tristate "Windows Media Center Ed. USB IR Transceiver" > + depends on LIRC_DEV && USB > + help > + Driver for Windows Media Center Ed. USB IR Transceivers > > endif > Index: b/drivers/input/lirc/Makefile > === > --- a/drivers/input/lirc/Makefile > +++ b/drivers/input/lirc/Makefile > @@ -4,3 +4,4 @@ > # Each configuration option enables a list of files. > > obj-$(CONFIG_INPUT_LIRC) += lirc_dev.o > +obj-$(CONFIG_LIRC_MCEUSB)+= lirc_mceusb.o > Index: b/drivers/input/lirc/lirc_mceusb.c > === > --- /dev/null > +++ b/drivers/input/lirc/lirc_mceusb.c > @@ -0,0 +1,1235 @@ > +/* > + * LIRC driver for Windows Media Center Edition USB Infrared Transceivers > + * > + * (C) by Martin A. Blatter > + * > + * Transmitter support and reception code cleanup. > + * (C) by Daniel Melander > + * > + * Original lirc_mceusb driver for 1st-gen device: > + * Copyright (c) 2003-2004 Dan Conti > + * > + * Original lirc_mceusb driver deprecated in favor of this driver, which > + * supports the 1st-gen device now too. Transmitting on the 1st-gen device > + * only functions on port #2 at the moment. > + * > + * Support for 1st-gen device added June 2009, > + * by Jarod Wilson > + * > + * Initial transmission support for 1st-gen device added August 2009, > + * by Patrick Calhoun > + * > + * Derived from ATI USB driver by Paul Miller and the original > + * MCE USB driver by Dan Conti (and now including chunks of the latter > + * relevant to the 1st-gen device initialization) > + * > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "lirc.h" > +#include "lirc_dev.h" > + > +#define DRIVER_VERSION "1.90" > +#define DRIVER_AUTHOR"Daniel Melander , " \ > + "Martin Blatter , " \ > + "Dan Conti " > +#define DRIVER_DESC "Windows Media Center Edition USB IR Transceiver " \ > + "driver for LIRC" > +#define DRIVER_NAME "lirc_mceusb" > + > +#define USB_BUFLEN 32 /* USB reception buffer length */ > +#define LIRCBUF_SIZE 256 /* LIRC work buffer length */ > + > +/* MCE constants */ > +#define MCE_CMDBUF_SIZE 384 /* MCE Command buffer length */ > +#define MCE_TIME_UNIT50 /* Approx 50us resolution */ > +#define MCE_CODE_LENGTH 5 /* Normal length of packet (with header) */ > +#define MCE_PACKET_SIZE 4 /* Normal length of packet (without header) */ > +#define MCE_PACKET_HEADER 0x84 /* Actual header format is 0x80 + num_bytes */ > +#define MCE_CONTROL_HEADER 0x9F /* MCE status header */ > +#define MCE_TX_HEADER_LENGTH 3 /* # of bytes in the initializing tx header */ > +#define MCE_MAX_CHANNELS 2 /* Two transmitters, hardware dependent? */ > +#define MCE_DEFAULT_TX_MASK 0x03 /* Val opts: TX1=0x01, TX2=0x02, ALL=0x03 */ > +#define MCE_PULSE_BIT0x80 /* Pulse bit,
Re: [PATCH 3/3 v2] lirc driver for SoundGraph iMON IR receivers and displays
Jarod Wilson wrote: > lirc driver for SoundGraph iMON IR receivers and displays > > Successfully tested with multiple devices with and without displays. > > +static struct usb_device_id imon_usb_id_table[] = { > + /* TriGem iMON (IR only) -- TG_iMON.inf */ > + { USB_DEVICE(0x0aa8, 0x8001) }, ... Another set of USB vendor ID's... this time, vendors weren't described. The same comment I did on patch 2/3 applies here... IMO, we should really try to create a global list of vendors/devices on kernel. Of course this is not a non-go issue, as it is already present on several other USB drivers. > + > + /* > + * Translate received data to pulse and space lengths. > + * Received data is active low, i.e. pulses are 0 and > + * spaces are 1. > + * > + * My original algorithm was essentially similar to > + * Changwoo Ryu's with the exception that he switched > + * the incoming bits to active high and also fed an > + * initial space to LIRC at the start of a new sequence > + * if the previous bit was a pulse. > + * > + * I've decided to adopt his algorithm. > + */ > + Before digging into all code details, am I wrong or this device has the pulse/space decoding inside the chip? In this case, we shouldn't really be converting their IR keystroke events into a pseudo set of pulse/space marks, but use the standard events interface. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
On Mon, 23 Nov 2009, Patrick Boettcher wrote: On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote: [..] - hello stupid I2C access Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1 Call Trace: [] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common] [] ? i2c_transfer+0x91/0xe0 [] ? dib3000_write_reg+0x51/0x70 [dib3000mb] [] ? dvb_pll_attach+0xa9/0x238 [dvb_pll] [..] Voila. This is the access with makes the dvb-pll-driver not create the tuner driver. This is (I forgot the correct name) read-without-write-i2caccess. It is bad handled by the dibusb-driver and it can destroy the eeprom on the USB side. Please try whether the attached patch fixes the whole situation for you. If so, please send back a line like this: Tested-by: Your name The patch attached. -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/diff -r 52da57b5e800 linux/drivers/media/dvb/dvb-usb/dibusb-common.c --- a/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Thu Nov 19 17:15:37 2009 +0100 +++ b/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Mon Nov 23 13:20:10 2009 +0100 @@ -142,8 +142,13 @@ } else if ((msg[i].flags & I2C_M_RD) == 0) { if (dibusb_i2c_msg(d, msg[i].addr, msg[i].buf,msg[i].len,NULL,0) < 0) break; - } else - break; + } else if (msg[i].addr != 0x50) { + /* 0x50 is the address of the eeprom - we need to protect it +* from dibusb's bad i2c implementation: reads without +* writing the offset before are forbidden */ + if (dibusb_i2c_msg(d, msg[i].addr, NULL, 0, msg[i].buf, msg[i].len) < 0) + break; + } } mutex_unlock(&d->i2c_mutex);
Re: dibusb-common.c FE_HAS_LOCK problem
Am Mon, 23 Nov 2009 14:19:10 +0100 (CET) schrieb Patrick Boettcher : > On Mon, 23 Nov 2009, Patrick Boettcher wrote: > > > On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote: > >> [..] > >> - hello stupid I2C access > >> Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1 > >> Call Trace: > >> [] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common] > >> [] ? i2c_transfer+0x91/0xe0 > >> [] ? dib3000_write_reg+0x51/0x70 [dib3000mb] > >> [] ? dvb_pll_attach+0xa9/0x238 [dvb_pll] > >> [..] > > > > Voila. > > > > This is the access with makes the dvb-pll-driver not create the tuner > > driver. > > > > This is (I forgot the correct name) read-without-write-i2caccess. It is bad > > handled by the dibusb-driver and it can destroy the eeprom on the USB side. > > > > Please try whether the attached patch fixes the whole situation for you. > > > > If so, please send back a line like this: > > > > Tested-by: Your name > > The patch attached. > > -- > > Patrick Boettcher - Kernel Labs > http://www.kernellabs.com/ Hi Patrick, your patch [dibusb-common-fix text/PLAIN (1054 bytes)] works here. Tested-by: Mario Bachmann Mario -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
Hans Verkuil wrote: > On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote: >> On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil wrote: >>> Hi Mauro, >>> >>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging >>> for the following: >>> >>> - Enable staging drivers by default when building v4l-dvb >>> - go7007: Add struct v4l2_device. >>> - s2250: Change module structure >>> - s2250: subdev conversion >>> - go7007: subdev conversion >> I have to admit that I am not sure that enabling staging drivers by >> default is a good idea. Staging drivers can be highly unstable, and >> can potentially damage hardware. I can totally imagine less >> experienced users with one of these devices building the current code >> and then being confused why their hardware is detected but is totally >> broken, or worse becomes damaged. > > If there are drivers in the staging tree that are so unreliable that they > can break the hardware, then those should be explicitly disabled, rather > than disabling all drivers in the staging tree. Or perhaps do not belong > there at all, or belong under the CONFIG_STAGING_BROKEN option. > > A driver like the go7007 is under active development, and it does work. It > only needs more cleanup before it can be moved to drivers/media/video, so > there was no reason that it should be disabled. > > Mauro, what are the risks of always compiling the tm6000 and cx25821 > drivers? Let me know if you think that either one or both should be > disabled for now and I'll make a patch for it. Even on upstream, drivers in staging are not compiled by default. To enable them, you need to answer yes to two questions. If the driver is OK, it shouldn't be in staging. The drivers that are in staging have issues that may be just coding style, can be the usage of wrong API's, or can be something serious. Also, since the criteria for a driver to be in staging are weak, they may not be prepared to be used widely, since they is likely doing some evil things, like duplicating existing code or creating non-accepted API's. In the go7007 case, among other things, the driver duplicates existing code at the saa7115 driver still uses the already deprecated DECODER ioctl's, and creates its own API (see go7007.h). So, I'm against of enabling any staging drivers to be compiled by default. Of course, in the case of auto-compilation tests tools like what you have, it is valuable if you add a patch there that enables their compilations inside the tool, but such patch shouldn't be committed at the development tree, simply because staging drivers aren't ready yet. The developers and testers of the staging drivers should manually enable it, after being warned about the risks of using them. > By not compiling you run the very high risk of bit rot: code getting > seriously out-of-sync with the rest of the tree. Possibly requiring a lot > of work later. If the driver is being maintained, this risk is low, since the driver maintainer will take care of it. It helps if your automatic build scripts could point that the driver compilation broke for some kernels, but, as the driver is being prepared for upstream submission, the developer should already being using the latest -rc kernel for its development. If they aren't maintained, they'll be removed from staging tree on a few kernel cycles, so patches fixing the compilation for those unmaintained drivers just means that someone lost his time fixing a dead driver. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab writes: > Event input has the advantage that the keystrokes will provide an unique > representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized key<>function mapping. > Considering the common case > where the lirc driver will be associated with a media input device, the > IR type can be detected automatically on kernel. However, advanced users may > opt to use other IR types than what's provided with the device they > bought. I think most users would want to do that, though I don't have hard numbers of course. Why use a number of RCs simultaneously while one will do? > It should also be noticed that not all the already-existing IR drivers > on kernel can provide a lirc interface, since several devices have > their own IR decoding chips inside the hardware. Right. I think they shouldn't use lirc interface, so it doesn't matter. > 2) create a lirc kernel API, and have a layer there to decode IR > protocols and output them via the already existing input layer. In > this case, all we need to do, in terms of API, is to add a way to set > the IR protocol that will be decoded, and to enumberate the > capabilities. The lirc API, will be an in-kernel API to communicate > with the devices that don't have IR protocols decoding capabilities > inside the hardware. I think this makes a lot of sense. But: we don't need a database of RC codes in the kernel (that's a lot of data, the user has to select the RC in use anyway so he/she can simply provide mapping e.g. RC5<>keycode). We do need RCx etc. protocols implementation in the kernel for the input layer. "lirc" interface: should we be sending time+on/off data to userspace, or the RC5 etc. should be implemented in the kernel? There is (?) only a handful of RC protocols, implementing them in the kernel and passing only information such as proto+group+code+press/release etc. should be more efficient. Perhaps the raw RCx data could be sent over the input layer as well? Something like the raw keyboard codes maybe? We need to handle more than one RC at a time, of course. > So, the basic question that should be decided is: should we create a new > userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code <> key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). > or it would be better to standardize it > to always use the existing input layer? I'd optionally provide a keyboard-alike input layer interface, with mappings (proto + raw code <> key) provided by userspace program. This should also work with multiple remotes. Then the existing drivers (such as saa713x with GPIO+IRQ-driven IR receiver (IR signal on/off generating IRQ)) should be converted. I think we shouldn't at this time worry about IR transmitters. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa wrote: > I think this makes a lot of sense. > But: we don't need a database of RC codes in the kernel (that's a lot of > data, the user has to select the RC in use anyway so he/she can simply > provide mapping e.g. RC5<>keycode). Just bear in mind that with the current in-kernel code, users do *not * have to manually select the RC code to use if they are using the default remote that shipped with the product. This helps alot for those unfamiliar with LIRC, since their product "works out of the box" with the remote the product came with. I agree though, that the user should be able to easily change the RC to be used if he/she decides to use a remote other than the default. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
> Hans Verkuil wrote: >> On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote: >>> On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil >>> wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging for the following: - Enable staging drivers by default when building v4l-dvb - go7007: Add struct v4l2_device. - s2250: Change module structure - s2250: subdev conversion - go7007: subdev conversion >>> I have to admit that I am not sure that enabling staging drivers by >>> default is a good idea. Staging drivers can be highly unstable, and >>> can potentially damage hardware. I can totally imagine less >>> experienced users with one of these devices building the current code >>> and then being confused why their hardware is detected but is totally >>> broken, or worse becomes damaged. >> >> If there are drivers in the staging tree that are so unreliable that >> they >> can break the hardware, then those should be explicitly disabled, rather >> than disabling all drivers in the staging tree. Or perhaps do not belong >> there at all, or belong under the CONFIG_STAGING_BROKEN option. >> >> A driver like the go7007 is under active development, and it does work. >> It >> only needs more cleanup before it can be moved to drivers/media/video, >> so >> there was no reason that it should be disabled. >> >> Mauro, what are the risks of always compiling the tm6000 and cx25821 >> drivers? Let me know if you think that either one or both should be >> disabled for now and I'll make a patch for it. > > Even on upstream, drivers in staging are not compiled by default. To > enable > them, you need to answer yes to two questions. > > If the driver is OK, it shouldn't be in staging. The drivers that are in > staging have issues that may be just coding style, can be the usage of > wrong > API's, or can be something serious. > > Also, since the criteria for a driver to be in staging are weak, they may > not > be prepared to be used widely, since they is likely doing some evil > things, > like duplicating existing code or creating non-accepted API's. > > In the go7007 case, among other things, the driver duplicates existing > code at > the saa7115 driver still uses the already deprecated DECODER ioctl's, and > creates its own API (see go7007.h). > > So, I'm against of enabling any staging drivers to be compiled by default. > > Of course, in the case of auto-compilation tests tools like what you have, > it is > valuable if you add a patch there that enables their compilations inside > the > tool, but such patch shouldn't be committed at the development tree, > simply > because staging drivers aren't ready yet. > > The developers and testers of the staging drivers should manually enable > it, > after being warned about the risks of using them. > >> By not compiling you run the very high risk of bit rot: code getting >> seriously out-of-sync with the rest of the tree. Possibly requiring a >> lot >> of work later. > > If the driver is being maintained, this risk is low, since the driver > maintainer > will take care of it. It helps if your automatic build scripts could point > that > the driver compilation broke for some kernels, but, as the driver is being > prepared > for upstream submission, the developer should already being using the > latest -rc kernel > for its development. > > If they aren't maintained, they'll be removed from staging tree on a few > kernel > cycles, so patches fixing the compilation for those unmaintained drivers > just > means that someone lost his time fixing a dead driver. I've reverted that patch and respun my v4l-dvb-staging tree. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: flicker/jumpy at the bottom of the video
Purushottam R S wrote: Hi , I am using latest gspca driver from dvb for camera driver. But I see bottom of the video has flickering/jumping effect. I have "Zippys" web camera, which is from Z-Star. I have loaded the following drivers. 1. gspca_zc3xx 44832 0 - Live 0xbf01f000 2. gspca_main 23840 1 gspca_zc3xx, Live 0xbf014000 3. videodev 36672 1 gspca_main, Live 0xbf006000 4. v4l1_compat 14788 1 videodev, Live 0xbf00 But otherwise there is no issue with video. I tested using gst-launch pipeline. Can you try using vlc application. I have the same effect using v4l1 compat api Michael regards Purush The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AltoBeam ATBM8830 GB20600-2006(DMB-TH) demodulator
David T. L. Wong wrote: > Hi, > > This patch adds support for Maxim MAX2165 silicon tuner. > > It is tested on Mygica X8558Pro, which has MAX2165, ATBM8830 and CX23885 Applied, thanks. Please submit a patch to fix this warning: /home/v4l/master/v4l/atbm8830.c:166: warning: 'set_agc_config' defined but not used Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote control support ? See http://marc.info/?l=linux-kernel&m=122591465821297&w=2 and all discussions around it. Regards, Emmanuel. --- Laposte.net fête ses 10 ans ! Gratuite, garantie à vie et déjà utilisée par des millions d'internautes... vous aussi, pour votre adresse e-mail, choisissez laposte.net. Laposte.net, bien + qu'une messagerie -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Multifrontend support for saa7134
Hi Lukáš/Hermann, Any news about this patch? I'll mark it as RFC at the patchwork, since it seems that this is not finished yet. Please let me know if you make some progress. > @@ -1352,6 +1353,7 @@ struct saa7134_board saa7134_boards[] = > .tuner_addr = ADDR_UNSET, > .radio_addr = ADDR_UNSET, >.mpeg = SAA7134_MPEG_DVB, > + .num_frontends = 1, >.inputs = {{ >.name = name_tv, >.vmux = 1, Just one suggestion here: it is a way better to assume that an "uninitialized" value (e. g. num_frontends = 0) for num_frontends to mean that just one frontend exists. This saves space at the initialization segment of the module and avoids the risk of someone forget to add num_frontends=0. cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: lgs8gxx: remove firmware for lgs8g75
Ben Hutchings wrote: > The recently added support for lgs8g75 included some 8051 machine code > without accompanying source code. Replace this with use of the > firmware loader. > > Compile-tested only. > > Signed-off-by: Ben Hutchings > --- > This firmware can be added to linux-firmware.git instead, and I will be > requesting that very shortly. Had you submitted a patch for it already? Could you please test the patch before we commit it at the tree? > > Ben. > > drivers/media/dvb/frontends/Kconfig |1 + > drivers/media/dvb/frontends/lgs8gxx.c | 50 ++-- > 2 files changed, 11 insertions(+), 40 deletions(-) > > diff --git a/drivers/media/dvb/frontends/Kconfig > b/drivers/media/dvb/frontends/Kconfig > index d7c4837..26b00ab 100644 > --- a/drivers/media/dvb/frontends/Kconfig > +++ b/drivers/media/dvb/frontends/Kconfig > @@ -553,6 +553,7 @@ config DVB_LGS8GL5 > config DVB_LGS8GXX > tristate "Legend Silicon LGS8913/LGS8GL5/LGS8GXX DMB-TH demodulator" > depends on DVB_CORE && I2C > + select FW_LOADER > default m if DVB_FE_CUSTOMISE > help > A DMB-TH tuner module. Say Y when you want to support this frontend. > diff --git a/drivers/media/dvb/frontends/lgs8gxx.c > b/drivers/media/dvb/frontends/lgs8gxx.c > index eabcadc..1bfcf85 100644 > --- a/drivers/media/dvb/frontends/lgs8gxx.c > +++ b/drivers/media/dvb/frontends/lgs8gxx.c > @@ -24,6 +24,7 @@ > */ > > #include > +#include > > #include "dvb_frontend.h" > > @@ -46,42 +47,6 @@ module_param(fake_signal_str, int, 0644); > MODULE_PARM_DESC(fake_signal_str, "fake signal strength for LGS8913." > "Signal strength calculation is slow.(default:on)."); > > -static const u8 lgs8g75_initdat[] = { > - 0x01, 0x30, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, > - 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, > - 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, > - 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, > - 0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, > - 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, > - 0xE4, 0xF5, 0xA8, 0xF5, 0xB8, 0xF5, 0x88, 0xF5, > - 0x89, 0xF5, 0x87, 0x75, 0xD0, 0x00, 0x11, 0x50, > - 0x11, 0x50, 0xF4, 0xF5, 0x80, 0xF5, 0x90, 0xF5, > - 0xA0, 0xF5, 0xB0, 0x75, 0x81, 0x30, 0x80, 0x01, > - 0x32, 0x90, 0x80, 0x12, 0x74, 0xFF, 0xF0, 0x90, > - 0x80, 0x13, 0x74, 0x1F, 0xF0, 0x90, 0x80, 0x23, > - 0x74, 0x01, 0xF0, 0x90, 0x80, 0x22, 0xF0, 0x90, > - 0x00, 0x48, 0x74, 0x00, 0xF0, 0x90, 0x80, 0x4D, > - 0x74, 0x05, 0xF0, 0x90, 0x80, 0x09, 0xE0, 0x60, > - 0x21, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x1B, 0x12, > - 0x00, 0xDD, 0x14, 0x60, 0x15, 0x12, 0x00, 0xDD, > - 0x14, 0x60, 0x0F, 0x12, 0x00, 0xDD, 0x14, 0x60, > - 0x09, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x03, 0x12, > - 0x00, 0xDD, 0x90, 0x80, 0x42, 0xE0, 0x60, 0x0B, > - 0x14, 0x60, 0x0C, 0x14, 0x60, 0x0D, 0x14, 0x60, > - 0x0E, 0x01, 0xB3, 0x74, 0x04, 0x01, 0xB9, 0x74, > - 0x05, 0x01, 0xB9, 0x74, 0x07, 0x01, 0xB9, 0x74, > - 0x0A, 0xC0, 0xE0, 0x74, 0xC8, 0x12, 0x00, 0xE2, > - 0xD0, 0xE0, 0x14, 0x70, 0xF4, 0x90, 0x80, 0x09, > - 0xE0, 0x70, 0xAE, 0x12, 0x00, 0xF6, 0x12, 0x00, > - 0xFE, 0x90, 0x00, 0x48, 0xE0, 0x04, 0xF0, 0x90, > - 0x80, 0x4E, 0xF0, 0x01, 0x73, 0x90, 0x80, 0x08, > - 0xF0, 0x22, 0xF8, 0x7A, 0x0C, 0x79, 0xFD, 0x00, > - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD9, > - 0xF6, 0xDA, 0xF2, 0xD8, 0xEE, 0x22, 0x90, 0x80, > - 0x65, 0xE0, 0x54, 0xFD, 0xF0, 0x22, 0x90, 0x80, > - 0x65, 0xE0, 0x44, 0xC2, 0xF0, 0x22 > -}; > - > /* LGS8GXX internal helper functions */ > > static int lgs8gxx_write_reg(struct lgs8gxx_state *priv, u8 reg, u8 data) > @@ -627,9 +592,14 @@ static int lgs8913_init(struct lgs8gxx_state *priv) > > static int lgs8g75_init_data(struct lgs8gxx_state *priv) > { > - const u8 *p = lgs8g75_initdat; > + const struct firmware *fw; > + int rc; > int i; > > + rc = request_firmware(&fw, "lgs8g75.fw", &priv->i2c->dev); > + if (rc) > + return rc; > + > lgs8gxx_write_reg(priv, 0xC6, 0x40); > > lgs8gxx_write_reg(priv, 0x3D, 0x04); > @@ -640,16 +610,16 @@ static int lgs8g75_init_data(struct lgs8gxx_state *priv) > lgs8gxx_write_reg(priv, 0x3B, 0x00); > lgs8gxx_write_reg(priv, 0x38, 0x00); > > - for (i = 0; i < sizeof(lgs8g75_initdat); i++) { > + for (i = 0; i < fw->size; i++) { > lgs8gxx_write_reg(priv, 0x38, 0x00); > lgs8gxx_write_reg(priv, 0x3A, (u8)(i&0xff)); > lgs8gxx_write_reg(priv, 0x3B, (u8)(i>>8)); > - lgs8gxx_write_reg(priv, 0x3C, *p); > - p++; > + lgs8gxx_write_reg(priv, 0x3C, fw->data[i]); > } > > lgs8gxx_write_reg(priv, 0x38, 0x00); > > + release_firmware(fw); > return 0; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vg
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> Event input has the advantage that the keystrokes will provide an unique >> representation that is independent of the device. > > This can hardly work as the only means, the remotes have different keys, > the user almost always has to provide customized key<>function mapping. Modern input drivers in the mainline kernel have a scancode-to-keycode translation table (or equivalent) which can be overwritten by userspace. The mechanism to do that is the EVIOCSKEYCODE ioctl. (This is no recommendation for lirc. I have no idea whether a pulse/space -> scancode -> keycode translation would be practical there.) -- Stefan Richter -=-==--= =-== =-=== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
Hans Verkuil wrote: >> Hans Verkuil wrote: >>> On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote: On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil wrote: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging > for the following: > > - Enable staging drivers by default when building v4l-dvb > - go7007: Add struct v4l2_device. > - s2250: Change module structure > - s2250: subdev conversion > - go7007: subdev conversion I have to admit that I am not sure that enabling staging drivers by default is a good idea. Staging drivers can be highly unstable, and can potentially damage hardware. I can totally imagine less experienced users with one of these devices building the current code and then being confused why their hardware is detected but is totally broken, or worse becomes damaged. >>> If there are drivers in the staging tree that are so unreliable that >>> they >>> can break the hardware, then those should be explicitly disabled, rather >>> than disabling all drivers in the staging tree. Or perhaps do not belong >>> there at all, or belong under the CONFIG_STAGING_BROKEN option. >>> >>> A driver like the go7007 is under active development, and it does work. >>> It >>> only needs more cleanup before it can be moved to drivers/media/video, >>> so >>> there was no reason that it should be disabled. >>> >>> Mauro, what are the risks of always compiling the tm6000 and cx25821 >>> drivers? Let me know if you think that either one or both should be >>> disabled for now and I'll make a patch for it. >> Even on upstream, drivers in staging are not compiled by default. To >> enable >> them, you need to answer yes to two questions. >> >> If the driver is OK, it shouldn't be in staging. The drivers that are in >> staging have issues that may be just coding style, can be the usage of >> wrong >> API's, or can be something serious. >> >> Also, since the criteria for a driver to be in staging are weak, they may >> not >> be prepared to be used widely, since they is likely doing some evil >> things, >> like duplicating existing code or creating non-accepted API's. >> >> In the go7007 case, among other things, the driver duplicates existing >> code at >> the saa7115 driver still uses the already deprecated DECODER ioctl's, and >> creates its own API (see go7007.h). >> >> So, I'm against of enabling any staging drivers to be compiled by default. >> >> Of course, in the case of auto-compilation tests tools like what you have, >> it is >> valuable if you add a patch there that enables their compilations inside >> the >> tool, but such patch shouldn't be committed at the development tree, >> simply >> because staging drivers aren't ready yet. >> >> The developers and testers of the staging drivers should manually enable >> it, >> after being warned about the risks of using them. >> >>> By not compiling you run the very high risk of bit rot: code getting >>> seriously out-of-sync with the rest of the tree. Possibly requiring a >>> lot >>> of work later. >> If the driver is being maintained, this risk is low, since the driver >> maintainer >> will take care of it. It helps if your automatic build scripts could point >> that >> the driver compilation broke for some kernels, but, as the driver is being >> prepared >> for upstream submission, the developer should already being using the >> latest -rc kernel >> for its development. >> >> If they aren't maintained, they'll be removed from staging tree on a few >> kernel >> cycles, so patches fixing the compilation for those unmaintained drivers >> just >> means that someone lost his time fixing a dead driver. > > I've reverted that patch and respun my v4l-dvb-staging tree. Thanks. I should be pulling from all pending requests today, after finishing the pending stuff at patchwork. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
2009/11/23 Devin Heitmueller : > Just bear in mind that with the current in-kernel code, users do *not > * have to manually select the RC code to use if they are using the > default remote that shipped with the product. This could still happen, if LIRC checks the identifiers of the reciving device, and has a database that tells it mappings between those devices and the remote controls that shipped with them. However, it occours to me that the IR circumstances map pretty well to what happens with ps/2 and serial devices now: 1: There are a variety of drivers for serio computer-side hardware, each of which speaks the serio interface to the next-higher level. These corrospond to the drivers for IR recievers. 2: There's a raw serio interface, for those wishing to do strange things. 3: There's also a variety of things that take data, using the kernel serio API, and decode it into input events -- the ps2 keyboard driver, the basic mouse driver, the advanced mice drivers. This is where the interface falls down a little bit -- the ps2 keyboard driver is the closest analogue to what I'm suggesting. The ps2 keyboard driver creates scancode events, which map nicely to what the keyboard is sending -- these are, for ex, rc5 codes. It will also produce key-up/key-down events, if it has a keymap loaded. (This is the difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned to it at boottime, so it works out-of-box. This isn't really possible with an IR remote -- though perhaps rc5 is standarized enough, I don't think other protocols neccessarly are.) Userspace would have to load a keymap; those don't really belong in kernel code. Of course, userspace could look at the device identifiers to pick a reasonable default keymap if it's not configured to load another, solving the out-of-box experince. Why is this such a contentious point? I can understand wanting to keep uncommon decoding algos out of the kernel, and keymaps, but at the same time, they are currently there, in multiple drivers, and while colesing them into a single place each makes sense, I'm not convinced that moving them out completely makes all that much sense. Having an explicit layer between the raw pulse/space layer and the decoders means that usespace can hook in there, and create scancode events, if it wishes to, but for the majority of remotes that use just a couple of encoding schemes, the code can stay in the kernel. Of course, devices that do the decoding in hardware would not implement the raw interface, but simply create the scancode/keycode events. -=- James Mastros -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
2009/11/23 Devin Heitmueller : > Just bear in mind that with the current in-kernel code, users do *not > * have to manually select the RC code to use if they are using the > default remote that shipped with the product. This could still happen, if LIRC checks the identifiers of the reciving device, and has a database that tells it mappings between those devices and the remote controls that shipped with them. However, it occours to me that the IR circumstances map pretty well to what happens with ps/2 and serial devices now: 1: There are a variety of drivers for serio computer-side hardware, each of which speaks the serio interface to the next-higher level. These corrospond to the drivers for IR recievers. 2: There's a raw serio interface, for those wishing to do strange things. 3: There's also a variety of things that take data, using the kernel serio API, and decode it into input events -- the ps2 keyboard driver, the basic mouse driver, the advanced mice drivers. This is where the interface falls down a little bit -- the ps2 keyboard driver is the closest analogue to what I'm suggesting. The ps2 keyboard driver creates scancode events, which map nicely to what the keyboard is sending -- these are, for ex, rc5 codes. It will also produce key-up/key-down events, if it has a keymap loaded. (This is the difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned to it at boottime, so it works out-of-box. This isn't really possible with an IR remote -- though perhaps rc5 is standarized enough, I don't think other protocols neccessarly are.) Userspace would have to load a keymap; those don't really belong in kernel code. Of course, userspace could look at the device identifiers to pick a reasonable default keymap if it's not configured to load another, solving the out-of-box experince. -=- James Mastros -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: Reprise of YUV frame alignment improvements
On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls wrote: > 5. If you don't give an MDL back to the firmware, it never uses it > again. That's why you see the sweep-up log messages. As soon as an MDL > is skipped *on the order of the depth* of q_busy times, when looking for > the currently DMA_DONE'd MDL, that skipped MDL must have been dropped. > It is picked up and put back into rotation then. Perhaps I am misinterpreting the definition of "sweep-up" in this context. Don't the buffers get forcefully returned to the pool at that point? If so, why would I see the same error over and over long after the CPU utilization has dropped back to a reasonable level. I feel like I must be missing something here. 1. CPU load goes up (ok) 2. Packets start to get dropped (expected) 3. CPU load goes back down (ok) 4. Packets continue to get dropped and never recycled, even after minutes of virtually no CPU load? I can totally appreciate the notion that the video would look choppy when the system is otherwise under high load, but my expectation would be that once the load drops back to 0, the video should look fine (perhaps with some small window of time where it is still recovering). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the > following: > > - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. Something went wrong here: $ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1 linux/Documentation/DocBook/v4l/pixfmt.xml |5 linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097 2 files changed, 554 insertions(+), 548 deletions(-) Why a simple patch like this is changing 1097 lines at videodev2.h.xml? Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 12:05 PM, James Mastros wrote: > 2009/11/23 Devin Heitmueller : >> Just bear in mind that with the current in-kernel code, users do *not >> * have to manually select the RC code to use if they are using the >> default remote that shipped with the product. > This could still happen, if LIRC checks the identifiers of the > reciving device, and has a database that tells it mappings between > those devices and the remote controls that shipped with them. > However, it occours to me that the IR circumstances map pretty well to > what happens with ps/2 and serial devices now: > > 1: There are a variety of drivers for serio computer-side hardware, > each of which speaks the serio interface to the next-higher level. > These corrospond to the drivers for IR recievers. > 2: There's a raw serio interface, for those wishing to do strange things. > 3: There's also a variety of things that take data, using the kernel > serio API, and decode it into input events -- the ps2 keyboard driver, > the basic mouse driver, the advanced mice drivers. This is where the > interface falls down a little bit -- the ps2 keyboard driver is the > closest analogue to what I'm suggesting. The ps2 keyboard driver > creates scancode events, which map nicely to what the keyboard is > sending -- these are, for ex, rc5 codes. It will also produce > key-up/key-down events, if it has a keymap loaded. (This is the > difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned > to it at boottime, so it works out-of-box. This isn't really possible > with an IR remote -- though perhaps rc5 is standarized enough, I don't > think other protocols neccessarly are.) > > Userspace would have to load a keymap; those don't really belong in > kernel code. Of course, userspace could look at the device > identifiers to pick a reasonable default keymap if it's not configured > to load another, solving the out-of-box experince. I think perhaps before we go much further into this, we may wish to come up with a set of use cases and expected behavior. I worry that part of the problem here is people are thinking of how their particular cards behave, and few people have a holistic picture of all the possible scenarios. Whatever implementation we come up, we should be confident that it meets the requirements of *all* the various hardware implementations. I will try to draft up some requirements/use cases if people think this would be worthwhile. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Mauro Carvalho Chehab wrote: > Hans Verkuil wrote: >> Hi Mauro, >> >> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the >> following: >> >> - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. > > Something went wrong here: > > $ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1 > linux/Documentation/DocBook/v4l/pixfmt.xml |5 > linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097 > > 2 files changed, 554 insertions(+), 548 deletions(-) > > Why a simple patch like this is changing 1097 lines at videodev2.h.xml? I've applied it here, reverted the videodev2.h.xml and did a make -C media-specs. The produced changes at videodev2.h.xml were coherent... Maybe you used the legacy v4l2-specs tree to make the driver? IMO, we can remove it and the dvb-specs directories, since I don't see much sense on keeping compiling the separate specs. Comments? Cheers, Mauro. diff --git a/linux/Documentation/DocBook/v4l/pixfmt.xml b/linux/Documentation/DocBook/v4l/pixfmt.xml --- a/linux/Documentation/DocBook/v4l/pixfmt.xml +++ b/linux/Documentation/DocBook/v4l/pixfmt.xml @@ -770,6 +770,11 @@ kernel sources in the file Doc 'S920' YUV 4:2:0 format of the gspca sn9c20x driver. + + V4L2_PIX_FMT_STV0680 + 'S680' + Bayer format of the gspca stv0680 driver. + V4L2_PIX_FMT_WNVA 'WNVA' diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml b/linux/Documentation/DocBook/v4l/videodev2.h.xml --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml @@ -363,6 +363,7 @@ struct v #define V4L2_PIX_FMT_OV511 v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ #define V4L2_PIX_FMT_OV518 v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */ #define V4L2_PIX_FMT_TM6000 v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ +#define V4L2_PIX_FMT_STV0680 v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */ /* * F O R M A T E N U M E R A T I O N -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Video extractor?
Is there a video editor which can be used to extract pieces of video to file? Two of the editors in Ubuntu failed to load the DVB TS streamfile, Kino converted it to DV format, and slowly. That is bad. And I don't know what DV format is, and how to convert it losslessly back to DVB TS format. Simplest would be if Xine would be equipped with "mark begin", "mark end", and "extract to file" commands. The marks should be at 188 byte packet boundaries. I could write viewer myself using libxine but it takes time. Are Xine people reading this? In any case, I got feeling basic tools are still missing from Linux media software catalogue. I need the tool in my projects. Juhana -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> Event input has the advantage that the keystrokes will provide an unique >> representation that is independent of the device. > > This can hardly work as the only means, the remotes have different keys, > the user almost always has to provide customized key<>function mapping. Key mapping can be easily changed via input interface, as noticed by others. >> Considering the common case >> where the lirc driver will be associated with a media input device, the >> IR type can be detected automatically on kernel. However, advanced users may >> opt to use other IR types than what's provided with the device they >> bought. > > I think most users would want to do that, though I don't have hard > numbers of course. Why use a number of RCs simultaneously while one will > do? If you're building a dedicated hardware to act as a MCE, it makes sense to use just one IR to control your TV and your hardware, but the common usage is to add a TV board or stick to your desktop to see TV. For this, the standard IR fits well. >> It should also be noticed that not all the already-existing IR drivers >> on kernel can provide a lirc interface, since several devices have >> their own IR decoding chips inside the hardware. > > Right. I think they shouldn't use lirc interface, so it doesn't matter. If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. It is very bad to have two interfaces for the same thing, because people may do things like that. Also, there are some cases where the same V4L driver can receive IR scancodes directly for one board, while for others, it needs to get pulse/space decoding. So, it makes sense to have an uniform way for doing it. >> 2) create a lirc kernel API, and have a layer there to decode IR >> protocols and output them via the already existing input layer. In >> this case, all we need to do, in terms of API, is to add a way to set >> the IR protocol that will be decoded, and to enumberate the >> capabilities. The lirc API, will be an in-kernel API to communicate >> with the devices that don't have IR protocols decoding capabilities >> inside the hardware. > > I think this makes a lot of sense. > But: we don't need a database of RC codes in the kernel (that's a lot of > data, the user has to select the RC in use anyway so he/she can simply > provide mapping e.g. RC5<>keycode). This is an interesting discussion. We currently have lots of such tables in kernel, but it can be a good idea to have it loaded by udev during boot time. > We do need RCx etc. protocols implementation in the kernel for the input > layer. Yes. We already have this. See bttv, saa7134 and cx88 for several of such protocol decoding. > "lirc" interface: should we be sending time+on/off data to userspace, or > the RC5 etc. should be implemented in the kernel? There is (?) only > a handful of RC protocols, implementing them in the kernel and passing > only information such as proto+group+code+press/release etc. should be > more efficient. > > Perhaps the raw RCx data could be sent over the input layer as well? > Something like the raw keyboard codes maybe? > > We need to handle more than one RC at a time, of course. Are you meaning that we should do more than one RC per input event interface? If so, why do you think we need to handle more than one IR protocol at the same time? I think this will just make the driver more complex without need. Also, I'm not sure if this would work well for all protocols. >> So, the basic question that should be decided is: should we create a new >> userspace API for raw IR pulse/space > > I think so, doing the RCx proto handling in the kernel (but without > RCx raw code <> key mapping in this case due to multiple controllers > etc.). Though it could probably use the input layer as well(?). Since the key mapping table can be changed anytime, I don't see this as an issue. If we are doing protocol handling in kernel, we just need to add some extensions to the existing input event API to properly handle the IR protocol type. > I think we shouldn't at this time worry about IR transmitters. Agreed. We can postpone this discussion after solving the IR receivers Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH, RFC] Fix videobuf_queue_vmalloc_init() prototype
For whatever reason, the device structure pointer to videobuf_queue_vmalloc_init is typed "void *", even though it's passed right through to videobuf_queue_core_init(), which expects a struct device pointer. The other videobuf implementations use struct device *; I think vmalloc should too. Signed-off-by: Jonathan Corbet diff --git a/drivers/media/video/videobuf-vmalloc.c b/drivers/media/video/videobuf-vmalloc.c index 99d646e..d6e6a28 100644 --- a/drivers/media/video/videobuf-vmalloc.c +++ b/drivers/media/video/videobuf-vmalloc.c @@ -392,7 +392,7 @@ static struct videobuf_qtype_ops qops = { void videobuf_queue_vmalloc_init(struct videobuf_queue* q, const struct videobuf_queue_ops *ops, -void *dev, +struct device *dev, spinlock_t *irqlock, enum v4l2_buf_type type, enum v4l2_field field, diff --git a/include/media/videobuf-vmalloc.h b/include/media/videobuf-vmalloc.h index 1ffdb66..4b419a2 100644 --- a/include/media/videobuf-vmalloc.h +++ b/include/media/videobuf-vmalloc.h @@ -31,7 +31,7 @@ struct videobuf_vmalloc_memory void videobuf_queue_vmalloc_init(struct videobuf_queue* q, const struct videobuf_queue_ops *ops, -void *dev, +struct device *dev, spinlock_t *irqlock, enum v4l2_buf_type type, enum v4l2_field field, -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > > > Event input has the advantage that the keystrokes will provide an unique > > representation that is independent of the device. > > This can hardly work as the only means, the remotes have different keys, > the user almost always has to provide customized key<>function mapping. > Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... > > Perhaps the raw RCx data could be sent over the input layer as well? > Something like the raw keyboard codes maybe? > Curreently the "scan" codes in the input layer serve just to help users to map whatever the device emits into a proper input event code so that the rest of userspace would not have to care and would work with all types of devices (USB, PS/2, etc). I would not want to get to the point where the raw codes are used as a primary data source. > We need to handle more than one RC at a time, of course. > > > So, the basic question that should be decided is: should we create a new > > userspace API for raw IR pulse/space > > I think so, doing the RCx proto handling in the kernel (but without > RCx raw code <> key mapping in this case due to multiple controllers > etc.). Though it could probably use the input layer as well(?). > I think if the data is used to do the primary protocol decoding then it should be a separate interface that is processed by someone and then fed into input subsystem (either in-kernel or through uinput). Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Stefan Richter wrote: > Krzysztof Halasa wrote: >> Mauro Carvalho Chehab writes: >> >>> Event input has the advantage that the keystrokes will provide an unique >>> representation that is independent of the device. >> This can hardly work as the only means, the remotes have different keys, >> the user almost always has to provide customized key<>function mapping. > > Modern input drivers in the mainline kernel have a scancode-to-keycode > translation table (or equivalent) which can be overwritten by userspace. > The mechanism to do that is the EVIOCSKEYCODE ioctl. This mechanism is already used by all V4L drivers and several DVB drivers. > (This is no recommendation for lirc. I have no idea whether a > pulse/space -> scancode -> keycode translation would be practical there.) pulse/space -> scancode translation is already done by several existing drivers. For example, there are several bttv and saa7134 devices that polls (or receive IRQ interrupts) to detect pulses (and the absense of them) in order to create a pulse/space code. The conversion from pulse/space to scancode is done inside the driver, with the help of some generic routines and based on the protocol specifications. The conversion from the scancode to a keycode is done based on in-kernel keycode tables that can be changed from userspace with EVIOCSKEYCODE ioctl. I can't see any technical reason why not doing the same for the lirc drivers, except for one issue: Those devices where the decoding is done by software can support any IR protocols. So, it is possible to buy a device with a NEC IR, and use a RC5 IR to control it. However, currently, there's no way to inform the kernel to use a different algorithm to translate the kernel. This can be solved by adding a few ioctls to enumerate the supported protocols and to select the one(s) that will be handled by the kernel driver. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
James Mastros wrote: > 2009/11/23 Devin Heitmueller : >> Just bear in mind that with the current in-kernel code, users do *not >> * have to manually select the RC code to use if they are using the >> default remote that shipped with the product. > This could still happen, if LIRC checks the identifiers of the > reciving device, and has a database that tells it mappings between > those devices and the remote controls that shipped with them. True, but this means that everyone with an IR will need to use lirc. /me thinks that, whatever decided with those lirc drivers, this should be applied also to the existing V4L/DVB drivers. IMO, it would be better to load the tables at the boot time (or at the corresponding hotplug event, for USB devices). > However, it occours to me that the IR circumstances map pretty well to > what happens with ps/2 and serial devices now: > > 1: There are a variety of drivers for serio computer-side hardware, > each of which speaks the serio interface to the next-higher level. > These corrospond to the drivers for IR recievers. > 2: There's a raw serio interface, for those wishing to do strange things. > 3: There's also a variety of things that take data, using the kernel > serio API, and decode it into input events -- the ps2 keyboard driver, > the basic mouse driver, the advanced mice drivers. Seems an interesting model. > This is where the > interface falls down a little bit -- the ps2 keyboard driver is the > closest analogue to what I'm suggesting. The ps2 keyboard driver > creates scancode events, which map nicely to what the keyboard is > sending -- these are, for ex, rc5 codes. It will also produce > key-up/key-down events, if it has a keymap loaded. (This is the > difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned > to it at boottime, so it works out-of-box. This isn't really possible > with an IR remote -- though perhaps rc5 is standarized enough, I don't > think other protocols neccessarly are.) Even with RC5, there are some vendors that implement it differently on his IR (for example, using VCR and/or TV group for the keys). > Userspace would have to load a keymap; those don't really belong in > kernel code. Of course, userspace could look at the device > identifiers to pick a reasonable default keymap if it's not configured > to load another, solving the out-of-box experince. I like this idea. We currently have hundreds of IR keymaps already in kernel. It seems good to remove from kernel and let udev load those. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Compile error saa7134 - compro videomate S350
Hi, I need help to compile v4l-dvb drivers for saa7134 modules. I'm new to v4l-dvb not sure how to get past the errors concerning undefined declarations found in saa7134-inputs.c file for the videomate S350 board, saying ir_codes, mask_keycodes, mask_keydown as undeclared: snip:- make[2]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /home/tvbox/v4l-dvb/v4l/saa7134-input.o /home/tvbox/v4l-dvb/v4l/saa7134-input.c: In function 'build_key': /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: 'ir_codes' undeclared (first use in this function) /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: (Each undeclared identifier is reported only once /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: for each function it appears in.) /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: 'ir_codes_videomate_s350' undeclared (first use in this function) /home/tvbox/v4l-dvb/v4l/saa7134-input.c:91: error: 'mask_keycode' undeclared (first use in this function) /home/tvbox/v4l-dvb/v4l/saa7134-input.c:92: error: 'mask_keydown' undeclared (first use in this function) make[3]: *** [/home/tvbox/v4l-dvb/v4l/saa7134-input.o] Error 1 make[2]: *** [_module_/home/tvbox/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/tvbox/v4l-dvb/v4l' make: *** [all] Error 2 background: Justbought last week a new compro videomate s350 (dvb-s) card after seeing some positive feedback on forumes saying it is working. But the card I got has a newer chip set incorporating a saa7135 device and after some searching found someone else also had the same issue back in June but managed to fix it with a few changes. I trying to re-produce the actions (see link below) and re-build the drivers but I'm stuck at the compile stage (make all). http://osdir.com/ml/linux-media/2009-06/msg01256.html Can someone advise me on how get past the make error? Thanks, Dominic -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VFlip problem in gspca_pac7311
Hi, Gustavo Chaín Dumit wrote: > Hi > > I'm testing a Pixart Imaging device (0x93a:0x2622) > Everything works fine, but vertical orientation. Image looks rotated. > So I wrote a little hack to prevent it. > [...] > Any one has the same problem ? You might want to have a look to libv4l ( http://freshmeat.net/projects/libv4l ) and the v4lcontrol_flags[] in http://linuxtv.org/hg/v4l-dvb/file/2f87f537fb2b/v4l2-apps/libv4l/libv4lconvert/control/libv4lcontrol.c . This user space library has a list of laptops where the webcams are installed for example upside down. Regards, Márton Németh -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ENE CIR driver
On Sat, Nov 21, 2009 at 1:30 PM, Jarod Wilson wrote: > On Nov 21, 2009, at 12:18 PM, Alex Deucher wrote: > >> Does anyone know if there is a driver or documentation available for >> the ENE CIR controller that's incorporated into many of their keyboard >> controllers? If there is no driver but documentation, are there >> drivers for other CIR controllers that could be used as a reference? > > Maxim Levitsky authored lirc_ene0100, which is in the lirc tarball and my > lirc git tree now, with the intention of submitting it for upstream kernel > inclusion once (if?) we get the base lirc bits accepted. > Excellent. thanks for the heads up. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
image capture with ov9655 camera and intel pxa270C5C520
Hello, my name is Kai Tiwisina and i'm a student in germany and i'm trying to communicate with a Omnivision ov9655 camera which is atteched with my embedded linux system via the v4l commands. I've written a small testprogram which should grow step by step while i'm trying one ioctl after another. Everything worked fine until i tried to use the VIDIOC_S_FMT ioctl. It's always giving me an "invalid argument" failure and i don't know why. Perhaps someone of you is able to help me with this ioctl and give an advice for a simple flow chart for a single frame image capture. Which ioctl steps are neccessary and where do i need loops and for what, because the capture-example.c from bytesex.org is way too general for my purpose. Thanks in advance Kai Tiwisina -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser stream_test.c Description: Binary data
Re: VFlip problem in gspca_pac7311
El Mon, 23 Nov 2009 19:27:04 +0100 Németh Márton escribió: > Hi, > Gustavo Chaín Dumit wrote: > > Hi > > > > I'm testing a Pixart Imaging device (0x93a:0x2622) > > Everything works fine, but vertical orientation. Image looks > > rotated. So I wrote a little hack to prevent it. > > [...] > > Any one has the same problem ? > > You might want to have a look to libv4l > ( http://freshmeat.net/projects/libv4l ) and the v4lcontrol_flags[] in > http://linuxtv.org/hg/v4l-dvb/file/2f87f537fb2b/v4l2-apps/libv4l/libv4lconvert/control/libv4lcontrol.c > . > This user space library has a list of laptops where the webcams are > installed for example upside down. > > Regards, > > Márton Németh > -- > To unsubscribe from this list: send the line "unsubscribe > linux-media" in the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html thanks you! -- Gustavo Chaín Dumit http://0xff.cl -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
I'm a bit short on time to write up a more complete reply to anything in this thread at the moment, but a few quick notes interspersed below. On Nov 23, 2009, at 12:29 PM, Mauro Carvalho Chehab wrote: > Krzysztof Halasa wrote: >> Mauro Carvalho Chehab writes: ... >>> Considering the common case >>> where the lirc driver will be associated with a media input device, the >>> IR type can be detected automatically on kernel. However, advanced users may >>> opt to use other IR types than what's provided with the device they >>> bought. >> >> I think most users would want to do that, though I don't have hard >> numbers of course. Why use a number of RCs simultaneously while one will >> do? > > If you're building a dedicated hardware to act as a MCE, it makes sense to > use just one IR to control your TV and your hardware, but the common usage > is to add a TV board or stick to your desktop to see TV. For this, > the standard IR fits well. The main use case that I have personal experience using IR and capture devices is with MythTV. Its not at all uncommon for a MythTV user to have a setup where the capture devices are attached to a completely different system from the system where the IR part needs to be. MythTV is client-server -- the backend server does the video capture via the capture devices, and the frontend client plays back the video, and its the frontend client that you navigate via an IR remote control. There are quite a few available IR options that are NOT tied to a video capture device at all -- the mceusb and imon drivers submitted in my patch series are actually two such beasts. And particularly with the mceusb receivers, because they support damn near every IR protocol under the sun at any carrier frequency, using a remote other than the bundled one is quite common. Most people's set top boxes and/or televisions and/or AV receivers come with a remote capable of controlling multiple devices, and many bundled remotes are, quite frankly, utter garbage. I use a Logitech Harmony 880 universal remote myself. >>> It should also be noticed that not all the already-existing IR drivers >>> on kernel can provide a lirc interface, since several devices have >>> their own IR decoding chips inside the hardware. >> >> Right. I think they shouldn't use lirc interface, so it doesn't matter. > > If you see patch 3/3, of the lirc submission series, you'll notice a driver > that has hardware decoding, but, due to lirc interface, the driver generates > pseudo pulse/space code for it to work via lirc interface. Historically, this is true. But the version I submitted actually defaults to operating as a pure input layer device for all the imon devices that do onboard decoding. There are older imon devices that don't do onboard decoding, and I retained "legacy", if you will, lirc interface support in this pass of the driver for the onboard decode devices for those that want to keep things running as they always have (via a modparam). More replyification later tonight... -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in changeset 13239:54535665f94b ?
e9hack wrote: > e9hack schrieb: >> can you please commit this patch? It's perfect just I wrote here >> (http://news.gmane.org/gmane.linux.drivers.video-input-infrastructure). > > Ooops, the link wasn't correct. > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11846 > > Regards, > Hartmut > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Hartmut, There's no patch at the link you've pointed me. Please re-send me the patch that worked. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Nov 23 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13381:2f87f537fb2b gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc8-armv5: OK linux-2.6.32-rc8-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc8-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc8-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc8-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc8-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc8-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc8-x86_64: WARNINGS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc8): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
James Mastros writes: > (This is the > difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned > to it at boottime, so it works out-of-box. This isn't really possible > with an IR remote -- though perhaps rc5 is standarized enough, I don't > think other protocols neccessarly are.) Even with RC5 this isn't really possible. RC5 specifies several classes of remotes, and with a typical HTPC scenario the sensor will pick up more than one remote codeset - e.g. one for the display, one for TV card, and maybe others (all those codes may be coming from a single remote). We have no way to know in advance which one code set is for the PC. The only thing which we can "preconfigure" is the remote bundled with the sensor (card etc). And even this can be incorrect. Several sensors don't came with a remote controller. I think the default sensor->remote assignment may only make sense in userspace, while configuring the mapping. Of course all the above changes when the sensors can't present the "raw" data (IR on/off) but does all the decoding internally (and for example can't decode all RC5 but only keys used on its remote). In such unfortunate cases it has to go to the input layer directly. > Userspace would have to load a keymap; those don't really belong in > kernel code. Of course, userspace could look at the device > identifiers to pick a reasonable default keymap if it's not configured > to load another, solving the out-of-box experince. Precisely. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab writes: > True, but this means that everyone with an IR will need to use lirc. I think that if the input layer (instead of raw code) is used, a utility which only sets the mapping(s) would suffice. I.e. no daemon. > /me thinks that, whatever decided with those lirc drivers, this should > be applied also to the existing V4L/DVB drivers. Certainly. > IMO, it would be better to load the tables at the boot time (or at the > corresponding hotplug event, for USB devices). Sure (unless the "raw code" interface is in use). Though maybe the raw code interface should be done in a simple library instead of requiring the daemon. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab writes: >> (This is no recommendation for lirc. I have no idea whether a >> pulse/space -> scancode -> keycode translation would be practical >> there.) It would, but not exactly in the present shape. > For example, there are several bttv and saa7134 devices that polls (or receive > IRQ interrupts) to detect pulses (and the absense of them) in order to create > a pulse/space code. The conversion from pulse/space to scancode is done inside > the driver, with the help of some generic routines and based on the protocol > specifications. Right. There are currently several problems (I'm quite familiar with saa713x RC5 code): the one that it barely works and is not implemented for most such "GPIO/IRQ-driven" cards (as of 2.6.29 or so). This could be fixed, I even have a working though quick&dirty patch. Another: the RC5 allows for groups and codes within groups. The mapping can only use one group, and there can only be one mapping. These design limitations mean it's unusable in many cases. > Those devices where the decoding is done by software can support any > IR protocols. Yes, and there can be multiple remote controllers, and multiple code groups within a remote. > This can be solved by adding a few ioctls to enumerate the supported > protocols and to select the one(s) that will be handled by the kernel > driver. The driver may have to handle many protocols simultaneously. This is not a problem from a technical POV. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: image capture with ov9655 camera and intel pxa270C5C520
Hi Kai On Mon, 23 Nov 2009, Kai Tiwisina wrote: > Hello, > > my name is Kai Tiwisina and i'm a student in germany and i'm trying to > communicate with a Omnivision ov9655 camera which is atteched with my > embedded linux system via the v4l commands. > > I've written a small testprogram which should grow step by step while i'm > trying one ioctl after another. > Everything worked fine until i tried to use the VIDIOC_S_FMT ioctl. It's > always giving me an "invalid argument" failure and i don't know why. Since you don't seem to have the source of the driver at hand, I'd suggest to use the VIDIOC_ENUM_FMT http://v4l2spec.bytesex.org/spec/r8367.htm ioctl to enumerate all pixel formats supported be the driver. If the driver you're using is the same, that Stefan (cc'ed) has submitted to the list, then indeed it does not support the V4L2_PIX_FMT_RGB555 format, that you're requesting, only various YUV (and a Bayer?) formats. > Perhaps someone of you is able to help me with this ioctl and give an > advice for a simple flow chart for a single frame image capture. Which > ioctl steps are neccessary and where do i need loops and for what, because > the capture-example.c from bytesex.org is way too general for my purpose. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab writes: > If you see patch 3/3, of the lirc submission series, you'll notice a driver > that has hardware decoding, but, due to lirc interface, the driver generates > pseudo pulse/space code for it to work via lirc interface. IOW the driver generates artificial pulse code for lircd? I think - pure bloat. lircd can get events from input layer without problems. Perhaps I misunderstood? > It is very bad to have two interfaces for the same thing, because people > may do things like that. I think having a "raw" scan code interface + the key code "cooked" mode is beneficial. For remotes lacking the raw interface only the latter could be used. > Also, there are some cases where the same V4L driver can receive IR scancodes > directly for one board, while for others, it needs to get pulse/space > decoding. Sure. > This is an interesting discussion. We currently have lots of such tables in > kernel, but it can be a good idea to have it loaded by udev during > boot time. Sure. > Are you meaning that we should do more than one RC per input event > interface? I think so. Why not? For example, one of my remotes generates codes from at least two RC5 groups (in only one "mode"). Currently a remote is limited to only one RC5 group. I think the mapping should be: key = proto + group + raw code, while key2 could be different_proto + different group (if any) + another code. > If so, why do you think we need to handle more than one IR protocol at > the same time? Why not? There are X-in-1 remotes on the market for years. They can "speak" many protocols at once. One may want to have a protocol to handle DVD apps while another for DVB etc. And someone may want to use several different remotes, why not? Personally I use two different remotes (both set to speak RC5 but what if I couldn't set the protocol?). Sure, it requires a bit of hackery (not with pulse code and lircd). > I think this will just make the driver more complex without need. Not much more, and there is a need. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Monday 23 November 2009 18:14:26 Mauro Carvalho Chehab wrote: > Mauro Carvalho Chehab wrote: > > Hans Verkuil wrote: > >> Hi Mauro, > >> > >> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the > >> following: > >> > >> - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. > > > > Something went wrong here: > > > > $ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1 > > linux/Documentation/DocBook/v4l/pixfmt.xml |5 > > linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097 > > 2 files changed, 554 insertions(+), 548 > > deletions(-) > > > > Why a simple patch like this is changing 1097 lines at videodev2.h.xml? > > I've applied it here, reverted the videodev2.h.xml and did a make -C > media-specs. The produced changes at videodev2.h.xml were coherent... > > Maybe you used the legacy v4l2-specs tree to make the driver? > IMO, we can remove it and the dvb-specs directories, since I don't see > much sense on keeping compiling the separate specs. Comments? I'm all for removing v4l2-specs and dvb-specs. These are only confusing people. Regarding the videodev2.h.xml: all those whitespace changes have to do with the whitespace cleanups that 'make commit' does. When videodev2.h is changed, 'make spec' will regenerate videodev2.h.xml and 'make commit' will change that xml file again by modifying all the whitespace. I think it would be good if the whitespace checker script didn't mess with xml files. I don't know how easy it is to change that script, though. Regards, Hans > > Cheers, > Mauro. > > > diff --git a/linux/Documentation/DocBook/v4l/pixfmt.xml > b/linux/Documentation/DocBook/v4l/pixfmt.xml --- > a/linux/Documentation/DocBook/v4l/pixfmt.xml > +++ b/linux/Documentation/DocBook/v4l/pixfmt.xml > @@ -770,6 +770,11 @@ kernel sources in the file Doc > 'S920' > YUV 4:2:0 format of the gspca sn9c20x driver. > > + > + V4L2_PIX_FMT_STV0680 > + 'S680' > + Bayer format of the gspca stv0680 driver. > + > > V4L2_PIX_FMT_WNVA > 'WNVA' > diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml > b/linux/Documentation/DocBook/v4l/videodev2.h.xml --- > a/linux/Documentation/DocBook/v4l/videodev2.h.xml > +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml > @@ -363,6 +363,7 @@ struct v > #define V4L2_PIX_FMT_OV511 > v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ #define linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518v4l2_fourcc('O', > '5', '1', '8') /* ov518 JPEG */ #define linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000 > v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ +#define linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680 > v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */ > > /* > * F O R M A T E N U M E R A T I O N > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson writes: > There are quite a few available IR options that are NOT tied to a > video capture device at all -- the mceusb and imon drivers submitted > in my patch series are actually two such beasts. Precisely. This also includes the parallel and serial port receivers, I'm under impression that they are, or at least were, the most common, due to their extreme simplicity. > And particularly with the mceusb receivers, because they support damn > near every IR protocol under the sun at any carrier frequency, using a > remote other than the bundled one is quite common. Most people's set > top boxes and/or televisions and/or AV receivers come with a remote > capable of controlling multiple devices, and many bundled remotes are, > quite frankly, utter garbage. This is precisely also my experience. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov writes: > Curreently the "scan" codes in the input layer serve just to help users > to map whatever the device emits into a proper input event code so that > the rest of userspace would not have to care and would work with all > types of devices (USB, PS/2, etc). > > I would not want to get to the point where the raw codes are used as a > primary data source. The "key" interface is not flexible enough at present. > Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for > keys and buttons on all devices. Primary, I think so. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: > On Monday 23 November 2009 18:14:26 Mauro Carvalho Chehab wrote: >> Mauro Carvalho Chehab wrote: >>> Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. >>> Something went wrong here: >>> >>> $ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1 >>> linux/Documentation/DocBook/v4l/pixfmt.xml |5 >>> linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097 >>> 2 files changed, 554 insertions(+), 548 >>> deletions(-) >>> >>> Why a simple patch like this is changing 1097 lines at videodev2.h.xml? >> I've applied it here, reverted the videodev2.h.xml and did a make -C >> media-specs. The produced changes at videodev2.h.xml were coherent... >> >> Maybe you used the legacy v4l2-specs tree to make the driver? >> IMO, we can remove it and the dvb-specs directories, since I don't see >> much sense on keeping compiling the separate specs. Comments? > > I'm all for removing v4l2-specs and dvb-specs. These are only confusing > people. Ok. I'll later prepare a patch for it. > Regarding the videodev2.h.xml: all those whitespace changes have to do with > the whitespace cleanups that 'make commit' does. Hmm.. this is wrong for the generated xml files. > When videodev2.h is changed, > 'make spec' will regenerate videodev2.h.xml and 'make commit' will change > that > xml file again by modifying all the whitespace. I think it would be good if > the whitespace checker script didn't mess with xml files. I don't know how > easy it is to change that script, though. I haven't checked, but I suspect it shouldn't be hard to modify it to not handle *.[ch].xml files. While we don't fix it, please avoid committing such changes with make commit. > > Regards, > >Hans > >> Cheers, >> Mauro. >> >> >> diff --git a/linux/Documentation/DocBook/v4l/pixfmt.xml >> b/linux/Documentation/DocBook/v4l/pixfmt.xml --- >> a/linux/Documentation/DocBook/v4l/pixfmt.xml >> +++ b/linux/Documentation/DocBook/v4l/pixfmt.xml >> @@ -770,6 +770,11 @@ kernel sources in the file Doc >> 'S920' >> YUV 4:2:0 format of the gspca sn9c20x driver. >> >> + >> +V4L2_PIX_FMT_STV0680 >> +'S680' >> +Bayer format of the gspca stv0680 driver. >> + >> >> V4L2_PIX_FMT_WNVA >> 'WNVA' >> diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml >> b/linux/Documentation/DocBook/v4l/videodev2.h.xml --- >> a/linux/Documentation/DocBook/v4l/videodev2.h.xml >> +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml >> @@ -363,6 +363,7 @@ struct v >> #define V4L2_PIX_FMT_OV511 >> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ #define > linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518v4l2_fourcc('O', >> '5', '1', '8') /* ov518 JPEG */ #define > linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000 >> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ +#define > linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680 >> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */ >> >> /* >> * F O R M A T E N U M E R A T I O N >> -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Czesc Krzysztof, on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: [...] > I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Jarod, on 23 Nov 09 at 14:17, Jarod Wilson wrote: >> Krzysztof Halasa wrote: [...] >> If you see patch 3/3, of the lirc submission series, you'll notice a driver >> that has hardware decoding, but, due to lirc interface, the driver >> generates pseudo pulse/space code for it to work via lirc interface. > Historically, this is true. No, it's not. I think you misunderstood the code. The comment may be a bit misleading, too. Early iMON devices did not decode in hardware and the part of the driver that Krzystof is referring to is translating a bit-stream of the sampled input data into pulse/space durations. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add new TV cards of Beholder
Hi Dmitri, I added this patch, but the driver is essentially broken. It would be wonderful if you have some time to fix it. Cheers, Mauro. Dmitri Belimov wrote: > Hi All > > Add new TV cards of Beholder for autodetect. > > diff -r 3919b17dc88e linux/drivers/staging/tm6000/tm6000-cards.c > --- a/linux/drivers/staging/tm6000/tm6000-cards.c Wed Oct 14 12:52:55 > 2009 -0300 > +++ b/linux/drivers/staging/tm6000/tm6000-cards.c Tue Nov 10 08:05:15 > 2009 +0900 > @@ -33,6 +33,7 @@ > #include "tm6000.h" > #include "tm6000-regs.h" > #include "tuner-xc2028.h" > +#include "tuner-xc5000.h" > > #define TM6000_BOARD_UNKNOWN 0 > #define TM5600_BOARD_GENERIC 1 > @@ -193,6 +194,36 @@ > }, > .gpio_addr_tun_reset = TM6000_GPIO_2, > }, > + [TM6010_BOARD_BEHOLD_WANDER] = { > + .name = "Beholder Wander DVB-T/TV/FM USB2.0", > + .tuner_type = TUNER_XC5000, > + .tuner_addr = 0xc2 >> 1, > + .demod_addr = 0x1e >> 1, > + .type = TM6010, > + .caps = { > + .has_tuner= 1, > + .has_dvb = 1, > + .has_zl10353 = 1, > + .has_eeprom = 1, > + .has_remote = 1, > + }, > + .gpio_addr_tun_reset = TM6000_GPIO_2, > + }, > + [TM6010_BOARD_BEHOLD_VOYAGER] = { > + .name = "Beholder Voyager TV/FM USB2.0", > + .tuner_type = TUNER_XC5000, > + .tuner_addr = 0xc2 >> 1, > + .type = TM6010, > + .caps = { > + .has_tuner= 1, > + .has_dvb = 0, > + .has_zl10353 = 0, > + .has_eeprom = 1, > + .has_remote = 1, > + }, > + .gpio_addr_tun_reset = TM6000_GPIO_2, > + }, > + > }; > > /* table of devices that work with this driver */ > @@ -203,6 +234,8 @@ > { USB_DEVICE(0x14aa, 0x0620), .driver_info = > TM6000_BOARD_FREECOM_AND_SIMILAR }, > { USB_DEVICE(0x06e1, 0xb339), .driver_info = > TM6000_BOARD_ADSTECH_MINI_DUAL_TV }, > { USB_DEVICE(0x2040, 0x6600), .driver_info = > TM6010_BOARD_HAUPPAUGE_900H }, > + { USB_DEVICE(0x6000, 0xdec0), .driver_info = TM6010_BOARD_BEHOLD_WANDER > }, > + { USB_DEVICE(0x6000, 0xdec1), .driver_info = > TM6010_BOARD_BEHOLD_VOYAGER }, > { }, > }; > > Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov > > With my best regards, Dmitry. > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add new TV cards of Beholder
On Mon, Nov 23, 2009 at 4:28 PM, Mauro Carvalho Chehab wrote: > Hi Dmitri, > > I added this patch, but the driver is essentially broken. It would > be wonderful if you have some time to fix it. > > Cheers, > Mauro. Yeah, I saw his patch and was wondering why on Earth he submitted a patch adding card support for a completely broken driver. How could he have validated the patch is correct? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
l...@bartelmus.de (Christoph Bartelmus) writes: >> I think we shouldn't at this time worry about IR transmitters. > > Sorry, but I have to disagree strongly. > Any interface without transmitter support would be absolutely unacceptable > for many LIRC users, including myself. I don't say don't use a transmitter. I say the transmitter is not an input device, they are completely independent functions. I can't see any reason to try and fit both in the same interface - can you? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 4:46 PM, Krzysztof Halasa wrote: > l...@bartelmus.de (Christoph Bartelmus) writes: > >>> I think we shouldn't at this time worry about IR transmitters. >> >> Sorry, but I have to disagree strongly. >> Any interface without transmitter support would be absolutely unacceptable >> for many LIRC users, including myself. > > I don't say don't use a transmitter. > I say the transmitter is not an input device, they are completely > independent functions. I can't see any reason to try and fit both in the > same interface - can you? There is an argument to be made that since it may be desirable for both IR receivers and transmitters to share the same table of remote control definitions, it might make sense to at least *consider* how the IR transmitter interface is going to work, even if it is decided to not implement such a design in the first revision. Personally, I would hate to see a situation where we find out that we took a bad approach because nobody considered what would be required for IR transmitters to reuse the same remote control definition data. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
I though about it a bit - my idea: 1. Receivers that can only decode their own remote controllers. The present code (saa713x etc) can stay mostly unchanged. I'd only verify that 7 bits (or whatever the number is) is enough for all cases. The ioctl() should stay unchanged. That means keyboard-like input layer interface. 2. Receivers that can be programmed to receive different codes, and/or which simply generate IRQ on space/mark changes. They would use a new ioctl() instead: int set_rc_mapping_ioctl(void *data ...) data should be: u32 protocol1; u32 length1; u32 protocol2; u32 length2; ... u32 protocol_last; u32 length_last; (u32) 0. The protocol data would follow (after all proto/length fields to avoid alignment issues, but that's a detail of course). For example, RC5. It uses 1 start bit (formerly 2 bits), 1 "toggle" bit, 5 address bits (group code) and 7 command bits (formerly 6 bits). Each key would be represented by u16, or maybe by a couple of u8. A "discard repeated" (perhaps inverted) bit should be included. Of course, the "symbolic" key code should be included for each "scan" code. Maybe: u8 address_and_discard_repeated_bit; u8 command_value; u8 symbolic_key_code; repeated as required. Protocol2 would follow protocol1 etc. (alignment issues). The driver could see this info (for example, to program hardware to receive a specific protocol) and then it should pass it to the generic lirc_set_mapping() routine. I'd also add separate trivial space/mark protocol, for debugging etc. Maybe: u8 key_code_for_space; u8 key_code_for_mark; Maybe specifying length = 0 (meaning constant "key" codes) would be enough? I think the "key" code should also specify some time stamp (or pulse length). Interface to the sensor driver: The driver should register an IRQ called on both (preferably) edges of the input signal. Basically it should only register IRQ and do: irqreturn_t xxx_irq() { ack_irq_as_usual_etc(); if (input_signal->changed_state) /* really for us */ lirc_signal_state_change(input_signal->current_state); } The sensor driver would not know about the protocols etc. unless it needs to e.g. program the hardware. The middle layer (some sort of a library, and module) would interface to the userspace (ioctl passed by the driver, input interface) and to the hw driver. It would have to enable and call the required protocol decoders (based on the keymap loaded). -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Devin Heitmueller writes: > There is an argument to be made that since it may be desirable for > both IR receivers and transmitters to share the same table of remote > control definitions, it might make sense to at least *consider* how > the IR transmitter interface is going to work, even if it is decided > to not implement such a design in the first revision. > > Personally, I would hate to see a situation where we find out that we > took a bad approach because nobody considered what would be required > for IR transmitters to reuse the same remote control definition data. I briefly though about such possibility, but dismissed it with assumption that we won't transmit the same codes (including "key" codes) that we receive. Perhaps I'm wrong. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa wrote: > Devin Heitmueller writes: > >> There is an argument to be made that since it may be desirable for >> both IR receivers and transmitters to share the same table of remote >> control definitions, it might make sense to at least *consider* how >> the IR transmitter interface is going to work, even if it is decided >> to not implement such a design in the first revision. >> >> Personally, I would hate to see a situation where we find out that we >> took a bad approach because nobody considered what would be required >> for IR transmitters to reuse the same remote control definition data. > > I briefly though about such possibility, but dismissed it with > assumption that we won't transmit the same codes (including "key" codes) > that we receive. I'm not specifically suggesting that you would want to transmit the same codes that you receive, but you probably want the database of remote control definitions to be shared. For example, you might want the IR receiver to be listening for codes using the "Universal Remote Control XYZ" profile and the IR transmitter pretending to be "Cable Company Remote Control ABC" when blasting IR codes to the cable box. Ideally, there would be a single shared database of the definitions of the remote controls, regardless of whether you are IR receiving or transmitting. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Video extractor?
That is the weak point of linux in general, in my case I can't capture, edit and process DV video using linux, TS I doesn't even count. In windows I have virtualdub and avisynth (with plugins) to do whatever I need to process any capture type. Since I got to know Linux OS (your linux OS brand here) back in 1996 not much was made so you can switch 100% from windows to linux. Yes, today linux is much more easy to handle for a normal user, back in the days we had to compile the kernel at the installation process, compile your drivers and so on, but even today if you need some specific tools in Linux that is trivial in Windows like virtualdub, avisynth (others) you don't have it. Make a dual boot installation to use windows based tools to do your basic work. 2009/11/23 Juhana Sadeharju : > > Is there a video editor which can be used to extract pieces > of video to file? Two of the editors in Ubuntu failed to load > the DVB TS streamfile, Kino converted it to DV format, and slowly. > That is bad. And I don't know what DV format is, and how to convert > it losslessly back to DVB TS format. > In any case, I got feeling basic tools are still missing from > Linux media software catalogue. I need the tool in my projects. > > Juhana -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Devin Heitmueller writes: > For example, you might want the IR receiver to be listening for codes > using the "Universal Remote Control XYZ" profile and the IR > transmitter pretending to be "Cable Company Remote Control ABC" when > blasting IR codes to the cable box. Ideally, there would be a single > shared database of the definitions of the remote controls, regardless > of whether you are IR receiving or transmitting. Well, with different receivers, the maps must certainly be different. There can be single database in the userspace but the kernel must be uploaded the relevant info only. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] soc-camera: tw9910: modify V/H outpit pin setting to use VALID
Dear Guennadi > Hm, strange... This doesn't work at all for me. Getting only timeouts. > Have you tested this on Migo-R? Hmm.. strange... It works well on my environment. Of course Migo-R too. my environment is based on your 20091105 patches and my patches Kuninori Morimoto (13): soc-camera: tw9910: Add revision control soc-camera: tw9910: fix a persistent ID calculation soc-camera: tw9910: Add tri-state control soc-camera: tw9910: Add power control soc-camera: tw9910: tw9910_set_hsync clean up soc-camera: tw9910: Add revision control on tw9910_set_hsync ->soc-camera: tw9910: modify V/H outpit pin setting to use VALID soc-camera: tw9910: modify output format soc-camera: tw9910: remove cropping soc-camera: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support soc-camera: tw9910: use V4L2_FIELD_INTERLACED_BT soc-camera: sh_mobile_ceu_camera: Add support sync polarity selection soc-camera: tw9910: Add sync polarity support if you use arrow point, you can get strange color output, but get image I think. (to get correct color, next "modify output format" is needed) Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] sh_mobile_ceu_camera: fix pass-through geometry parameters and try_fmt reporting
> Fix geometry parameter calculations for the pass-through mode, using the > imagebus API, Also fix try-fmt result reporting for natively supported by > the driver pixel formats. > > Signed-off-by: Guennadi Liakhovetski > --- > > Marked as RFC because this is based on my imagebus tree. Otherwise this is > nothing new, I've had this fix for a while in my tree, just forgot to post > together with the rest, when presenting my imagebus stack. This patch seems solve my "broken image" problem !! Tested-by: Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc-camera: sh_mobile_ceu_camera: Add support sync polarity selection
Dear Guennadi Thank you checking > In any case, this confirms, how important good name choice is:-) Now, HSP, > etc. have nothing to do with SH, on CEU these fields are called HDPOL and > VDPOL. But I would suggest some descriptive names, like > SH_CEU_FLAG_HSYNC_HIGH or similar. OK. I understand. I will modify it as soon as possible !! Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc-camera: tw9910: Add sync polarity support
Dear Guennadi > > -#define HSP_LOW 0x00 /* 0 : HS pin output polarity is active low */ > > +#define HSP_LO 0x00 /* 0 : HS pin output polarity is active low */ > > I would remove field names with "0" values completely. Also see below (snip) > > +#define VSP_V_LOVSP_HI /* xSSL_xVALID case, polarity will be inverted > > */ > > +#define VSP_V_HIVSP_LO > > +#define HSP_V_LOHSP_HI > > +#define HSP_V_HIHSP_LO > > I wouldn't add these - just add a comment below and use reverted > [HV]SP_{HI,LO} macros. Hmm OK. > + /* > + * We use VVALID and DVALID signals to control VSYNC and HSYNC > + * outputs, in this mode their polarity is inverted. > + */ > + if (flags & SOCAM_HSYNC_ACTIVE_LOW) > + val |= HSP_HI; > > without any else, agree? agree. OK I will modify it. Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: > Czesc Krzysztof, > > on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: > [...] > > I think we shouldn't at this time worry about IR transmitters. > > Sorry, but I have to disagree strongly. > Any interface without transmitter support would be absolutely unacceptable > for many LIRC users, including myself. I agree with Christoph. Is it that the input subsystem is better developed and seen as a leverage point for development and thus an "easier" place to get results earlier? If so, then one should definitely deal with transmitters early in the design, as that is where the most unknowns lie. With the end of analog TV, people will have STBs feeding analog only video cards. Being able to change the channel on the STB with an IR transmitter controlled by applications like MythTV is essential. And on some different notes: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. I believe Jarod's intent is to have the LIRC components, that need to be in kernel modules, moved into kernel mainline to avoid the headaches of out of kernel driver maintenance. I'm not sure it is time well spent for developers, or end users, to develop yet another IR receive implementation in addition to the ones we suffer with now. I would also note that RC-6 Mode 6A, used by most MCE remotes, was developed by Philips, but Microsoft has some sort of licensing interest in it and it is almost surely encumbered somwhow: http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt "Microsoft recommends the Microsoft-Philips IR protocol (based on RC6) * You can become a licensee at no charge to you [...] * How to license RC6 * Contact RemoteMC @ microsoft.com for license agreement" I would much rather that RC-6 be handled as much as possible in user space than in the kernel. LIRC userspace components already handle it, IIRC. Regards, Andy "LIRC Fan-Boy" Walls -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: image capture with ov9655 camera and intel pxa270C5C520
Hello everyone, here is a little update to my question and to the source code. After i implemented an function with the VIDIOC_ENUM_FMT ioctl i recognized, that only two formats are support by the driver by now. (Thanks to Mr. Liakhovetski by the way ;) ) The output.txt shows the output of this function and mentions the two different types. One is definately the V4L2_PIX_FMT_YUYV format but i don't know the other one exactly... I changed my set_format function after i got this information and unfortunately nothing has changed... Perhaps there are some further possibilities to solve this Problem. Maybe there have some other v4l2 structures to be initialized, befor the VIDIOC_S_FMT ioctl runs? Thans for the support and in advance. Yours sincerely, Kai Tiwisina # Guennadi Liakhovetski wrote: Hi Kai On Mon, 23 Nov 2009, Kai Tiwisina wrote: Hello, my name is Kai Tiwisina and i'm a student in germany and i'm trying to communicate with a Omnivision ov9655 camera which is atteched with my embedded linux system via the v4l commands. I've written a small testprogram which should grow step by step while i'm trying one ioctl after another. Everything worked fine until i tried to use the VIDIOC_S_FMT ioctl. It's always giving me an "invalid argument" failure and i don't know why. Since you don't seem to have the source of the driver at hand, I'd suggest to use the VIDIOC_ENUM_FMT http://v4l2spec.bytesex.org/spec/r8367.htm ioctl to enumerate all pixel formats supported be the driver. If the driver you're using is the same, that Stefan (cc'ed) has submitted to the list, then indeed it does not support the V4L2_PIX_FMT_RGB555 format, that you're requesting, only various YUV (and a Bayer?) formats. Perhaps someone of you is able to help me with this ioctl and give an advice for a simple flow chart for a single frame image capture. Which ioctl steps are neccessary and where do i need loops and for what, because the capture-example.c from bytesex.org is way too general for my purpose. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ r...@bebot15:~# stream_test *New file descriptor: 3* driver: pxa27x-camera card: PXA_Camera bus_info: version:0.0.5 capabilities: 401(HEX) buffer allocated 20 times 1 index: 0 buffer type:1 compressed: 0 sescription:YUV 4:2:2 pixelformat:1448695129 index: 1 buffer type:1 compressed: 0 sescription:YUV 4:2:2 BE pixelformat:1498831189 buffer type:1 image size: 0x0 pixels pixelformat:1448695129 v4l2 field-type:1 bytes per line: 0 image size: 0 v4l2_colorspace-type: 0 Process set_format failed 22, Invalid argument /* Name: stream_test.c Author : Kai Tiwisina Version : Description : Output of camera stream in to text-file */ #include #include #include #include // open() is in here #include // close() is in here #include // used for desolving error numbers #include // ioctl() is in here #include #include // jpeg_markers are defined in here #include // for videodev2.h #include // VIDIOC_QUERYCAP & struct v4ls_capability are defined in here #define CLEAR(x) memset(&(x), 0, sizeof(x)) void print_errno(char *s); //returns errno argument as value and expression void open_device(); //opens a v4l device returning new file descriptor and gives error info if necessary void query_cap(); void request_buffer(); void stream_on(); void query_buffer(); void memory_mapping(); void stream_off(); void get_format(); void set_format(); static struct v4l2_requestbuffers buffer; static struct v4l2_buffer q_buffer; static struct v4l2_format f_type; static int fd; // fd is the file descriptor int main(void) { open_device(); printf("\n\n*New file descriptor: %i*\n\n",fd); query_cap(); request_buffer(); get_format(); set_format(); get_format(); //stream_on(); //query_buffer(); //memory_mapping(); //stream_off(); close(fd); //closes connection to device return 0; } void print_errno(char *s) { printf("Process %s failed %d, %s\n", s, errno, strerror(errno)); exit(EXIT_FAILURE); } void open_device() { int status; status=open("/dev/video0",O_RDWR); //Look up arguments for v4l2 open() in v4l_doku.pdf if(status==-1) //Device_n
Re: [PATCH] Multifrontend support for saa7134
Hi Mauro, Am Montag, den 23.11.2009, 14:04 -0200 schrieb Mauro Carvalho Chehab: > Hi Lukáš/Hermann, > > Any news about this patch? I'll mark it as RFC at the patchwork, since it > seems that this is not finished yet. Please let me know if you make some > progress. > > > @@ -1352,6 +1353,7 @@ struct saa7134_board saa7134_boards[] = > > .tuner_addr = ADDR_UNSET, > > .radio_addr = ADDR_UNSET, > > .mpeg = SAA7134_MPEG_DVB, > > +.num_frontends = 1, > > .inputs = {{ > > .name = name_tv, > > .vmux = 1, > > Just one suggestion here: it is a way better to assume that an > "uninitialized" value (e. g. num_frontends = 0) for num_frontends to mean > that just one frontend exists. This saves space at the initialization segment > of the module and avoids the risk of someone forget to add num_frontends=0. > > cheers, > Mauro. I currently don't have time to work on it and Lukáš' time is also limited. We stay in contact and I can provide a device not yet working for me to him, if he wants. I'll keep you posted. You can have one too ;) Currently the hardware reset in saa7134-dvb.c seems to break tda8275a hybrid tuners on my saa7131e devices for DVB-T. This is not restricted to the devices with multiple frontends, but also hits such with single frontend only. The TRIO has two tda8275a, they are not in use as hybrid tuners and don't need extra initialization again, that might be the difference. We should avoid such saa7133 hardware reset on those cards not needing it in any case, means all with single frontend. ON DVB-S is also a regression visible, in one of two cases needs a second tuning attempt now and it also seems to be related to the hardware reset, since without works fine like previously. Patch is not ready yet for inclusion. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compile error saa7134 - compro videomate S350
Hi Dominic, Am Montag, den 23.11.2009, 10:01 -0800 schrieb Dominic Fernandes: > Hi, > > I need help to compile v4l-dvb drivers for saa7134 modules. > I'm new to v4l-dvb not sure how to get past the errors concerning > undefined declarations found in saa7134-inputs.c file for the videomate > S350 board, saying ir_codes, mask_keycodes, mask_keydown as undeclared: > > snip:- > > make[2]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' > CC [M] /home/tvbox/v4l-dvb/v4l/saa7134-input.o > /home/tvbox/v4l-dvb/v4l/saa7134-input.c: In function 'build_key': > /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: 'ir_codes' undeclared > (first use in this function) > /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: (Each undeclared > identifier is reported only once > /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: for each function it > appears in.) > /home/tvbox/v4l-dvb/v4l/saa7134-input.c:90: error: 'ir_codes_videomate_s350' > undeclared (first use in this function) > /home/tvbox/v4l-dvb/v4l/saa7134-input.c:91: error: 'mask_keycode' undeclared > (first use in this function) > /home/tvbox/v4l-dvb/v4l/saa7134-input.c:92: error: 'mask_keydown' undeclared > (first use in this function) > make[3]: *** [/home/tvbox/v4l-dvb/v4l/saa7134-input.o] Error 1 > make[2]: *** [_module_/home/tvbox/v4l-dvb/v4l] Error 2 > make[2]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/home/tvbox/v4l-dvb/v4l' > make: *** [all] Error 2 > > background: > Justbought last week a new compro videomate s350 (dvb-s) card after seeing > some positive feedback on forumes saying it is working. But the card I > got has a newer chip set incorporating a saa7135 device and after some > searching found someone else also had the same issue back in June but > managed to fix it with a few changes. I trying to re-produce the > actions (see link below) and re-build the drivers but I'm stuck at the > compile stage (make all). > > http://osdir.com/ml/linux-media/2009-06/msg01256.html > > Can someone advise me on how get past the make error? > > Thanks, > Dominic > hm, likely you are on some older/other stuff. Igor had some merge conflict previously for the S350. Can't see it with current linuxtv.org mercurial v4l-dvb. Please try with that. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote: > l...@bartelmus.de (Christoph Bartelmus) writes: > > >> I think we shouldn't at this time worry about IR transmitters. > > > > Sorry, but I have to disagree strongly. > > Any interface without transmitter support would be absolutely unacceptable > > for many LIRC users, including myself. > > I don't say don't use a transmitter. > I say the transmitter is not an input device, they are completely > independent functions. I can't see any reason to try and fit both in the > same interface - can you? The underlying hardware need not be completely independent. For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012] chips have IR hardware that shares a common timing source, interrupt line, interrupt status register, etc, between IR Rx and Tx. They can also do things like loopback of Tx to Rx. That said, an underlying hardware implementation can be split up to user space with separate interfaces Tx and Rx. The underlying driver module would have to manage the dependencies. I would guess that would be easier for driver modules, if the userspace interfaces were designed with such combined IR Tx/Rx hardware in mind. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] soc-camera: sh_mobile_ceu_camera: Add support sync polarity selection
Signed-off-by: Kuninori Morimoto --- v1 -> v2 o remove pclock field o rename macro drivers/media/video/sh_mobile_ceu_camera.c | 17 + include/media/sh_mobile_ceu.h |2 ++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c index b259884..3980fcd 100644 --- a/drivers/media/video/sh_mobile_ceu_camera.c +++ b/drivers/media/video/sh_mobile_ceu_camera.c @@ -674,6 +674,23 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd, if (!common_flags) return -EINVAL; + /* Make choises, based on platform preferences */ + if ((common_flags & SOCAM_HSYNC_ACTIVE_HIGH) && + (common_flags & SOCAM_HSYNC_ACTIVE_LOW)) { + if (pcdev->pdata->flags & SH_CEU_FLAG_HSYNC_LOW) + common_flags &= ~SOCAM_HSYNC_ACTIVE_HIGH; + else + common_flags &= ~SOCAM_HSYNC_ACTIVE_LOW; + } + + if ((common_flags & SOCAM_VSYNC_ACTIVE_HIGH) && + (common_flags & SOCAM_VSYNC_ACTIVE_LOW)) { + if (pcdev->pdata->flags & SH_CEU_FLAG_VSYNC_LOW) + common_flags &= ~SOCAM_VSYNC_ACTIVE_HIGH; + else + common_flags &= ~SOCAM_VSYNC_ACTIVE_LOW; + } + ret = icd->ops->set_bus_param(icd, common_flags); if (ret < 0) return ret; diff --git a/include/media/sh_mobile_ceu.h b/include/media/sh_mobile_ceu.h index 0f3524c..b677478 100644 --- a/include/media/sh_mobile_ceu.h +++ b/include/media/sh_mobile_ceu.h @@ -3,6 +3,8 @@ #define SH_CEU_FLAG_USE_8BIT_BUS (1 << 0) /* use 8bit bus width */ #define SH_CEU_FLAG_USE_16BIT_BUS (1 << 1) /* use 16bit bus width */ +#define SH_CEU_FLAG_HSYNC_LOW (1 << 2) /* default High if possible */ +#define SH_CEU_FLAG_VSYNC_LOW (1 << 3) /* default High if possible */ struct sh_mobile_ceu_info { unsigned long flags; -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] soc-camera: tw9910: Add sync polarity support
Signed-off-by: Kuninori Morimoto --- v1 -> v2 o remove noisy macro o add explain for polarity inverte drivers/media/video/tw9910.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c index a4ba720..fe46c2c 100644 --- a/drivers/media/video/tw9910.c +++ b/drivers/media/video/tw9910.c @@ -513,12 +513,21 @@ static int tw9910_set_bus_param(struct soc_camera_device *icd, { struct v4l2_subdev *sd = soc_camera_to_subdev(icd); struct i2c_client *client = sd->priv; + u8 val = VSSL_VVALID | HSSL_DVALID; /* * set OUTCTR1 +* +* We use VVALID and DVALID signals to control VSYNC and HSYNC +* outputs, in this mode their polarity is inverted. */ - return i2c_smbus_write_byte_data(client, OUTCTR1, -VSSL_VVALID | HSSL_DVALID); + if (flags & SOCAM_HSYNC_ACTIVE_LOW) + val |= HSP_HI; + + if (flags & SOCAM_VSYNC_ACTIVE_LOW) + val |= VSP_HI; + + return i2c_smbus_write_byte_data(client, OUTCTR1, val); } static unsigned long tw9910_query_bus_param(struct soc_camera_device *icd) @@ -528,6 +537,7 @@ static unsigned long tw9910_query_bus_param(struct soc_camera_device *icd) struct soc_camera_link *icl = to_soc_camera_link(icd); unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER | SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH | + SOCAM_VSYNC_ACTIVE_LOW | SOCAM_HSYNC_ACTIVE_LOW | SOCAM_DATA_ACTIVE_HIGH | priv->info->buswidth; return soc_camera_apply_sensor_flags(icl, flags); -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. This patch was generated and tested against v2.6.32-rc8. Similar patch was applied and tested using 2.6.27 which is similar to the latest dvb_net.c, except for network device statistical data structure. I suspect that this bug was introduced in kernel version 2.6.15, but had not verified it. Care has been taken not to introduce more bug by fixing this bug, but please scrutinize the code for I always produces buggy code. Signed-off-by: Ang Way Chuang --- diff --git a/drivers/media/dvb/dvb-core/dvb_net.c b/drivers/media/dvb/dvb-core/dvb_net.c index 0241a7c..7e0db86 100644 --- a/drivers/media/dvb/dvb-core/dvb_net.c +++ b/drivers/media/dvb/dvb-core/dvb_net.c @@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) "field: %u.\n", priv->ts_count, *from_where); /* Drop partly decoded SNDU, reset state, resync on PUSI. */ - if (priv->ule_skb) { - dev_kfree_skb( priv->ule_skb ); + if (priv->ule_skb || priv->ule_sndu_remain) { + if (priv->ule_skb) + dev_kfree_skb( priv->ule_skb ); dev->stats.rx_errors++; dev->stats.rx_frame_errors++; } @@ -533,6 +534,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) from_where += 2; } + priv->ule_sndu_remain = priv->ule_sndu_len + 2; /* * State of current TS: * ts_remain (remaining bytes in the current TS cell) @@ -542,6 +544,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) */ switch (ts_remain) { case 1: + priv->ule_sndu_remain--; priv->ule_sndu_type = from_where[0] << 8; priv->ule_sndu_type_1 = 1; /* first byte of ule_type is set. */ ts_remain -= 1; from_where += 1; @@ -555,6 +558,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) default: /* complete ULE header is present in current TS. */ /* Extract ULE type field. */ if (priv->ule_sndu_type_1) { + priv->ule_sndu_type_1 = 0; priv->ule_sndu_type |= from_where[0]; from_where += 1; /* points to payload start. */ ts_remain -= 1; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: Reprise of YUV frame alignment improvements
On Mon, 2009-11-23 at 12:09 -0500, Devin Heitmueller wrote: > On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls wrote: > > 5. If you don't give an MDL back to the firmware, it never uses it > > again. That's why you see the sweep-up log messages. As soon as an MDL > > is skipped *on the order of the depth* of q_busy times, when looking for > > the currently DMA_DONE'd MDL, that skipped MDL must have been dropped. > > It is picked up and put back into rotation then. > > Perhaps I am misinterpreting the definition of "sweep-up" in this > context. Don't the buffers get forcefully returned to the pool at > that point? You've got it right. > If so, why would I see the same error over and over long > after the CPU utilization has dropped back to a reasonable level. > > I feel like I must be missing something here. > > 1. CPU load goes up (ok) > 2. Packets start to get dropped (expected) > 3. CPU load goes back down (ok) > 4. Packets continue to get dropped and never recycled, even after > minutes of virtually no CPU load? > > I can totally appreciate the notion that the video would look choppy > when the system is otherwise under high load, but my expectation would > be that once the load drops back to 0, the video should look fine > (perhaps with some small window of time where it is still recovering). OK the messages are coming from the sweep up implementation, let's assume it's not working right (which is reasonable to me). The sweep up algorithm relies on an assumption. Assumption: The firmware uses MDL on a FIFO basis based on the order in which we submitted the MDLs to the firmware. Thus, the order of MDLs in the q_busy linked list should match how the firmware returns them. Given that the decision to perform sweep up is based on the absolute current depth of q_busy (was the buffer skipped q_busy.depth - 1 times or more?), it turns out that a. For large numbers of MDLs on q_busy, the assumption needs to only be approximately true. b. For very small numbers of MDLs on q_busy (i.e. 2), the assumption needs to be strictly true or errant sweep-ups happen. So I suspect for the case of the CX23418 firmware only having 1 MDL and use giving it another MDL, the CX23418 might use the one we just gave it first - violating the assumption amd causing errant sweep ups. The fix is simple: don't sweep up a skipped buffer that meets the current skipped > = (q_busy.depth -1) criteria in the case of q_full.depth > q_free.depth + qbusy.depth Which says if we've got a lot of MDLs tied up waiting for the application to read them, don't both sweeping up potentially lost buffers until the q_busy.depth increases. Since "lost" MDLs stay on q_busy and are counted in q_busy.depth, this will always end up returning MDLs to the firmware as the application reads data and returns MDLs. Of course that's all speculation about the problem. If you could reproduce the condition and then # echo 271 > /sys/modules/cx18/parameters/debug to record the sequence of CX18_DE_SET_MDLs and DMA_DONE sequence numbers for the YUIV stream, it might provide conifrmation of what is going on. 271 is high volume messages for info, warning, mailbox, and dma debug messages. It will write a lot to your logs. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/23/2009 04:10 PM, Christoph Bartelmus wrote: Hi Jarod, on 23 Nov 09 at 14:17, Jarod Wilson wrote: Krzysztof Halasa wrote: [...] If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. Historically, this is true. No, it's not. I think you misunderstood the code. The comment may be a bit misleading, too. Early iMON devices did not decode in hardware and the part of the driver that Krzystof is referring to is translating a bit-stream of the sampled input data into pulse/space durations. Sorry, no, I know the newer devices don't actually send pulse/data info out to userspace, just hex codes that correspond to key presses. What I meant was "onboard decoding devices can operate as pure input devices or in classic lirc mode", leaving out the details on exactly what they were sending out to userspace. :) -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 v2] lirc driver for SoundGraph iMON IR receivers and displays
On 11/23/2009 07:58 AM, Mauro Carvalho Chehab wrote: Jarod Wilson wrote: lirc driver for SoundGraph iMON IR receivers and displays Successfully tested with multiple devices with and without displays. +static struct usb_device_id imon_usb_id_table[] = { + /* TriGem iMON (IR only) -- TG_iMON.inf */ + { USB_DEVICE(0x0aa8, 0x8001) }, ... Another set of USB vendor ID's... this time, vendors weren't described. The same comment I did on patch 2/3 applies here... IMO, we should really try to create a global list of vendors/devices on kernel. Of course this is not a non-go issue, as it is already present on several other USB drivers. My first thought is that a global list shared by everyone would be a pain to manage -- which upstream tree would be the entry point for additions? I think a global-within-lirc header would be just fine though. Most usb lirc drivers don't have very long lists, these two (mceusb and imon) are by far the longest ones. + + /* +* Translate received data to pulse and space lengths. +* Received data is active low, i.e. pulses are 0 and +* spaces are 1. +* +* My original algorithm was essentially similar to +* Changwoo Ryu's with the exception that he switched +* the incoming bits to active high and also fed an +* initial space to LIRC at the start of a new sequence +* if the previous bit was a pulse. +* +* I've decided to adopt his algorithm. +*/ + Before digging into all code details, am I wrong or this device has the pulse/space decoding inside the chip? The current generation of imon devices do onboard decoding, but the driver supports older imon devices as well, which do NOT do onboard decoding, and follow the code referenced by the above comment block. In this case, we shouldn't really be converting their IR keystroke events into a pseudo set of pulse/space marks, but use the standard events interface. And that's actually the default mode for the devices that do onboard decoding -- the key mappings are all in lirc_imon.h. A modparam can be used to override pure input mode and instead pass the decoded hex values out to userspace for lircd to handle. Its entirely possible we could split this driver into two, one that is for the older devices, and another for the newer devices that do onboard decoding, which is a pure input mode driver (and still usable with lirc via its devinput userspace driver). It'd be a lot of extra work at the moment though, and I have no older devices to test with, only the newer ones. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehab writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized key<>function mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. ... We need to handle more than one RC at a time, of course. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code<> key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). I think if the data is used to do the primary protocol decoding then it should be a separate interface that is processed by someone and then fed into input subsystem (either in-kernel or through uinput). Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. Current lircd actually inter-operates with the input subsystem quite well for any and all supported remotes if their keys are mapped in their respective lircd.conf file using standard input subsystem key names, and the lirc daemon started with the --uinput param. lircd decodes the raw IR, finds the mapping in its config, and happily passes it along to uinput. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add new TV cards of Beholder
Hi Working tm6000 driver is my next task. I'll start with tm6000 around New Year. With my best regards, Dmitry. > On Mon, Nov 23, 2009 at 4:28 PM, Mauro Carvalho Chehab > wrote: > > Hi Dmitri, > > > > I added this patch, but the driver is essentially broken. It would > > be wonderful if you have some time to fix it. > > > > Cheers, > > Mauro. > > Yeah, I saw his patch and was wondering why on Earth he submitted a > patch adding card support for a completely broken driver. How could > he have validated the patch is correct? > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: flicker/jumpy at the bottom of the video
Added following property to pipeline, now it is better, v4l2src always-copy=0 queue-size=4 regards Purush - Original Message From: Michael Trimarchi To: Purushottam R S Cc: linux-media@vger.kernel.org Sent: Mon, 23 November, 2009 9:01:16 PM Subject: Re: flicker/jumpy at the bottom of the video Purushottam R S wrote: > Hi , > > I am using latest gspca driver from dvb for camera driver. But I see bottom > of the video has flickering/jumping effect. > > I have "Zippys" web camera, which is from Z-Star. I have loaded the > following drivers. > 1. gspca_zc3xx 44832 0 - Live 0xbf01f000 > 2. gspca_main 23840 1 gspca_zc3xx, Live 0xbf014000 > 3. videodev 36672 1 gspca_main, Live 0xbf006000 > 4. v4l1_compat 14788 1 videodev, Live 0xbf00 > > But otherwise there is no issue with video. > > I tested using gst-launch pipeline. Can you try using vlc application. I have the same effect using v4l1 compat api Michael > > regards > Purush > > > > The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. > http://in.yahoo.com/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html