Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Le dimanche 17 juillet 2011 03:56:36 Mauro Carvalho Chehab, vous avez écrit : After all, you cannot connect both a DVB-C cable and a DVB-T antenna at the same time, so the vast majority of users won't ever want to switch modes at all. You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. As Antti and Rémi pointed, there are issues with some cable operators. Not sure how critical is that, but an userspace application changing it via sysfs might work while the applications are not ported to support both ways. Telling applications to use sysfs... I can see many ways that you might regret that in the future... Accessing sysfs directly from an application is against all the good practices I thought I had learnt regarding Linux. There is the theoretical possibility that udev gets explicit support for Linux DVB and exposes the properties nicely. But that would be rather inconvenient, and cannot be used to change properties. Antti/Rémi, how the current applications work with one physical frontend supporting both DVB-T and DVB-C? Do they allow to change channels from one to the other mode on a transparent way? I don't know. VLC does not care if you switch from DVB-T to DVB-C, to the DVD drive or to YouTube. Each channel (or at least each multiplex) is a different playlist item. So it'll close the all device nodes and (re)open them. There are obviously other applications at stake. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Le dimanche 17 juillet 2011 05:51:33 Andreas Oberritter, vous avez écrit : On 16.07.2011 18:37, Rémi Denis-Courmont wrote: Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. I know that there are cable operators which use DVB-T, but they don't use DVB-C simultaneously. This wouldn't make sense, unless they didn't want their customers to receive their signals. They do offer both simultaneously. DNA (formerly Welho) in Helsinki provides both DVB-T and DVB-C on the same cable, obviously on different frequencies. Is there any channel available on DVB-T which isn't available on DVB-C in this cable network? Probably, I wouldn't know. My S**g TV won't provision channels from both systems at the same time. And Linux does not support DVB-T on my TT-connect CT-3650 tuner. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Em 17-07-2011 04:39, Rémi Denis-Courmont escreveu: Le dimanche 17 juillet 2011 03:56:36 Mauro Carvalho Chehab, vous avez écrit : After all, you cannot connect both a DVB-C cable and a DVB-T antenna at the same time, so the vast majority of users won't ever want to switch modes at all. You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. As Antti and Rémi pointed, there are issues with some cable operators. Not sure how critical is that, but an userspace application changing it via sysfs might work while the applications are not ported to support both ways. Telling applications to use sysfs... I can see many ways that you might regret that in the future... I'm expressed it badly. What I meant to say is to have some sort of script or a specific application to allow users to change the delivery system, by changing the modprobe parameter, for the MFE drivers supported on = 3.0 Kernel that won't fit in the agreed approach, while applications don't support the adopted approach directly. Accessing sysfs directly from an application is against all the good practices I thought I had learnt regarding Linux. There is the theoretical possibility that udev gets explicit support for Linux DVB and exposes the properties nicely. But that would be rather inconvenient, and cannot be used to change properties. Antti/Rémi, how the current applications work with one physical frontend supporting both DVB-T and DVB-C? Do they allow to change channels from one to the other mode on a transparent way? I don't know. VLC does not care if you switch from DVB-T to DVB-C, to the DVD drive or to YouTube. Each channel (or at least each multiplex) is a different playlist item. So it'll close the all device nodes and (re)open them. There are obviously other applications at stake. -- 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: em28xx detection
Em 17-07-2011 16:14, Pupthai escreveu: is em2820 detected as em2860 lsusb Bus 001 Device 004: ID eb1a:2820 eMPIA Technology, Inc. dmesg | grep em28xx usbcore: registered new interface driver em28xx em28xx driver loaded em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) em28xx #0: chip ID is em2820 (or em2710) em28xx #0: board has no eeprom em28xx #0: found i2c device @ 0x4a [saa7113h] em28xx #0: Your board has no unique USB ID. em28xx #0: A hint were successfully done, based on i2c devicelist hash. em28xx #0: This method is not 100% failproof. em28xx #0: If the board were missdetected, please email this log to: em28xx #0: V4L Mailing List linux-media@vger.kernel.org em28xx #0: Board detected as EM2860/SAA711X Reference Design em28xx #0: Identified as EM2860/SAA711X Reference Design (card=19) em28xx #0: Registering snapshot button... input: em28xx snapshot button as /devices/pci:00/:00:1d.7/usb1/1-3/input/input1 em28xx #0: Config register raw data: 0x00 em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 video device registered as video0 Nothing works with this device anymore and it used to work with application motion and vlc still works fine in windows apps and windows vlc sees a em2820 Your device doesn't have an eeprom. So, there's no reliable way to identify what board you have. Kernel can try to hint, but there will always be cases where two different boards will match such hint. On such cases (like yours), you'll need to modprobe em28xx with card= parameter. If your device used to be supported by the in-kernel em28xx driver, all you need is to add something like: options em28xx card=20 (well, replacing 20 by the correct card number from Documentation/video4linux/CARDLIST.em28xx) If otherwise your board is not listed there, then you'll need to discover what are the correct setups for it and send us a patch adding a new card number with your configs. 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][saa7134] do not change mute state for capturing audio
15.07.2011 05:38, Mauro Carvalho Chehab wrote: If you want, feel free to propose a patch fixing that logic at saa7134, instead of just removing it. Hi, I've just verified that pulseaudio indeed does the sound capturing on startup: --- saa7134[0]/alsa: saa7134[0] at 0xfe8fb800 irq 22 registered as card 2 saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: irq: field oops [even] --- So your proposal is not going to fix anything at all. Can we get back to discussing/applying mine then? And if the other drivers has that autounmute logic, then I suggest removing it there as well. You have not named any use-case for it, so I think there is none. I also think that the whole auto-unmute logic in your drivers is entirely flawed: for instance, I don't think recording from the sound card will automatically unmute its line-in or something else, so you are probably not following the generic alsa style here. I am adding alsa-devel to CC to find out what they think about that whole auto-unmute question. -- 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
[GIT PATCHES FOR 3.1] v4l-dvb: add and use poll_requested_events() function
Hi Mauro, This patch series adds the poll_requested_events() function and uses it in the V4L2 core and the ivtv driver. The poll patch is unchanged from the RFCv3 patch posted a week ago and the other patches are unchanged from the RFCv1 patch series posted last Wednesday on the linux-media list. Tested with vivi and ivtv. Regards, Hans The following changes since commit bec969c908bb22931fd5ab8ecdf99de8702a6a31: [media] v4l: s5p-tv: add TV Mixer driver for Samsung S5P platform (2011-07-14 13:09:48 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git poll Hans Verkuil (6): poll: add poll_requested_events() function ivtv: only start streaming in poll() if polling for input. videobuf2: only start streaming in poll() if so requested by the poll mask. videobuf: only start streaming in poll() if so requested by the poll mask. videobuf2-core: also test for pending events. vivi: let vb2_poll handle events. drivers/media/video/ivtv/ivtv-fileops.c |6 ++- drivers/media/video/videobuf-core.c |3 +- drivers/media/video/videobuf2-core.c| 48 +- drivers/media/video/vivi.c |9 +- fs/eventpoll.c | 19 +-- fs/select.c | 38 +++- include/linux/poll.h|7 - 7 files changed, 78 insertions(+), 52 deletions(-) -- 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][saa7134] do not change mute state for capturing audio
Hi Stas, Em 17-07-2011 06:44, Stas Sergeev escreveu: 15.07.2011 05:38, Mauro Carvalho Chehab wrote: If you want, feel free to propose a patch fixing that logic at saa7134, instead of just removing it. Hi, I've just verified that pulseaudio indeed does the sound capturing on startup: --- saa7134[0]/alsa: saa7134[0] at 0xfe8fb800 irq 22 registered as card 2 saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 = fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 = fmt=0xdd swap=- saa7134[0]/alsa: irq: field oops [even] (Added Lennart to the c/c list) If pulseaudio is starting sound capture at startup, then it is either a pulseaudio miss-configuration or a bug there. I fail to understand why pulseaudio would start capturing sound from a V4L audio at startup. I think that this is not the default for pulseaudio, though, as you're the only one complaining about that, and I never saw such behavior in the time I was using pulseaudio here. I don't know enough about pulseaudio to help on this issue, nor I'm using it currently, so I can't test anything pulsaudio-related. Lennart, Could you please help us with this issue? Thanks! Mauro --- So your proposal is not going to fix anything at all. Can we get back to discussing/applying mine then? And if the other drivers has that autounmute logic, then I suggest removing it there as well. You have not named any use-case for it, so I think there is none. I also think that the whole auto-unmute logic in your drivers is entirely flawed: for instance, I don't think recording from the sound card will automatically unmute its line-in or something else, so you are probably not following the generic alsa style here. I am adding alsa-devel to CC to find out what they think about that whole auto-unmute question. -- 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][saa7134] do not change mute state for capturing audio
17.07.2011 15:51, Mauro Carvalho Chehab wrote: (Added Lennart to the c/c list) If pulseaudio is starting sound capture at startup, then it is either a pulseaudio miss-configuration or a bug there. Why? I think that this is not the default for pulseaudio, though, as you're the only one complaining about that, and I never saw such behavior in the time I was using pulseaudio here. I've seen such a problem mentioned on the russion linux resource a few years ago... The reason why it was never mentioned on that list, is probably that noone tracked it down to the saa7134_alsa driver yet. But maybe the reason is different, ok, lets see what Lennart thinks. -- 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 4/6] V4L: sh_mobile_csi2: switch away from using the soc-camera bus notifier
On Sat, Jul 16, 2011 at 02:13:54AM +0200, Guennadi Liakhovetski wrote: This moves us one more step closer to eliminating the soc-camera bus and devices on it. Besides, as a side effect, CSI-2 runtime PM on sh-mobile secomes finer grained now: we only have to power on the interface, when the device nodes are open. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- arch/arm/mach-shmobile/board-ap4evb.c | 12 +-- drivers/media/video/sh_mobile_ceu_camera.c | 117 ++-- drivers/media/video/sh_mobile_csi2.c | 135 +++- include/media/sh_mobile_ceu.h | 10 ++- include/media/sh_mobile_csi2.h |8 +- 5 files changed, 180 insertions(+), 102 deletions(-) Acked-by: Paul Mundt let...@linux-sh.org -- 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 6/6] V4L: soc-camera: remove soc-camera bus and devices on it
On Sat, Jul 16, 2011 at 02:14:03AM +0200, Guennadi Liakhovetski wrote: Now that v4l2 subdevices have got their own device objects, having one more device in soc-camera clients became redundant and confusing. This patch removes those devices and the soc-camera bus, they used to reside on. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- This one looks pretty big, most of it are just 10-liners. It removes more than a 100 lines of code. Tested on sh-mobile, pxa270, i.MX31. Compile tested with all soc-camera hosts and clients. Hope it doesn't break too many things, if it does, we'll have the whole 3.1-rc timeframe to fix them. Acked-by: Paul Mundt let...@linux-sh.org -- 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: Imon module Oops and kernel hang
On Sun, 2011-07-17 at 11:38 +1000, Chris W wrote: On 17/07/11 10:43, Andy Walls wrote: This is an obviously repeatable NULL pointer dereference in rc_g_keycode_from_table(). The faulting line of code in both cases disasembles to: 1e: 8b 80 dc 00 00 00 mov0xdc(%eax),%eax %eax obviously holds the value 0 (NULL). But I'm having a hard time telling to where exactly that line of assembly corresponds in rc_g_keycode_from_table(). And I can't tell from the source which data structure has something at offset 0xdc that gets derefernced early: struct rc_dev or struct rc_map. Could you provide the output of $ locate rc-core.ko $ objdump -d -l /blah/blah/drivers/media/rc/rc-core.ko for the rc_g_keycode_from_table() function? I have a few copies lying about now. This is from my current running kernel /lib/modules/2.6.38-gentoo-r6/kernel/drivers/media/rc/rc-core.ko and the partial objdump and corresponding oops/crash output: Thanks. 0450 rc_g_keycode_from_table: rc_g_keycode_from_table(): 450: 55 push %ebp 451: 89 e5 mov%esp,%ebp 453: 57 push %edi 454: 56 push %esi 455: 53 push %ebx 456: 83 ec 24sub$0x24,%esp Store the (struct rc_dev *) dev input argument on the stack 459: 89 45 e8mov%eax,-0x18(%ebp) local_irq_save(flags): 45c: 9c pushf 45d: 8f 45 ecpopl -0x14(%ebp) 460: fa cli preempt_disable(): 461: 89 e0 mov%esp,%eax 463: 25 00 e0 ff ff and$0xe000,%eax 468: ff 40 14incl 0x14(%eax) Move (struct rc_dev *) dev into %eax 46b: 8b 45 e8mov-0x18(%ebp),%eax dev-rc_map-lock 46e: 8b 80 d4 00 00 00 mov0xd4(%eax),%eax But that's where the Oops always happens, so the dev input argument to the function is NULL. Someone familiar with the driver/media/rc/imon.c file needs to figure out how rc_g_keycode_from_table() can be called with a NULL first argument: ictx-rdev is NULL when rc_g_keycode_from_table(ictx-rdev,...) is called. There might be some race at driver initialization, given that at first look ictx-rdev being NULL seems impossible. Your stack backtraces always indicate some sort of IRQ context, so maybe that matters. Regards, Andy 474: 89 c3 mov%eax,%ebx 476: 89 45 f0mov%eax,-0x10(%ebp) 479: 4b dec%ebx 47a: 78 38 js 4b4 rc_g_keycode_from_table+0x64 47c: 8b 45 e8mov-0x18(%ebp),%eax 47f: 31 c9 xor%ecx,%ecx 481: 8b b0 cc 00 00 00 mov0xcc(%eax),%esi 487: eb 0e jmp497 rc_g_keycode_from_table+0x47 489: 8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi 490: 8d 48 01lea0x1(%eax),%ecx 493: 39 d9 cmp%ebx,%ecx 495: 7f 1d jg 4b4 rc_g_keycode_from_table+0x64 497: 8d 04 0blea(%ebx,%ecx,1),%eax 49a: 89 c7 mov%eax,%edi 49c: c1 ef 1fshr$0x1f,%edi 49f: 8d 04 07lea(%edi,%eax,1),%eax 4a2: d1 f8 sar%eax 4a4: 8d 3c c6lea(%esi,%eax,8),%edi 4a7: 3b 17 cmp(%edi),%edx 4a9: 77 e5 ja 490 rc_g_keycode_from_table+0x40 4ab: 73 3b jae4e8 rc_g_keycode_from_table+0x98 4ad: 8d 58 fflea-0x1(%eax),%ebx 4b0: 39 d9 cmp%ebx,%ecx 4b2: 7e e3 jle497 rc_g_keycode_from_table+0x47 4b4: 31 db xor%ebx,%ebx 4b6: ff 75 ecpushl -0x14(%ebp) 4b9: 9d popf 4ba: 89 e0 mov%esp,%eax 4bc: 25 00 e0 ff ff and$0xe000,%eax 4c1: ff 48 14decl 0x14(%eax) 4c4: 8b 40 08mov0x8(%eax),%eax 4c7: a8 08 test $0x8,%al 4c9: 75 52 jne51d rc_g_keycode_from_table+0xcd 4cb: 85 db test %ebx,%ebx 4cd: 74 0a je 4d9 rc_g_keycode_from_table+0x89 4cf: 8b 3d 00 00 00 00 mov0x0,%edi 4d5: 85 ff test %edi,%edi 4d7: 7f 19 jg 4f2
Smart card reader support for Anysee DVB devices
Hi,
I have developed smart card reader support for the Anysee devices by
extending Antti Palosaari's driver. I attached the patches for it. It
registers a character device named /dev/anysee_scN for each Anysee
device.
The character device supports two ioctl's (see anysee_sc), one for
detecting the presence of a card, the other one for resetting the card
and querying the ATR. The write() operation writes to the card by
packaging the bytes into USB commands. The read() operation issues an
appropriate command over USB and returns the reply. I have also
written a simple OpenCT driver (attached) which shows the usage.
I would like to have the kernel driver included in the official
sources. For this reason I corresponded with Antti, and he suggested
the perhaps the kernel driver should have a lower-level interface. I
had the following proposal:
We would continue having the two ioctls, ANYSEE_SC_ACTIVATE and
ANYSEE_SC_PRESENT, however, ANYSEE_SC_ACTIVATE would do only the
register reading and writing.
Besides these two we need access to the anysee_ctrl_msg() function
somehow. I think the cleanest way would be via another ioctl() call in
which we would pass the return buffer as well, with the length so that
we know how many bytes to copy. Another possibility would be that a
call to write() calls anysee_ctrl_msg() and stores the return data in
a 64 byte buffer that we allocate for each device. The read()
following a write() would read this buffer, then discard it. Further
read() attempts would fail with EAGAIN, or we could maintain an offset
into the 64 byte buffer, and read as long as there is data, and fail
only then. A write() would cause losing any unread data.
What do you think?
Thanks,
Istvan
patch
Description: Binary data
#ifndef ANYSEE_SC_H
#define ANYSEE_SC_H
#include linux/ioctl.h
#define ANYSEE_SC_IOC_MAGIC 's'
struct anysee_sc_activate {
unsigned atr_length;
unsigned char atr[33];
};
#define ANYSEE_SC_ACTIVATE _IOR(ANYSEE_SC_IOC_MAGIC, 1, struct anysee_sc_activate)
#define ANYSEE_SC_PRESENT _IO(ANYSEE_SC_IOC_MAGIC, 2)
#endif
#include internal.h
#include anysee_sc.h
#include string.h
#include fcntl.h
static int anysee_open(ifd_reader_t* reader, const char* name)
{
ifd_device_t* dev = 0;
int fd = -1;
const char* device_name = 0;
ifd_debug(1, anysee_open: name='%s'\n, name);
device_name = strchr(name, ':');
if (device_name==0) return -1;
++device_name;
fd = open(device_name, O_RDWR);
ifd_debug(2, anysee_open: fd=%d\n, fd);
if (fd0) return -1;
reader-name = Anysee DVB USB card reader;
reader-nslots = 1;
dev = ifd_device_new(name, 0, sizeof(*dev));
reader-device = dev;
dev-timeout = 1000;
dev-fd = fd;
dev-type = IFD_DEVICE_TYPE_OTHER;
return 0;
}
static int anysee_close(ifd_reader_t * reader)
{
return close(reader-device-fd);
}
static int anysee_activate(ifd_reader_t *reader)
{
return 0;
}
static int anysee_deactivate(ifd_reader_t *reader)
{
return 0;
}
static int anysee_card_status(ifd_reader_t *reader, int slot, int *status)
{
int rv = ioctl(reader-device-fd, ANYSEE_SC_PRESENT);
ifd_debug(2, anysee_card_status: rv=%d\n, rv);
if (rv0) {
return -1;
} else {
*status = (rv==0) ? 0 : IFD_CARD_PRESENT;
return 0;
}
}
static int anysee_card_reset(ifd_reader_t *reader, int slot, void *atr, size_t atr_len)
{
struct anysee_sc_activate activate;
if (ioctl(reader-device-fd, ANYSEE_SC_ACTIVATE, activate)0) {
ifd_debug(2, anysee_card_reset: failed\n);
return -1;
} else {
size_t length = (atr_lenactivate.atr_length) ? atr_len : activate.atr_length;
memcpy(atr, activate.atr, length);
return length;
}
}
static int anysee_send(ifd_reader_t *reader, unsigned int dad,
const unsigned char *buffer, size_t len)
{
return write(reader-device-fd, buffer, len);
}
static int anysee_recv(ifd_reader_t *reader, unsigned int dad,
unsigned char *buffer, size_t len,
long timeout)
{
return read(reader-device-fd, buffer, len);
}
static struct ifd_driver_ops anysee_ops;
void ifd_anysee_register()
{
anysee_ops.open = anysee_open;
anysee_ops.close = anysee_close;
anysee_ops.activate = anysee_activate;
anysee_ops.deactivate = anysee_deactivate;
anysee_ops.card_status = anysee_card_status;
anysee_ops.card_reset = anysee_card_reset;
anysee_ops.send = anysee_send;
anysee_ops.recv = anysee_recv;
ifd_driver_register(anysee, anysee_ops);
}
Announcing v4l-utils-0.8.5
Hi, I'm happy to announce the release of v4l-utils-0.8.5. We're back to our regular boring releases again :) Still this release contains some fixes / things which are good to get out there, hence a new release. Full changelog: v4l-utils-0.8.5 --- * Utils changes * parse_em28xx_drxk.pl: New parser for dumps of em28xx with drxk frontend (mchehab) * qv4l2: Add support for bitmap controls (hverkuil) * v4l2-ctl: add support for the new bitmask control type (hverkuil) * v4l2-ctl: add support for the control event (hverkuil) * v4l2-ctl: small bugfixes (hverkuil) * v4l2-compliance: various new tests (hverkuil) * lib_media_dev: various fixes / cleanups (hdegoede) * libv4l changes * Add some more laptop models to the upside down devices table (hdegoede) * Add support for SE401 pixelformat (hdegoede) * Software autogain tweaks (hdegoede) Go get it here: http://linuxtv.org/downloads/v4l-utils/v4l-utils-0.8.5.tar.bz2 You can always find the latest developments here: http://git.linuxtv.org/v4l-utils.git Regards, Hans -- 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/5] mt9m111: set inital return values to zero
On Thu, 14 Jul 2011, Laurent Pinchart wrote:
Hi Michael,
There's no need to set initial return values to zero if they're assigned to
in
all code paths.
[snip]
*client) static int mt9m111_enable(struct i2c_client *client)
{
struct mt9m111 *mt9m111 = to_mt9m111(client);
- int ret;
+ int ret = 0;
ret = reg_set(RESET, MT9M111_RESET_CHIP_ENABLE);
if (!ret)
This is a clear example, ret will never be used uninitialized. Initializing
it
to 0 would be a waste of resources (although in this case it will probably be
optimized out by the compiler).
Seconded. When I wrote:
+static int mt9m111_reg_mask(struct i2c_client *client, const u16 reg,
+ const u16 data, const u16 mask)
+{
+ int ret;
+
+ ret = mt9m111_reg_read(client, reg);
+ return mt9m111_reg_write(client, reg, (ret ~mask) | data);
Ok, I feel ashamed, that I have accepted this driver in this form... It is
full of such buggy error handling instances, and this adds just one
more... So, I would very appreciate if you could clean them up - before
this patch, and handle this error properly too, otherwise I might do this
myself some time... And, just noticed - static int lastpage from
reg_page_map_set() must be moved into struct mt9m111, if this driver shall
be able to handle more than one sensor simultaneously, at least in
principle...
I didn't mean to init all return codes to 0. I meant, before using a
result of a reg_read(), you have to check it for error. I.e.,
+ ret = mt9m111_reg_read(client, reg);
+ if (ret = 0)
+ ret = mt9m111_reg_write(client, reg, (ret ~mask) | data);
+ return ret;
In principle, after the updated version of your patch mt9m111: rewrite
set_pixfmt all errors, returned by reg_read(), reg_write() and reg_mask()
are checked, even if some of them I would do a bit differently. E.g., I
would propagate the error code instead of replacing it with -EIO, etc. But
in principle all error cases are handled, so, we can live with that for
now. I'm dropping this patch.
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: [PATCH 3/5] mt9m111: move lastpage to struct mt9m111 for multi instances
On Thu, 14 Jul 2011, Laurent Pinchart wrote:
Hi Michael,
On Tuesday 12 July 2011 17:39:04 Michael Grzeschik wrote:
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/media/video/mt9m111.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index e08b46c..8ad99a9 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -170,6 +170,7 @@ struct mt9m111 {
enum mt9m111_context context;
struct v4l2_rect rect;
const struct mt9m111_datafmt *fmt;
+ int lastpage;
unsigned int gain;
unsigned char autoexposure;
unsigned char datawidth;
@@ -192,17 +193,17 @@ static int reg_page_map_set(struct i2c_client
*client, const u16 reg) {
int ret = 0;
u16 page;
- static int lastpage = -1; /* PageMap cache value */
You're loosing lastpage initialization to -1.
Seconded. A fixed version of this patch will ve welcome for 3.2.
Thanks
Guennadi
+ struct mt9m111 *mt9m111 = to_mt9m111(client);
page = (reg 8);
- if (page == lastpage)
+ if (page == mt9m111-lastpage)
return 0;
if (page 2)
return -EINVAL;
ret = i2c_smbus_write_word_data(client, MT9M111_PAGE_MAP, swab16(page));
if (!ret)
- lastpage = page;
+ mt9m111-lastpage = page;
return ret;
}
--
Regards,
Laurent Pinchart
---
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: [PATCH 2/5] mt9m111: fix missing return value check mt9m111_reg_clear
On Tue, 12 Jul 2011, Michael Grzeschik wrote: Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de Applied, thanks --- drivers/media/video/mt9m111.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index f10dcf0..e08b46c 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -248,7 +248,9 @@ static int mt9m111_reg_clear(struct i2c_client *client, const u16 reg, int ret = 0; ret = mt9m111_reg_read(client, reg); - return mt9m111_reg_write(client, reg, ret ~data); + if (ret = 0) + ret = mt9m111_reg_write(client, reg, ret ~data); + return ret; } static int mt9m111_set_context(struct i2c_client *client, -- 1.7.5.4 --- 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: [PATCH 5/5] mt9m111: make use of testpattern
On Tue, 12 Jul 2011, Michael Grzeschik wrote:
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
Changes v1 - v2
* removed ifdef DEBUG
drivers/media/video/mt9m111.c | 57
+
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 7eb2e4a..a3463d9 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -87,6 +87,7 @@
*/
#define MT9M111_OPER_MODE_CTRL 0x106
#define MT9M111_OUTPUT_FORMAT_CTRL 0x108
+#define MT9M111_TEST_PATTERN_GEN 0x148
#define MT9M111_REDUCER_XZOOM_B 0x1a0
#define MT9M111_REDUCER_XSIZE_B 0x1a1
#define MT9M111_REDUCER_YZOOM_B 0x1a3
@@ -103,6 +104,15 @@
#define MT9M111_OPMODE_AUTOWHITEBAL_EN (1 1)
#define MT9M111_OUTFMT_FLIP_BAYER_COL (1 9)
#define MT9M111_OUTFMT_FLIP_BAYER_ROW (1 8)
+#define MT9M111_TST_PATT_OFF (0 0)
+#define MT9M111_TST_PATT_1 (1 0)
+#define MT9M111_TST_PATT_2 (2 0)
+#define MT9M111_TST_PATT_3 (3 0)
+#define MT9M111_TST_PATT_4 (4 0)
+#define MT9M111_TST_PATT_5 (5 0)
+#define MT9M111_TST_PATT_6 (6 0)
+#define MT9M111_TST_PATT_COLORBARS (7 0)
+#define MT9M111_TST_PATT_FORCE_WB_GAIN_1 (1 7)
#define MT9M111_OUTFMT_PROCESSED_BAYER (1 14)
#define MT9M111_OUTFMT_BYPASS_IFP(1 10)
#define MT9M111_OUTFMT_INV_PIX_CLOCK (1 9)
@@ -138,6 +148,11 @@
#define MT9M111_MAX_HEIGHT 1024
#define MT9M111_MAX_WIDTH1280
+static int testpattern;
+module_param(testpattern, int, S_IRUGO);
+MODULE_PARM_DESC(testpattern, Test pattern: a number from 1 to 10, 0 for
+ normal usage);
+
I already replied, that I do not like using a module parameter for this.
Thanks
Guennadi
/* MT9M111 has only one fixed colorspace per pixelcode */
struct mt9m111_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -464,6 +479,7 @@ static int mt9m111_set_pixfmt(struct i2c_client *client,
enum v4l2_mbus_pixelcode code)
{
u16 data_outfmt1 = 0, data_outfmt2 = 0, mask_outfmt1, mask_outfmt2;
+ u16 pattern = 0;
int ret = 0;
switch (code) {
@@ -531,6 +547,47 @@ static int mt9m111_set_pixfmt(struct i2c_client *client,
if (!ret)
ret = reg_mask(OUTPUT_FORMAT_CTRL, data_outfmt1, mask_outfmt1);
+ switch (testpattern) {
+ case 1:
+ pattern = MT9M111_TST_PATT_1 | MT9M111_TST_PATT_FORCE_WB_GAIN_1;
+ break;
+ case 2:
+ pattern = MT9M111_TST_PATT_2 | MT9M111_TST_PATT_FORCE_WB_GAIN_1;
+ break;
+ case 3:
+ pattern = MT9M111_TST_PATT_3 | MT9M111_TST_PATT_FORCE_WB_GAIN_1;
+ break;
+ case 4:
+ pattern = MT9M111_TST_PATT_4 | MT9M111_TST_PATT_FORCE_WB_GAIN_1;
+ break;
+ case 5:
+ pattern = MT9M111_TST_PATT_5 | MT9M111_TST_PATT_FORCE_WB_GAIN_1;
+ break;
+ case 6:
+ pattern = MT9M111_TST_PATT_6 | MT9M111_TST_PATT_FORCE_WB_GAIN_1;
+ break;
+ case 7:
+ pattern = MT9M111_TST_PATT_COLORBARS |
+ MT9M111_TST_PATT_FORCE_WB_GAIN_1;
+ break;
+ case 8:
+ data_outfmt2 |= MT9M111_OUTFMT_TST_RAMP_COL;
+ break;
+ case 9:
+ data_outfmt2 |= MT9M111_OUTFMT_TST_RAMP_ROW;
+ break;
+ case 10:
+ data_outfmt2 |= MT9M111_OUTFMT_TST_RAMP_FRAME;
+ break;
+ }
+
+ dev_dbg(client-dev, %s: using testpattern %d\n, __func__,
+ testpattern);
+
+ if (!ret)
+ ret = mt9m111_reg_set(client,
+ MT9M111_TEST_PATTERN_GEN, pattern);
+
if (!ret)
ret = reg_mask(OUTPUT_FORMAT_CTRL2_A, data_outfmt2,
mask_outfmt2);
--
1.7.5.4
---
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
[PULL] V4L, soc-camera: second pull for 3.1
Hi Mauro The following changes since commit bec969c908bb22931fd5ab8ecdf99de8702a6a31: [media] v4l: s5p-tv: add TV Mixer driver for Samsung S5P platform (2011-07-14 13:09:48 -0300) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.1 Bastian Hecht (1): V4L: initial driver for ov5642 CMOS sensor Guennadi Liakhovetski (8): V4L: pxa-camera: switch to using standard PM hooks V4L: soc-camera: remove now unused soc-camera specific PM hooks V4L: soc-camera: group struct field initialisations together V4L: add media bus configuration subdev operations V4L: sh_mobile_csi2: switch away from using the soc-camera bus notifier V4L: soc-camera: un-export the soc-camera bus V4L: soc-camera: remove soc-camera bus and devices on it V4L: sh_mobile_ceu_camera: fix Oops when USERPTR mapping fails Michael Grzeschik (2): V4L: mt9m111: fix missing return value check mt9m111_reg_clear V4L: mt9m111: rewrite set_pixfmt arch/arm/mach-shmobile/board-ap4evb.c | 12 +- arch/arm/mach-shmobile/board-mackerel.c| 13 +- arch/sh/boards/mach-ap325rxa/setup.c | 15 +- drivers/media/video/Kconfig|6 + drivers/media/video/Makefile |3 +- drivers/media/video/atmel-isi.c| 64 +- drivers/media/video/mt9m001.c | 14 +- drivers/media/video/mt9m111.c | 189 ++ drivers/media/video/mt9t031.c |3 +- drivers/media/video/mt9t112.c | 10 +- drivers/media/video/mt9v022.c | 10 +- drivers/media/video/mx1_camera.c | 42 +- drivers/media/video/mx2_camera.c | 46 +- drivers/media/video/mx3_camera.c | 56 +- drivers/media/video/omap1_camera.c | 52 +- drivers/media/video/ov2640.c | 13 +- drivers/media/video/ov5642.c | 1011 drivers/media/video/ov772x.c | 10 +- drivers/media/video/ov9640.c | 13 +- drivers/media/video/ov9740.c | 13 +- drivers/media/video/pxa_camera.c | 66 +- drivers/media/video/rj54n1cb0c.c |7 +- drivers/media/video/sh_mobile_ceu_camera.c | 199 -- drivers/media/video/sh_mobile_csi2.c | 135 ++-- drivers/media/video/soc_camera.c | 264 +++- drivers/media/video/soc_camera_platform.c | 10 +- drivers/media/video/tw9910.c | 10 +- include/media/sh_mobile_ceu.h | 10 +- include/media/sh_mobile_csi2.h |8 +- include/media/soc_camera.h | 29 +- include/media/soc_camera_platform.h| 15 +- include/media/v4l2-chip-ident.h|1 + include/media/v4l2-mediabus.h | 66 ++ include/media/v4l2-subdev.h| 10 + 34 files changed, 1707 insertions(+), 718 deletions(-) create mode 100644 drivers/media/video/ov5642.c 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: [PATCH v4 4/5] mt9m111: rewrite set_pixfmt
On Tue, 12 Jul 2011, Michael Grzeschik wrote:
added new bit offset defines,
more supported BE colour formats
and also support BGR565 swapped pixel formats
removed pixfmt helper functions and option flags
setting the configuration register directly in set_pixfmt
added reg_mask function
reg_mask is basically the same as clearing setting registers,
but it is more convenient and faster (saves one rw cycle).
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
Applied after pretty heavy modifications. (1) forward-ported to the
current tree, (2) removed Bayer swapping, as discussed earlier, (3)
removed double bitfield definitions. Please, check out
http://git.linuxtv.org/gliakhovetski/v4l-dvb.git?a=shortlog;h=refs/heads/for-3.1
and see, if I haven't inadvertently broken anything.
Thanks
Guennadi
---
Changes v1 - v2
* removed unrelated OPMODE handling in this function
Changes v2 - v3
* squashed: [PATCH 04/11] mt9m111: added new bit offset defines
* squashed: [PATCH 08/11] mt9m111: added reg_mask function
Changes v3 - v4
* removed wrong formats V4L2_MBUS_FMT_{YVYU8,YUYV8}_2X8_BE
* fixed some return value handling
drivers/media/video/mt9m111.c | 175
++---
1 files changed, 77 insertions(+), 98 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 8ad99a9..7eb2e4a 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -63,6 +63,12 @@
#define MT9M111_RESET_RESTART_FRAME (1 1)
#define MT9M111_RESET_RESET_MODE (1 0)
+#define MT9M111_RM_FULL_POWER_RD (0 10)
+#define MT9M111_RM_LOW_POWER_RD (1 10)
+#define MT9M111_RM_COL_SKIP_4X (1 5)
+#define MT9M111_RM_ROW_SKIP_4X (1 4)
+#define MT9M111_RM_COL_SKIP_2X (1 3)
+#define MT9M111_RM_ROW_SKIP_2X (1 2)
#define MT9M111_RMB_MIRROR_COLS (1 1)
#define MT9M111_RMB_MIRROR_ROWS (1 0)
#define MT9M111_CTXT_CTRL_RESTART(1 15)
@@ -95,7 +101,8 @@
#define MT9M111_OPMODE_AUTOEXPO_EN (1 14)
#define MT9M111_OPMODE_AUTOWHITEBAL_EN (1 1)
-
+#define MT9M111_OUTFMT_FLIP_BAYER_COL (1 9)
+#define MT9M111_OUTFMT_FLIP_BAYER_ROW (1 8)
#define MT9M111_OUTFMT_PROCESSED_BAYER (1 14)
#define MT9M111_OUTFMT_BYPASS_IFP(1 10)
#define MT9M111_OUTFMT_INV_PIX_CLOCK (1 9)
@@ -113,6 +120,7 @@
#define MT9M111_OUTFMT_SWAP_YCbCr_C_Y(1 1)
#define MT9M111_OUTFMT_SWAP_RGB_EVEN (1 1)
#define MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr (1 0)
+#define MT9M111_OUTFMT_SWAP_RGB_R_B (1 0)
/*
* Camera control register addresses (0x200..0x2ff not implemented)
@@ -122,6 +130,8 @@
#define reg_write(reg, val) mt9m111_reg_write(client, MT9M111_##reg, (val))
#define reg_set(reg, val) mt9m111_reg_set(client, MT9M111_##reg, (val))
#define reg_clear(reg, val) mt9m111_reg_clear(client, MT9M111_##reg, (val))
+#define reg_mask(reg, val, mask) mt9m111_reg_mask(client, MT9M111_##reg, \
+ (val), (mask))
#define MT9M111_MIN_DARK_ROWS8
#define MT9M111_MIN_DARK_COLS26
@@ -153,7 +163,11 @@ static const struct mt9m111_datafmt
mt9m111_colour_fmts[] = {
{V4L2_MBUS_FMT_UYVY8_2X8, V4L2_COLORSPACE_JPEG},
{V4L2_MBUS_FMT_VYUY8_2X8, V4L2_COLORSPACE_JPEG},
{V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
};
@@ -177,10 +191,6 @@ struct mt9m111 {
unsigned int powered:1;
unsigned int hflip:1;
unsigned int vflip:1;
- unsigned int swap_rgb_even_odd:1;
- unsigned int swap_rgb_red_blue:1;
- unsigned int swap_yuv_y_chromas:1;
- unsigned int swap_yuv_cb_cr:1;
unsigned int autowhitebalance:1;
};
@@ -254,6 +264,17 @@ static int mt9m111_reg_clear(struct i2c_client *client,
const u16 reg,
return ret;
}
+static int mt9m111_reg_mask(struct i2c_client *client, const u16 reg,
+ const u16 data, const u16 mask)
+{
+ int ret = 0;
+
+ ret = mt9m111_reg_read(client, reg);
+ if (ret = 0)
+ ret = mt9m111_reg_write(client, reg, (ret ~mask) | data);
+ return ret;
+}
+
static int mt9m111_set_context(struct i2c_client *client,
enum mt9m111_context ctxt)
{
@@ -315,78 +336,6 @@ static int mt9m111_setup_rect(struct i2c_client *client,
return ret;
}
-static int
[cron job] v4l-dvb daily build: 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:Sun Jul 17 19:00:31 CEST 2011 git hash:9bc5f6fa12c9e3e1e73e66bfabe9d463ea779b08 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
PATCH add drx firmware extraction routine for hauppauge 930c
I'm trying to get this device supported starting from Mauro's work on H5 Here is the firmware extraction for hauppauge hvr930c hardware Signed-off-by: Eddi De Pieri e...@depieri.net get_dvb_firmware.diff Description: Binary data
Start of v4l-utils-0.9.x devel cycle, break of libv4lconvert ABI
Hi All, With the upcoming support for libv4l2 plugins we need to break the ABI for libv4lconvert, this is a good moment to start a bit more unstable v4l-utils / libv4l tree where we can make some other changes as well. v4l-utils follows the classic odd unstable / even stable release numbering, this is the start of a new 0.9.x dev cycle leading to a 0.10.x (or maybe a 1.x) release. The plan for 0.9.x is to: 1) Keep the libv4l1 and libv4l2 ABI's compatible with 0.8.x 2) Change the libv4lconvert ABI, changing the soname to libv4lconvert.so.1 (from libv4lconvert.so.0), this is needed to be able to add plugin support to libv4l2 3) Allow for somewhat more adventurous changes, until later in the 0.9.x cycle, when things should stabilize again Note WRT 2): a) There is no promise of a stable libv4lconvert.so.1 ABI until 0.10.0 is released! Note b) This is not really a big deal, only qv4l2 (which is shipped together with libv4lconvert) and Jean-Francois Moine's svv use libv4lconvert directly AFAIK. I've already pushed the initial plugin support to the v4l-utils git repo, other things I plan to do is: -think about how libv4lconvert / control / processing fit together, probably redesign parts and allow for processing plugins, which can' then also bring along their own fake controls. -change how the upside down table works, making it more flexible, in the form of being able to say: if system_vendor is in this list and product_name is in this list, and usb vendor+prod_id is in this list then it is upside down This is mostly for Asus where they tend to mix and match a given set of internal laptop webcams against there entire portfolio of laptops, usually in a chassis which has an upside down mount for the cam, but not always ... -maybe, just maybe add support for software autofocus (this would be a new processing plugin) Regards, Hans -- 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 v4 1/1] libv4l: Add plugin support to libv4l
Hi,
Sorry it took so long, but I've just merged the plugin
support into v4l-utils git. I did make some minor mods /
bugfixes before merging, see the commit message in git.
Regards,
Hans
p.s.
I think we should expand the plugin support with support
for a output devices, iow add a write() dev_op. If you
guys agree I can easily do so myself, we should do this
asap before people start depending on the ABI
(although there is no ABI stability promise until I
release 0.10.x, see my message to the list wrt
the start of the 0.9.x cycle).
While on the subject of keeping the plugin ABI, I suggest
that we add a number of extra dev_ops named reserved1 --
reserved8 for future use and a comment that these should
all be set to NULL. Then we can easily add another op
on the future while keeping compatibility with older
plugins.
On 05/03/2011 05:26 PM, Yordan Kamenov wrote:
A libv4l2 plugin will sit in between libv4l2 itself and the actual
/dev/video device node a fd refers to. It will be called each time
libv4l2 wants to do an operation (read/write/ioctl) on the actual
/dev/video node in question.
Signed-off-by: Yordan Kamenovykame...@mm-sol.com
---
lib/include/libv4l2-plugin.h | 36 ++
lib/include/libv4lconvert.h|5 +-
lib/libv4l2/Makefile |6 +-
lib/libv4l2/libv4l2-priv.h | 10 ++
lib/libv4l2/libv4l2.c | 88 ++
lib/libv4l2/v4l2-plugin.c | 158
lib/libv4l2/v4l2convert.c |9 --
lib/libv4lconvert/control/libv4lcontrol-priv.h |4 +
lib/libv4lconvert/control/libv4lcontrol.c | 35 --
lib/libv4lconvert/control/libv4lcontrol.h |5 +-
lib/libv4lconvert/libv4lconvert-priv.h |2 +
lib/libv4lconvert/libv4lconvert.c | 34 --
utils/qv4l2/qv4l2.cpp | 17 +++-
utils/qv4l2/qv4l2.h|1 +
14 files changed, 347 insertions(+), 63 deletions(-)
create mode 100644 lib/include/libv4l2-plugin.h
create mode 100644 lib/libv4l2/v4l2-plugin.c
diff --git a/lib/include/libv4l2-plugin.h b/lib/include/libv4l2-plugin.h
new file mode 100644
index 000..158c0c2
--- /dev/null
+++ b/lib/include/libv4l2-plugin.h
@@ -0,0 +1,36 @@
+/*
+* Copyright (C) 2010 Nokia Corporationmultime...@maemo.org
+
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU Lesser General Public License as published by
+* the Free Software Foundation; either version 2.1 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
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser 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
+*/
+
+#ifndef __LIBV4L2_PLUGIN_H
+#define __LIBV4L2_PLUGIN_H
+
+#includesys/types.h
+
+/* Structure libv4l2_dev_ops holds the calls from libv4ls to video nodes.
+ They can be normal open/close/ioctl etc. or any of them may be replaced
+ with a callback by a loaded plugin.
+*/
+
+struct libv4l2_dev_ops {
+void * (*init)(int fd);
+void (*close)(void *dev_ops_priv);
+int (*ioctl)(void *dev_ops_priv, int fd, unsigned long int request, void
*arg);
+ssize_t (*read)(void *dev_ops_priv, int fd, void *buffer, size_t n);
+};
+
+#endif
diff --git a/lib/include/libv4lconvert.h b/lib/include/libv4lconvert.h
index 0264290..351142e 100644
--- a/lib/include/libv4lconvert.h
+++ b/lib/include/libv4lconvert.h
@@ -38,6 +38,8 @@
#includelinux/videodev2.h
+#include libv4l2-plugin.h
+
#ifdef __cplusplus
extern C {
#endif /* __cplusplus */
@@ -50,7 +52,8 @@ extern C {
struct v4lconvert_data;
-LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd);
+LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd,
+ void *dev_ops_priv, struct libv4l2_dev_ops *dev_ops);
LIBV4L_PUBLIC void v4lconvert_destroy(struct v4lconvert_data *data);
/* When doing flipping / rotating / video-processing, only supported
diff --git a/lib/libv4l2/Makefile b/lib/libv4l2/Makefile
index d78632f..f8b3714 100644
--- a/lib/libv4l2/Makefile
+++ b/lib/libv4l2/Makefile
@@ -1,12 +1,12 @@
override CPPFLAGS += -I../include -fvisibility=hidden
-LIBS_libv4l2 = -lpthread
+LIBS_libv4l2 = -lpthread -ldl
-V4L2_OBJS = libv4l2.o log.o
+V4L2_OBJS = libv4l2.o v4l2-plugin.o log.o
V4L2CONVERT = v4l2convert.so
V4L2CONVERT_O = v4l2convert.o libv4l2.so
TARGETS = $(V4L2_LIB) libv4l2.pc
-INCLUDES = ../include/libv4l2.h
+INCLUDES = ../include/libv4l2.h
Re: [PATCH 1/2] libv4l2: add implicit conversion from single- to multi-plane api
Hi, On 07/06/2011 11:24 AM, Tomasz Stanislawski wrote: This patch add implicit conversion of single plane variant of ioctl to multiplane variant. The conversion is performed only in case if a driver implements only mplane api. The conversion is done by substituting SYS_IOCTL with a wrapper that converts single plane call to their mplane analogs. Function v4l2_fd_open was revised to work correctly with the wrapper. Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Thanks for the patch, I like the general idea, but I'm not completely happy with the implementation. I think overloading SYS_ioctl is not such a great idea, since this won't work for calls made by libv4lconvert, unless we export it from libv4l2 and use it in libv4lconvert too, which is quite ugly from an ABI pov. This is also problematic in the light of the upcoming plugin support (which just landed in v4l-utils git). Notice how that has replaced SYS_ioctl with dev_ops-ioctl, so that plugins can intercept ioctls. Actually the plugni support should make doing this more easy wrt libv4lconvert, since libv4lconvert now uses dev_ops-ioctl too. I think this can and should be handled in the following way, with a 2 patch patch-set: Patch1: Make the dev_ops member of v4l2_dev_info a struct rather then a pointer to a struct (and adjust v4l_plugin_init accordingly). Patch2: If one of the devices in question is detected the original dev_ops-ioctl should be saved in v4l2_dev_info and be replaced with the proposed wrapper, which then calls the saved original in cases where it now calls SYS_ioctl. Regards, Hans -- 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: mt9v032: Fix Bayer pattern
On Monday 18 July 2011 00:14:21 Guennadi Liakhovetski wrote: On Sun, 17 Jul 2011, Laurent Pinchart wrote: Hi Guennadi, On Saturday 16 July 2011 23:40:23 Guennadi Liakhovetski wrote: On Sat, 16 Jul 2011, Laurent Pinchart wrote: On Saturday 16 July 2011 01:11:28 Guennadi Liakhovetski wrote: On Fri, 15 Jul 2011, Laurent Pinchart wrote: Compute crop rectangle boundaries to ensure a GRBG Bayer pattern. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/mt9v032.c | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) If there's no comment I'll send a pull request for this patch in a couple of days. Hm, I might have a comment: why?... Isn't it natural to accept the fact, that different sensors put a different Bayer pixel at their sensor matrix origin? Isn't that why we have all possible Bayer formats? Maybe you just have to choose a different output format? That's the other solution. The driver currently claims the device outputs SGRBG, but configures it to output SGBGR. This is clearly a bug. Is it better to modify the format than the crop rectangle location ? Actually, it is interesting. I just looked (again) in the mt9v032 and some other Aptina Bayer sensor datasheets, and they actually have _odd_ numbers of rows and columns. So, mt9v032 actually has 753x481 active pixels. And that extra pixel is explicitly provided to adjust the origin colour. Ok, they write, it is for uniformity with the mirrored image, but who believes them?;-) So, maybe you should adjust your max values to the above ones, then taking one pixel out of your image will not reduce your useful image size. I'm not sure what you mean. Even though the pixel array is bigger than that, the maximum output width/height are 752x480 according to the datasheet. Have a look at the Pixel array structure (p.10 in my version) section. I've seen that, but the sensor is still unable to output an image bigger than 752x480. See registers 3 and 4 maximum values on page 24 (in my version :-)). -- Regards, Laurent Pinchart -- 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: mt9v032: Fix Bayer pattern
On Mon, 18 Jul 2011, Laurent Pinchart wrote: On Monday 18 July 2011 00:14:21 Guennadi Liakhovetski wrote: On Sun, 17 Jul 2011, Laurent Pinchart wrote: Hi Guennadi, On Saturday 16 July 2011 23:40:23 Guennadi Liakhovetski wrote: On Sat, 16 Jul 2011, Laurent Pinchart wrote: On Saturday 16 July 2011 01:11:28 Guennadi Liakhovetski wrote: On Fri, 15 Jul 2011, Laurent Pinchart wrote: Compute crop rectangle boundaries to ensure a GRBG Bayer pattern. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/mt9v032.c | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) If there's no comment I'll send a pull request for this patch in a couple of days. Hm, I might have a comment: why?... Isn't it natural to accept the fact, that different sensors put a different Bayer pixel at their sensor matrix origin? Isn't that why we have all possible Bayer formats? Maybe you just have to choose a different output format? That's the other solution. The driver currently claims the device outputs SGRBG, but configures it to output SGBGR. This is clearly a bug. Is it better to modify the format than the crop rectangle location ? Actually, it is interesting. I just looked (again) in the mt9v032 and some other Aptina Bayer sensor datasheets, and they actually have _odd_ numbers of rows and columns. So, mt9v032 actually has 753x481 active pixels. And that extra pixel is explicitly provided to adjust the origin colour. Ok, they write, it is for uniformity with the mirrored image, but who believes them?;-) So, maybe you should adjust your max values to the above ones, then taking one pixel out of your image will not reduce your useful image size. I'm not sure what you mean. Even though the pixel array is bigger than that, the maximum output width/height are 752x480 according to the datasheet. Have a look at the Pixel array structure (p.10 in my version) section. I've seen that, but the sensor is still unable to output an image bigger than 752x480. See registers 3 and 4 maximum values on page 24 (in my version :-)). Right, sorry, what I mean, is, that even when you use one pixel to adjust your image origin, you don't actually lose the size. So, you can output 752 pixels in a row whether you begin at 0 or 1. That's why I suggested to set max width to 753, but then make sure it's always actually even. That way a configuration offset = 1, width = 752 will also be valid. 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
