SV: /dev/dvb/adapter0/dvr0 gives no output
Ok, sorry, RTFM I guess. //Anders -Ursprungligt meddelande- Från: David Santinoli [mailto:marau...@tiscali.it] Skickat: den 5 juni 2009 19:10 Till: Sandell, Anders Kopia: linux-media@vger.kernel.org Ämne: Re: /dev/dvb/adapter0/dvr0 gives no output On Fri, Jun 05, 2009 at 06:06:42PM +0200, Sandell, Anders wrote: Everything looks just fine but when trying cat /dev/dvb/adapter0/dvr0 file.mpg nothing happens, the file never get any contents. Szap-s2 also seems to be working locking on to BBC World: Don't know much about szap-s2, but if it works like szap, you might have to add '-r' in the command line to enable the dvr0 device. HTH, David -- 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: [PATCHv5 1 of 8] v4l2_subdev i2c: Add v4l2_i2c_new_subdev_board i2c helper function
Hi guys, On Mon, Jun 08, 2009 at 05:19:22AM +0200, ext Douglas Schilling Landgraf wrote: Hi, On Sun, 7 Jun 2009 22:29:14 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: Em Sun, 7 Jun 2009 08:40:08 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Saturday 06 June 2009 22:40:21 Eduardo Valentin wrote: Hi Hans, On Sat, Jun 6, 2009 at 8:09 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 06 June 2009 14:49:46 Hans Verkuil wrote: On Saturday 06 June 2009 13:59:19 Hans Verkuil wrote: snip No please. We did already lots of change due to the i2c changes, and there are still some occasional complaints at ML about regressions that might be due to i2c changes. Let's keep 2.6.31 clean, as previously agreed, without new KABI changes. We should focus 2.6.31 on fixing any core issues that may still have. Only with 2.6.30 we'll start to have feedbacks from normal users. snip I've cloned your tree and took a look at your code. Well, looks like the proper way to do this change. I didn't take this approach because it touchs other drivers. However, concentrating the code in only one function is better. I also saw that you have fixed the kernel version check in the v4l2_device_unregister function. Great! I will resend my series without this patch. I will rebase it on top of your subdev tree so the new api can be used straight. Is that ok? Yes, sure. Just be aware that there may be some small changes to my patch based on feedback I get. But it is a good test anyway of this API to see if it works well for you. Eduardo, Let's analyze and merge your changes using the current development tree. If you think that Hans approach is better (I haven't analyzed it yet), then it can later be converted to the new approach I have talked with Eduardo during last week and if there is no objections, I am ready to request a pull from the current/last patches series. Yes, my series is already in one of Douglas' trees and we have tested it. However, in that series there is one patch which does partially what Hans is proposing. Which is: add a way to pass platform info to i2c drivers, using v4l2 i2c helper functions. They way it is done in this patch it does not affect any other driver. Hans did also some re-factoring in existing i2c helper function, besides adding new way to pass platform data. If you agree we can use it for now and in next window we change things to have them using the way Hans did (which is more complete). What do you think? Cheers, Douglas Cheers, -- Eduardo Valentin -- 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: [PATCHv5 1 of 8] v4l2_subdev i2c: Add v4l2_i2c_new_subdev_board i2c helper function
On Monday 08 June 2009 03:29:14 Mauro Carvalho Chehab wrote:
Em Sun, 7 Jun 2009 08:40:08 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On Saturday 06 June 2009 22:40:21 Eduardo Valentin wrote:
Hi Hans,
On Sat, Jun 6, 2009 at 8:09 PM, Hans Verkuil hverk...@xs4all.nl
wrote:
On Saturday 06 June 2009 14:49:46 Hans Verkuil wrote:
On Saturday 06 June 2009 13:59:19 Hans Verkuil wrote:
On Friday 29 May 2009 09:33:21 Eduardo Valentin wrote:
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 1243414605 -10800
# Branch export
# Node ID 4fb354645426f8b187c2c90cd8528b2518461005
# Parent 142fd6020df3b4d543068155e49a2618140efa49
Device drivers of v4l2_subdev devices may want to have
board specific data. This patch adds an helper function
to allow bridge drivers to pass board specific data to
v4l2_subdev drivers.
For those drivers which need to support kernel versions
bellow 2.6.26, a .s_config callback was added. The
idea of this callback is to pass board configuration
as well. In that case, subdev driver should set .s_config
properly, because v4l2_i2c_new_subdev_board will call
the .s_config directly. Of course, if we are = 2.6.26,
the same data will be passed through i2c board info as well.
Hi Eduardo,
I finally had some time to look at this. After some thought I
realized that the main problem is really that the API is
becoming quite messy. Basically there are 9 different ways of
loading and initializing a subdev:
First there are three basic initialization calls: no
initialization, passing irq and platform_data, and passing the
i2c_board_info struct directly (preferred for drivers that
don't need pre-2.6.26 compatibility).
And for each flavor you would like to see three different
versions as well: one with a fixed known i2c address, one where
you probe for a list of addresses, and one where you can probe
for a single i2c address.
I propose to change the API as follows:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END
})
struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device
*v4l2_dev, struct i2c_adapter *adapter,
const char *module_name, const char
*client_type, u8 addr, const unsigned short *addrs);
struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct v4l2_device
*v4l2_dev, struct i2c_adapter *adapter,
const char *module_name, const char
*client_type, int irq, void *platform_data,
u8 addr, const unsigned short *addrs);
/* Only available for kernels = 2.6.26 */
struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct
v4l2_device *v4l2_dev, struct i2c_adapter *adapter, const char
*module_name, struct i2c_board_info *info, const unsigned short
*addrs);
If you use a fixed address, then only set addr (or info.addr)
and set addrs to NULL. If you want to probe for a list of
addrs, then set addrs to the list of addrs. If you want to
probe for a single addr, then use V4L2_I2C_ADDRS(addr) as the
addrs argument. This constructs an array with just two entries.
Actually, this macro can also create arrays with more entries.
Note that v4l2_i2c_new_subdev will be an inline that calls
v4l2_i2c_new_subdev_cfg with 0, NULL for the irq and
platform_data.
And for kernels = 2.6.26 v4l2_i2c_new_subdev_cfg can be an
inline calling v4l2_i2c_new_subdev_board.
This approach reduces the number of functions to just one (not
counting the inlines) and simplifies things all around. It does
mean that all sources need to be changed, but if we go this
route, then now is the time before the 2.6.31 window is closed.
And I would also like to remove the '_new' from these function
names. I never thought it added anything useful.
Comments? If we decide to go this way, then I need to know soon
so that I can make the changes before the 2.6.31 window closes.
BTW, if the new s_config subdev call is present, then it should
always be called. That way the subdev driver can safely do all
of its initialization in s_config, no matter how it was
initialized.
Sorry about the long delay in replying to this: it's been very
hectic lately at the expense of my v4l-dvb work.
I've done the initial conversion to the new API (no _cfg or
_board version yet) in my ~hverkuil/v4l-dvb-subdev tree. It
really simplifies things and if nobody objects then I'd like to
get this in before 2.6.31.
No please. We did already lots of change due to the i2c
Re: [PATCH] bt8xx: Add support for the Conexant Fusion 878a / Twinhan VP 1025 DVB-S
Hi Trent, * [08.06.09 02:24]: You can remove Conexant Fusion from the board name. All the boards for that driver use that same chip. Just use Twinhan VP 1025 DVB-S. Alright, thanks for clearing that up. Don't you need to add it to the list in bttv-cards.c in order to use the card? Not sure about that, it wasn’t necessary for me. Best regards, Michael signature.asc Description: Digital signature
Re: [PATCHv5 1 of 8] v4l2_subdev i2c: Add v4l2_i2c_new_subdev_board i2c helper function
On Monday 08 June 2009 08:11:32 Eduardo Valentin wrote: Hi guys, On Mon, Jun 08, 2009 at 05:19:22AM +0200, ext Douglas Schilling Landgraf wrote: Hi, On Sun, 7 Jun 2009 22:29:14 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: Em Sun, 7 Jun 2009 08:40:08 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Saturday 06 June 2009 22:40:21 Eduardo Valentin wrote: Hi Hans, On Sat, Jun 6, 2009 at 8:09 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 06 June 2009 14:49:46 Hans Verkuil wrote: On Saturday 06 June 2009 13:59:19 Hans Verkuil wrote: snip No please. We did already lots of change due to the i2c changes, and there are still some occasional complaints at ML about regressions that might be due to i2c changes. Let's keep 2.6.31 clean, as previously agreed, without new KABI changes. We should focus 2.6.31 on fixing any core issues that may still have. Only with 2.6.30 we'll start to have feedbacks from normal users. snip I've cloned your tree and took a look at your code. Well, looks like the proper way to do this change. I didn't take this approach because it touchs other drivers. However, concentrating the code in only one function is better. I also saw that you have fixed the kernel version check in the v4l2_device_unregister function. Great! I will resend my series without this patch. I will rebase it on top of your subdev tree so the new api can be used straight. Is that ok? Yes, sure. Just be aware that there may be some small changes to my patch based on feedback I get. But it is a good test anyway of this API to see if it works well for you. Eduardo, Let's analyze and merge your changes using the current development tree. If you think that Hans approach is better (I haven't analyzed it yet), then it can later be converted to the new approach I have talked with Eduardo during last week and if there is no objections, I am ready to request a pull from the current/last patches series. Yes, my series is already in one of Douglas' trees and we have tested it. However, in that series there is one patch which does partially what Hans is proposing. Which is: add a way to pass platform info to i2c drivers, using v4l2 i2c helper functions. They way it is done in this patch it does not affect any other driver. Hans did also some re-factoring in existing i2c helper function, besides adding new way to pass platform data. No, I don't agree with that. Your patch has some issues: no cleanup after s_config returns an error, and if we introduce s_config then it should be called by *all* v4l2_new_subdev* functions. That way i2c drivers that implement this can use it reliably for their initialization. I see no point in doing the same work twice. We have one clean solution into which I put quite a bit of time, and one that hacks new functionality into an already flawed API. This was also the reason why I didn't just sign off on Eduardo's patch. I strongly suspected I needed to do some proper refactoring first and when I finally had the time to look into this last Saturday I discovered it did indeed needed refactoring. If you agree we can use it for now and in next window we change things to have them using the way Hans did (which is more complete). Going with a suboptimal solution when a proper clean one is available is a really bad idea IMHO. Regards, Hans What do you think? Cheers, Douglas Cheers, -- 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: About the VIDIOC_DQBUF
Hello Xie,
I'm not sure which camera interface driver you are using, but it seems
to be camera interface driver's problem. Let me guess, are you using
pxa camera interface driver from Marvell?(proprietary but not in up
stream kernel)
It just looks like that camera interface driver is not returning
proper data in dqbuf.
And one more thing. I prefer to use byteused rather than length in
buf. because as far as I know the size of preview data from camera is
in byte unit which we need to copy to memory. But it should be
possible to use length, I guess..
Cheers,
Nate
On Mon, Jun 8, 2009 at 11:05 AM, xieyili@gmail.com wrote:
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(fds) ;
FD_SET(v4l2Fd, fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, fds, NULL, NULL, tv) ;
LOGD(The value of select return : %d\n, rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE(READ ERROR) ;
}
***/
if(-1 == rt){
LOGE(there is something wrong in select
function(select)) ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE(wait for data timeout in select) ;
return V4L2_TIMEOUT ;
}
memset(buf, 0, sizeof(buf)) ;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
buf.memory = V4L2_MEMORY_MMAP ;
if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, buf)){
LOGE(there is something wrong in dequeue
buffer(VIDIOC_DQBUF)) ;
return V4L2_IOCTL_ERROR ;
}
assert(i n_buf) ;
LOGE(buf.index 0buf.length = %d %d \n, buf.index ,
buf.length) ;
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.length) ;
if(-1 == ioctl(v4l2Fd, VIDIOC_QBUF, buf)){
LOGE(there is something wrong in enqueue
buffer(VIDIOC_QBUF)) ;
return V4L2_IOCTL_ERROR ;
}
//break ; //i don't know whether the break is needed ;
}
return V4L2_NOERROR ;
}
when executed the VIDIOC_DQBUF IOCTL,the return value was right, but the
value of buf.length would always be zero. Then I used the read()
function to read raw data in the file handle for debug, and I can get
the raw data. Anybody have met this issue before ? Who can give me some
advices or tell me what is wrong , thanks a lot ~
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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: [PATCHv5 1 of 8] v4l2_subdev i2c: Add v4l2_i2c_new_subdev_board i2c helper function
On Mon, Jun 08, 2009 at 08:38:32AM +0200, ext Hans Verkuil wrote: On Monday 08 June 2009 08:11:32 Eduardo Valentin wrote: Hi guys, On Mon, Jun 08, 2009 at 05:19:22AM +0200, ext Douglas Schilling Landgraf wrote: Hi, On Sun, 7 Jun 2009 22:29:14 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: Em Sun, 7 Jun 2009 08:40:08 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Saturday 06 June 2009 22:40:21 Eduardo Valentin wrote: Hi Hans, On Sat, Jun 6, 2009 at 8:09 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 06 June 2009 14:49:46 Hans Verkuil wrote: On Saturday 06 June 2009 13:59:19 Hans Verkuil wrote: snip No please. We did already lots of change due to the i2c changes, and there are still some occasional complaints at ML about regressions that might be due to i2c changes. Let's keep 2.6.31 clean, as previously agreed, without new KABI changes. We should focus 2.6.31 on fixing any core issues that may still have. Only with 2.6.30 we'll start to have feedbacks from normal users. snip I've cloned your tree and took a look at your code. Well, looks like the proper way to do this change. I didn't take this approach because it touchs other drivers. However, concentrating the code in only one function is better. I also saw that you have fixed the kernel version check in the v4l2_device_unregister function. Great! I will resend my series without this patch. I will rebase it on top of your subdev tree so the new api can be used straight. Is that ok? Yes, sure. Just be aware that there may be some small changes to my patch based on feedback I get. But it is a good test anyway of this API to see if it works well for you. Eduardo, Let's analyze and merge your changes using the current development tree. If you think that Hans approach is better (I haven't analyzed it yet), then it can later be converted to the new approach I have talked with Eduardo during last week and if there is no objections, I am ready to request a pull from the current/last patches series. Yes, my series is already in one of Douglas' trees and we have tested it. However, in that series there is one patch which does partially what Hans is proposing. Which is: add a way to pass platform info to i2c drivers, using v4l2 i2c helper functions. They way it is done in this patch it does not affect any other driver. Hans did also some re-factoring in existing i2c helper function, besides adding new way to pass platform data. No, I don't agree with that. Your patch has some issues: no cleanup after s_config returns an error, and if we introduce s_config then it should be called by *all* v4l2_new_subdev* functions. That way i2c drivers that implement this can use it reliably for their initialization. I see no point in doing the same work twice. We have one clean solution into which I put quite a bit of time, and one that hacks new functionality into an already flawed API. Agreed. No point in doing the same work. This was also the reason why I didn't just sign off on Eduardo's patch. I strongly suspected I needed to do some proper refactoring first and when I finally had the time to look into this last Saturday I discovered it did indeed needed refactoring. If you agree we can use it for now and in next window we change things to have them using the way Hans did (which is more complete). Going with a suboptimal solution when a proper clean one is available is a really bad idea IMHO. As I already said, I really liked your approach because it re-factors the API. No problem for me to rebase the patches on top of that. Regards, Hans What do you think? Cheers, Douglas Cheers, -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- Eduardo Valentin -- 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
testing contribute
I am really interested into contributing into testing a new module for this hewlett packard webcam... Bus 002 Device 010: ID 03f0:1b07 Hewlett-Packard I have uname -a Linux TOOLBOX 2.6.30-rc8 #1 SMP Mon Jun 8 00:08:59 CEST 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux I really would like to know which datas are needed to you to know how to make it... I can even send the windows drivers if required... please let me know soon -- 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: About the VIDIOC_DQBUF
Hi Dongsoo, Nathaniel ~
You must be expert on V4l2 ~ Thanks very much for your help and advice
~!~
I used the MXC camera interface driver from Fressscale ,I readed the
driver interface just now ,and have fouded that the driver not modified
the buf.lenth but buf.byteused . You are very right , I will use the
buf.byteused instead of buf.length ~
There is also a problem I want to consult to you ~ Can i get a full
frame with the below method if the driver have no problem ?
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.byteused) ;
Because I just need to implement a hal for getting the frame data and
post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
what about your advice ?
Thanks a lot ~~
在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
Hello Xie,
I'm not sure which camera interface driver you are using, but it seems
to be camera interface driver's problem. Let me guess, are you using
pxa camera interface driver from Marvell?(proprietary but not in up
stream kernel)
It just looks like that camera interface driver is not returning
proper data in dqbuf.
And one more thing. I prefer to use byteused rather than length in
buf. because as far as I know the size of preview data from camera is
in byte unit which we need to copy to memory. But it should be
possible to use length, I guess..
Cheers,
Nate
On Mon, Jun 8, 2009 at 11:05 AM, xieyili@gmail.com wrote:
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(fds) ;
FD_SET(v4l2Fd, fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, fds, NULL, NULL, tv) ;
LOGD(The value of select return : %d\n, rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE(READ ERROR) ;
}
***/
if(-1 == rt){
LOGE(there is something wrong in select
function(select)) ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE(wait for data timeout in select) ;
return V4L2_TIMEOUT ;
}
memset(buf, 0, sizeof(buf)) ;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
buf.memory = V4L2_MEMORY_MMAP ;
if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, buf)){
LOGE(there is something wrong in dequeue
buffer(VIDIOC_DQBUF)) ;
return V4L2_IOCTL_ERROR ;
}
assert(i n_buf) ;
LOGE(buf.index 0buf.length = %d %d \n, buf.index ,
buf.length) ;
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.length) ;
if(-1 == ioctl(v4l2Fd, VIDIOC_QBUF, buf)){
LOGE(there is something wrong in enqueue
buffer(VIDIOC_QBUF)) ;
return V4L2_IOCTL_ERROR ;
}
//break ; //i don't know whether the break is needed ;
}
return V4L2_NOERROR ;
}
when executed the VIDIOC_DQBUF IOCTL,the return value was right, but the
value of buf.length would always be zero. Then I used the read()
function to read raw data in the file handle for debug, and I can get
the raw data. Anybody have met this issue before ? Who can give me some
advices or tell me what is wrong , thanks a lot ~
--
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
[PATCHv6 0 of 7] FM Transmitter (si4713) and another changes
Hello all, I'm resending the FM transmitter driver and the proposed changes in v4l2 api files in order to cover the fmtx extended controls class. Difference from version #5 is that now I've dropped the patch which adds a new i2c helper function. And now this series is based on Hans tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev. That tree has the proper refactoring of v4l2 i2c helper functions. The work done before in the patch dropped here, now was done by Hans. So, now the series includes only changes to add the new v4l2 FMTX extended controls (and its documetation) and si4713 i2c and platform drivers (and its documentation as well). Again, comments are welcome. BR, --- Eduardo Valentin -- 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
[PATCHv6 1 of 7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
From: Eduardo Valentin eduardo.valen...@nokia.com
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 1243414606 -10800
# Node ID 44d477eb96bd219a16b7430937a9b14ae1f9d607
# Parent c8e571f41aa55740bee6095aa1526f5aadce3ec9
This patch adds a new class of extended controls. This class
is intended to support Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and region related properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
include/linux/videodev2.h | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff -r c8e571f41aa5 -r 44d477eb96bd linux/include/linux/videodev2.h
--- a/linux/include/linux/videodev2.h Sat Jun 06 19:05:35 2009 +0200
+++ b/linux/include/linux/videodev2.h Wed May 27 11:56:46 2009 +0300
@@ -803,6 +803,7 @@
#define V4L2_CTRL_CLASS_USER 0x0098/* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
+#define V4L2_CTRL_CLASS_FMTX 0x009b/* FM Radio Modulator class
controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1141,6 +1142,39 @@
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Radio Modulator class control IDs */
+#define V4L2_CID_FMTX_CLASS_BASE (V4L2_CTRL_CLASS_FMTX | 0x900)
+#define V4L2_CID_FMTX_CLASS(V4L2_CTRL_CLASS_FMTX | 1)
+
+#define V4L2_CID_RDS_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FMTX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FMTX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME (V4L2_CID_FMTX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FMTX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME(V4L2_CID_FMTX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FMTX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FMTX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FMTX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME (V4L2_CID_FMTX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED(V4L2_CID_FMTX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION (V4L2_CID_FMTX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY (V4L2_CID_FMTX_CLASS_BASE + 16)
+
+#define V4L2_CID_PREEMPHASIS (V4L2_CID_FMTX_CLASS_BASE + 17)
+enum v4l2_fmtx_preemphasis {
+ V4L2_FMTX_PREEMPHASIS_DISABLED = 0,
+ V4L2_FMTX_PREEMPHASIS_50_uS = 1,
+ V4L2_FMTX_PREEMPHASIS_75_uS = 2,
+};
+#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FMTX_CLASS_BASE + 18)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FMTX_CLASS_BASE + 19)
+
/*
* T U N I N G
*/
--
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
[PATCHv6 7 of 7] FMTx: si4713: Add document file
From: Eduardo Valentin eduardo.valen...@nokia.com # HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1243414607 -10800 # Node ID 2456c8fc506ecf928d2e95da36d611d094c0ec55 # Parent fbdd1a2a4fd099a98b1a48f3853a78c0a544632d Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- Documentation/video4linux/si4713.txt | 133 ++ 1 files changed, 133 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/si4713.txt diff -r fbdd1a2a4fd0 -r 2456c8fc506e linux/Documentation/video4linux/si4713.txt --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux/Documentation/video4linux/si4713.txtWed May 27 11:56:47 2009 +0300 @@ -0,0 +1,133 @@ +Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters + +Copyright (c) 2009 Nokia Corporation +Contact: Eduardo Valentin eduardo.valen...@nokia.com + + +Information about the Device + +This chip is a Silicon Labs product. It is a I2C device, currently on 0Ã63 address. +Basically, it has transmission and signal noise level measurement features. + +The Si4713 integrates transmit functions for FM broadcast stereo transmission. +The chip also allows integrated receive power scanning to identify low signal +power FM channels. + +The chip is programmed using commands and responses. There are also several +properties which can change the behavior of this chip. + +Users must comply with local regulations on radio frequency (RF) transmission. + +Device driver description += +There are two modules to handle this device. One is a I2C device driver +and the other is a platform driver. + +The I2C device driver exports a v4l2-subdev interface to the kernel. Also +it exports several device properties through sysfs interface to the user land. +All properties can also be accessed by v4l2 extended controls interface, by +using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls). + +The platform device driver exports a v4l2 radio device interface to user land. +So, it uses the I2C device driver as a sub device in order to send the user +commands to the actual device. Basically it is a wrapper to the I2C device driver. + +So, in summary, the device driver has two interfaces to the user space. + +Applications can use v4l2 radio API to specify frequency of operation, mute state, +etc. But mostly of its properties will be present in the extended controls. +However, the device properties can also be accessed through its sysfs directory. + +When the v4l2 mute property is set to 1 (true), the driver will turn the chip off. + +Properties description +== + +The properties can be accessed in sysfs device directory. Using v4l2 extended +controls as well. + +# ls +acomp_attack_timemodalias rds_radio_text +acomp_enabledname region +acomp_gain pilot_deviation region_bottom_frequency +acomp_release_time pilot_enabledregion_channel_spacing +acomp_threshold pilot_frequency region_preemphasis +antenna_capacitorpowerregion_top_frequency +bus power_level stereo_enabled +driver rds_enabled subsystem +limiter_deviationrds_pi tune_measure +limiter_enabled rds_ps_name uevent +limiter_release_time rds_pty + +Here is a summary of them: + +* Pilot is an audible tone sent by the device. + +pilot_frequency - Configures the frequency of the stereo pilot tone. +pilot_deviation - Configures pilot tone frequency deviation level. +pilot_enabled - Enables or disables the pilot tone feature. + +* The si4713 device is capable of applying audio compression to the transmitted signal. + +acomp_enabled - Enables or disables the audio dynamic range control feature. +acomp_gain - Sets the gain for audio dynamic range control. +acomp_threshold - Sets the threshold level for audio dynamic range control. +acomp_attack_time - Sets the attack time for audio dynamic range control. +acomp_release_time - Sets the release time for audio dynamic range control. + +* Limiter setups audio deviation limiter feature. Once a over deviation occurs, +it is possible to adjust the front-end gain of the audio input and always +prevent over deviation. + +limiter_enabled - Enables or disables the limiter feature. +limiter_deviation - Configures audio frequency deviation level. +limiter_release_time - Sets the limiter release time. + +* Tuning power + +power_level - Sets the output power level for signal transmission. +antenna_capacitor - This selects the value of antenna tuning capacitor manually +or automatically if set to zero. +tune_measure - With this you can get the value of signal length of a specific frequency. + +* RDS related + +rds_enabled - Enables or disables the RDS feature. +rds_ps_name - Sets the RDS ps
[PATCHv6 3 of 7] Add documentation description for FM Transmitter Extended Control Class
From: Eduardo Valentin eduardo.valen...@nokia.com # HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1242209424 -10800 # Node ID ccae4c3150d272235cc2b19af8e9adb2e8b2e5f5 # Parent 6220548f4843ce4d19868dfcf5316d6b58a77824 This single patch adds documentation description for FM Transmitter (FMTX) Extended Control Class and its Control IDs. The text was added under Extended Controls section. Priority: normal Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com diff -r 6220548f4843 -r ccae4c3150d2 v4l2-spec/controls.sgml --- a/v4l2-spec/controls.sgml Wed May 27 11:56:46 2009 +0300 +++ b/v4l2-spec/controls.sgml Wed May 13 13:10:24 2009 +0300 @@ -458,6 +458,12 @@ paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,200 @@ /tgroup /table /section + +section id=fmtx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FMTX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fmtx-control-id + titleFMTX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FMTX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FMTX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PI/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Type field for transmission. +This coding of up to 31 pre-defined programme types./entry + /row +!-- + row + entry spanname=idconstantV4L2_CID_RDS_PS_NAME/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descr./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RADIO_TEXT/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descr./entry + /row +-- + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the audio deviation limiter feature. +The limiter is useful when trying to maximize the audio volume, minimize receiver-generated +distortion and prevent overmodulation. +/entry + /row + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_RELEASE_TIME/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the audio deviation limiter feature release time. +The unit, step and range are driver-specific./entry + /row + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_DEVIATION/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrConfigures audio frequency deviation level in Hz. +The range and step are driver-specific./entry + /row + row + entry spanname=idconstantV4L2_CID_AUDIO_COMPRESSION_ENABLED/constantnbsp;/entry + entryboolean/entry + /row +
[PATCHv6 6 of 7] FMTx: si4713: Add Kconfig and Makefile entries
From: Eduardo Valentin eduardo.valen...@nokia.com # HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1243414607 -10800 # Node ID fbdd1a2a4fd099a98b1a48f3853a78c0a544632d # Parent 786afca68fc9fd35b18ee5cb4166b491613b13a5 Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- drivers/media/radio/Kconfig | 22 ++ drivers/media/radio/Makefile |3 +++ 2 files changed, 25 insertions(+), 0 deletions(-) diff -r 786afca68fc9 -r fbdd1a2a4fd0 linux/drivers/media/radio/Kconfig --- a/linux/drivers/media/radio/Kconfig Wed May 27 11:56:46 2009 +0300 +++ b/linux/drivers/media/radio/Kconfig Wed May 27 11:56:47 2009 +0300 @@ -339,6 +339,28 @@ help Enter the I/O port of your Zoltrix radio card. +config I2C_SI4713 + tristate I2C driver for Silicon Labs Si4713 device + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 I2C device. + This device driver supports only i2c bus. + + To compile this driver as a module, choose M here: the + module will be called si4713. + +config RADIO_SI4713 + tristate Silicon Labs Si4713 FM Radio Transmitter support + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 FM Radio Transmitter. + This device can transmit audio through FM. It can transmit + EDS and EBDS signals as well. This module is the v4l2 radio + interface for the i2c driver of this device. + + To compile this driver as a module, choose M here: the + module will be called radio-si4713. + config USB_DSBR tristate D-Link/GemTek USB FM radio support depends on USB VIDEO_V4L2 diff -r 786afca68fc9 -r fbdd1a2a4fd0 linux/drivers/media/radio/Makefile --- a/linux/drivers/media/radio/MakefileWed May 27 11:56:46 2009 +0300 +++ b/linux/drivers/media/radio/MakefileWed May 27 11:56:47 2009 +0300 @@ -15,6 +15,9 @@ obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o obj-$(CONFIG_RADIO_GEMTEK_PCI) += radio-gemtek-pci.o obj-$(CONFIG_RADIO_TRUST) += radio-trust.o +obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o +si4713-i2c-objs := si4713.o si4713-subdev.o +obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_USB_SI470X) += radio-si470x.o -- 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: [PATCHv6 0 of 7] FM Transmitter (si4713) and another changes
Hello all, I'm resending the FM transmitter driver and the proposed changes in v4l2 api files in order to cover the fmtx extended controls class. Difference from version #5 is that now I've dropped the patch which adds a new i2c helper function. And now this series is based on Hans tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev. That tree has the proper refactoring of v4l2 i2c helper functions. The work done before in the patch dropped here, now was done by Hans. So, now the series includes only changes to add the new v4l2 FMTX extended controls (and its documetation) and si4713 i2c and platform drivers (and its documentation as well). Pending unforeseen circumstances I will do a full review tomorrow. Regards, Hans Again, comments are welcome. BR, --- Eduardo Valentin -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
cx18, s5h1409: chronic bit errors, only under Linux
I have a Hauppauge WinTV-HVR-1600 that I am using to capture ATSC and clear QAM programming from cable television (Comcast of Chattanooga). This card uses the cx18 and s5h1409 kernel modules. There are frequent bursts of bit errors occurring every few seconds in the incoming transport stream, when I have the card tuned under Linux. This causes artifacts in the received video as well as skipping in the received audio, to the point that it is practically unwatchable. However, under Windows on the same system/capture card, I can tune to the same programs with nearly perfect reception (no bit errors). Also these programs appear on my TV with great quality as well. The problem is happening on all of several different frequencies/programs that I have tried, although it is more pronounced on some programs (particularly ATSC) than others. I have tried the latest v4l-dvb development sources under both kernel 2.6.24 and kernel 2.6.29, and additionally I have tried to use the unmodified v4l-dvb from kernel 2.6.29. Additionally, I have tried both the recommended cx23418 firmware from linuxtv.org, as well as the newer firmware provided by latest the Hauppauge drivers for Windows (which I am using successfully under Windows). Unfortunately they all produce the same results. I primarily use MythTV to capture the programs to a file, and the resulting file exhibits these problems. However, I can also see the bit errors when I simply use the 'azap' application to tune the card directly (and also read the dvr0 device into a file). The BER and UNC values reported by 'azap' are non-zero approximately one out of every five samples; then they are usually around 0x200, though this varies. The BER and UNC values are almost always identical, i.e., no error correction is taking place, only error detection. Additionally I am not seeing any TS continuity or TEI flag errors, as detectable in the system log with the latest changeset. I have tried to rule out other possible causes such as a weak input signal (by hooking the capture card directly to the household cable television input, bypassing all coaxial splitters) and system-specific issues (by trying this on three different systems). However, to me it seems that the problem must be originating from an issue in the kernel modules for this card. I understand that having some errors in the transport stream is unavoidable, and I have tried postprocessing with an application such as Project-X. However, it does not magically take care of this -- the length of the video is reduced by about 20% and the resulting video jumps around constantly. Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. Thanks, David Ward -- 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: Probably strange bug with usb radio-mr800
Am Sonntag, 7. Juni 2009 15:41:13 schrieb Alexey Klimov: If not, the driver may not be 64bit clean. Which driver is affected? media/radio/radio-mr800.c I can see no obvious 64bit problem. Please, also take a look in my first letter to usb and v4l mail lists from May 27. Please resend that and put linux-...@vger.kernel.org into cc. Regards Oliver -- 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: Question about driver for Mantis
Gernot Pansy wrote: i think i was one of the first SP400 owner but i had to sold my card for a Nova HD2 because the driver was not reliable (some i2c errors, slow tunning, sometimes tunning failed). And now i need a dvb-s2 card with ci working. so i'm searching again for a new card. their seems to be only the tt-3200 out, which seems to work - no newer card. You could try the FloppyDTV S2. -- 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: About the VIDIOC_DQBUF
Hi,
Sorry I'm not an expert, you can expect expertise from maintainers not from me.
But before answering your question about capturing, I'm not sure about
what the full frame means. I just assume that you meant to say the
biggest resolution of image frame, right?
So, when you are to capture a full resolution data while preview is
working, you need to stop preview with streamoff, re-configure
resolution with s_fmt to external camera module and start capturing
issuing streamon with re-configured resolution. I think you are
well-aware with this, aren't you? And in my opinion, memcpy may be
cool for that. What else are you expecting to use? and for what?
Anyway, I wish you luck.
Cheers,
Nate
On Mon, Jun 8, 2009 at 5:02 PM, xieyili@gmail.com wrote:
Hi Dongsoo, Nathaniel ~
You must be expert on V4l2 ~ Thanks very much for your help and advice
~!~
I used the MXC camera interface driver from Fressscale ,I readed the
driver interface just now ,and have fouded that the driver not modified
the buf.lenth but buf.byteused . You are very right , I will use the
buf.byteused instead of buf.length ~
There is also a problem I want to consult to you ~ Can i get a full
frame with the below method if the driver have no problem ?
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.byteused) ;
Because I just need to implement a hal for getting the frame data and
post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
what about your advice ?
Thanks a lot ~~
在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
Hello Xie,
I'm not sure which camera interface driver you are using, but it seems
to be camera interface driver's problem. Let me guess, are you using
pxa camera interface driver from Marvell?(proprietary but not in up
stream kernel)
It just looks like that camera interface driver is not returning
proper data in dqbuf.
And one more thing. I prefer to use byteused rather than length in
buf. because as far as I know the size of preview data from camera is
in byte unit which we need to copy to memory. But it should be
possible to use length, I guess..
Cheers,
Nate
On Mon, Jun 8, 2009 at 11:05 AM, xieyili@gmail.com wrote:
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(fds) ;
FD_SET(v4l2Fd, fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, fds, NULL, NULL, tv) ;
LOGD(The value of select return : %d\n, rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE(READ ERROR) ;
}
***/
if(-1 == rt){
LOGE(there is something wrong in select
function(select)) ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE(wait for data timeout in select) ;
return V4L2_TIMEOUT ;
}
memset(buf, 0, sizeof(buf)) ;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
buf.memory = V4L2_MEMORY_MMAP ;
if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, buf)){
LOGE(there is something wrong in dequeue
buffer(VIDIOC_DQBUF)) ;
return V4L2_IOCTL_ERROR ;
}
assert(i n_buf) ;
LOGE(buf.index 0buf.length = %d %d \n, buf.index ,
buf.length) ;
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.length) ;
if(-1 == ioctl(v4l2Fd, VIDIOC_QBUF, buf)){
LOGE(there is something wrong in enqueue
buffer(VIDIOC_QBUF)) ;
return V4L2_IOCTL_ERROR ;
}
//break ; //i don't know whether the break is needed ;
}
return V4L2_NOERROR ;
}
when executed the VIDIOC_DQBUF IOCTL,the return value was right, but the
value of buf.length would always be zero. Then I used the read()
function to read raw data in the file handle for debug, and I can get
the raw data. Anybody have met this issue before ? Who can give me some
advices or tell me what is wrong , thanks a lot ~
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media Communications RD Centre
Samsung Electronics CO., LTD.
e-mail :
Re: [PATCHv6 3 of 7] Add documentation description for FM Transmitter Extended Control Class
OK, I had some time, so here are a few comments: From: Eduardo Valentin eduardo.valen...@nokia.com # HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1242209424 -10800 # Node ID ccae4c3150d272235cc2b19af8e9adb2e8b2e5f5 # Parent 6220548f4843ce4d19868dfcf5316d6b58a77824 This single patch adds documentation description for FM Transmitter (FMTX) Am I the only one who consistently reads this as FMT-X instead of FM-TX? I wonder if it is just me or if it wouldn't be better to put an underscore between FM and TX. Extended Control Class and its Control IDs. The text was added under Extended Controls section. Priority: normal Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com diff -r 6220548f4843 -r ccae4c3150d2 v4l2-spec/controls.sgml --- a/v4l2-spec/controls.sgml Wed May 27 11:56:46 2009 +0300 +++ b/v4l2-spec/controls.sgml Wed May 13 13:10:24 2009 +0300 @@ -458,6 +458,12 @@ paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,200 @@ /tgroup /table /section + +section id=fmtx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FMTX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fmtx-control-id + titleFMTX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FMTX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FMTX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PI/constantnbsp;/entry + entryinteger/entry + /row It might be a good idea to add references to the specs used in these RDS descriptions. + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Type field for transmission. +This coding of up to 31 pre-defined programme types./entry + /row +!-- + row + entry spanname=idconstantV4L2_CID_RDS_PS_NAME/constantnbsp;/entry + entryinteger/entry + /row How can this be an integer? Shouldn't this be a string? If so, then we first need to add string support to the extended controls. + rowentry spanname=descr./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RADIO_TEXT/constantnbsp;/entry + entryinteger/entry Ditto. Also, is there no support for the Programme Type Name? + /row + rowentry spanname=descr./entry + /row +-- + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the audio deviation limiter feature. +The limiter is useful when trying to maximize the audio volume, minimize receiver-generated +distortion and prevent overmodulation. +/entry + /row + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_RELEASE_TIME/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the audio deviation limiter feature release time. +The unit, step and range are
Re: [PATCHv6 3 of 7] Add documentation description for FM Transmitter Extended Control Class
Hi Hans, On Mon, Jun 08, 2009 at 01:47:10PM +0200, ext Hans Verkuil wrote: OK, I had some time, so here are a few comments: From: Eduardo Valentin eduardo.valen...@nokia.com # HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1242209424 -10800 # Node ID ccae4c3150d272235cc2b19af8e9adb2e8b2e5f5 # Parent 6220548f4843ce4d19868dfcf5316d6b58a77824 This single patch adds documentation description for FM Transmitter (FMTX) Am I the only one who consistently reads this as FMT-X instead of FM-TX? I wonder if it is just me or if it wouldn't be better to put an underscore between FM and TX. Well, at first time I did put the underscore, but I realized the macro names became long. I don't see too many difference putting a underscore there. Extended Control Class and its Control IDs. The text was added under Extended Controls section. Priority: normal Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com diff -r 6220548f4843 -r ccae4c3150d2 v4l2-spec/controls.sgml --- a/v4l2-spec/controls.sgml Wed May 27 11:56:46 2009 +0300 +++ b/v4l2-spec/controls.sgml Wed May 13 13:10:24 2009 +0300 @@ -458,6 +458,12 @@ paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,200 @@ /tgroup /table /section + +section id=fmtx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FMTX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fmtx-control-id + titleFMTX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FMTX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FMTX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PI/constantnbsp;/entry + entryinteger/entry + /row It might be a good idea to add references to the specs used in these RDS descriptions. right. I think the rds specification is on EN 50067 EUROPEAN STANDARD. + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Type field for transmission. +This coding of up to 31 pre-defined programme types./entry + /row +!-- + row + entry spanname=idconstantV4L2_CID_RDS_PS_NAME/constantnbsp;/entry + entryinteger/entry + /row How can this be an integer? Shouldn't this be a string? If so, then we first need to add string support to the extended controls. + rowentry spanname=descr./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RADIO_TEXT/constantnbsp;/entry + entryinteger/entry Ditto. Yes, both are string. And yes, this is something incomplete. I didn't write the string manipulation for the ext controls. That's why in the code it is not filled correctly and here, the docs are in comments. Also, is there no support for the Programme Type Name? No. Well, not in this driver. As I said previously, the proposed extended controls are huge based on si4713 properties. + /row + rowentry spanname=descr./entry +
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
Hi Hans,
On Sat, 6 Jun 2009 15:00:48 +0200, Hans Verkuil wrote:
For video4linux we sometimes need to probe for a single i2c address.
Normally you would do it like this:
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
This can construct a list of one or more i2c addresses on the fly. But this
is something that really belongs in i2c.h, renamed to I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
I'm not a big fan of macros which hide how things work, but if this
makes your life easier, why not. Just send a patch and I'll queue it up
for 2.6.31.
--
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: cx18, s5h1409: chronic bit errors, only under Linux
Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - 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: cx18, s5h1409: chronic bit errors, only under Linux
On Mon, Jun 8, 2009 at 10:14 AM, Steven Toth st...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show 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: webcam drivers and V4L2_MEMORY_USERPTR support
Hi all, On 06/08/2009 10:58 AM, Stefan Kost wrote: Hans de Goede schrieb: On 06/05/2009 09:43 AM, Stefan Kost wrote: Hans de Goede schrieb: On 06/01/2009 09:58 AM, Trent Piepho wrote: On Mon, 1 Jun 2009, Stefan Kost wrote: I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers v4l2src [1]. This allows to request shared memory buffers from xvideo, capture into those and therefore save a memcpy. This works great with the v4l2 driver on our embedded device. When I was testing this on my desktop, I noticed that almost no driver seems to support it. I tested zc0301 and uvcvideo, but also grepped the kernel driver sources. It seems that gspca might support it, but I ave not confirmed it. Is there a technical reason for it, or is it simply not implemented? userptr support is relatively new and so it has less support, especially with driver that pre-date it. Maybe USB cams use a compressed format and so userptr with xvideo would not work anyway since xv won't support the camera's native format. It certainly could be done for bt8xx, cx88, saa7134, etc. Even in the webcam with custom compressed format case, userptr support could be useful to safe a memcpy, as libv4l currently fakes mmap buffers, so what happens is: camdirect transfer mmap bufferlibv4l format conversion fake mmap buffer application-memcpy dest buffer So if libv4l would support userptr's (which it currently does not do) we could still safe a memcpy here. Do you mean that if a driver supports userptr and one uses libv4l instead of the direct ioctl, there is a regression and the app iuppo getting told only mmap works? Yes, this was done this way for simplicity's sake (libv4l2 is complex enough at is). At the time this decision was made it was an easy one to make as userptr support mostly was (and I believe still is) a paper excercise. Iow no applications and almost no drivers support it. If more applications start supporting it, support can and should be added to libv4l2. But this will be tricky. E.g. omap2 v4l2 drivers (e.g. used in Nokia N800/N810) support it and the new drivers fro omap3 will do the same. I probably need to revert the libv4l usage in gstreamer than as we can have regressions in applications ... Erm the current (0.10.15) gstreamer libv4l2 plugin does not even use USERPTR support (which confirms my I didn't implement it because nothing uses it reasoning), so there can be no regression. Now not using libv4l will make gstreamer applications not work with *hundreds* of different webcam models (and that is not an exageration), see: http://moinejf.free.fr/webcam.html For an incomplete list, now some there may work without libv4l, but most don't. So given as a choice: * not having a performance enhancement, which was never present before so no regression * not working with *hundreds* of different webcam models Which one are you going to choose ? I will most certainly know where to redirect the bug reports. 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: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 10:17 AM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 10:14 AM, Steven Tothst...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show data? Devin Steven, Devin, Thanks for your replies. The signal and SNR are usually in the range 0x0128 - 0x0140. They may increment or decrement on a per-second basis but otherwise remain steady. The status field does not change most of the time when bit errors occur, but it does lose the lock from time to time for a second. Here is a representative sample: da...@delldimension:~$ azap -r RTN using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 55500 Hz video pid 0x0051, audio pid 0x0052 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 012e | snr 012e | ber 1b04 | unc 1b04 | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0269 | unc 0269 | FE_HAS_LOCK status 1f | signal 012e | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0266 | unc 0266 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0002 | unc 0002 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0150 | unc 0150 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0273 | unc 0273 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0001 | unc 0001 | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 07 | signal 012c | snr 012c | ber | unc | status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber 0263 | unc 0263 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK -- 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, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/08/2009 10:17 AM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 10:14 AM, Steven Tothst...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show data? Devin Steven, Devin, Thanks for your replies. The signal and SNR are usually in the range 0x0128 - 0x0140. They may increment or decrement on a per-second basis but otherwise remain steady. The status field does not change most of the time when bit errors occur, but it does lose the lock from time to time for a second. Here is a representative sample: da...@delldimension:~$ azap -r RTN using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 55500 Hz video pid 0x0051, audio pid 0x0052 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 012e | snr 012e | ber 1b04 | unc 1b04 | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is borderline. I like my cable system at home to be atleast 32db (0x140) bare minimum, it's typically 0x160 (36db) for comfort. It's possible that the tuner and 1409 driver are a little more optimized under windows. How much attenuation can you add under windows with signal loss? It's probably reasonably close to the edge also. -- Steven Toth - 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
soc-camera: Why are exposure and gain handled via special cases?
Hi All,
Whilst working on merging the various ov7670 drivers posted
recently, I came across the following in soc-camera:
static int soc_camera_g_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
struct soc_camera_file *icf = file-private_data;
struct soc_camera_device *icd = icf-icd;
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
WARN_ON(priv != file-private_data);
switch (ctrl-id) {
case V4L2_CID_GAIN:
if (icd-gain == (unsigned short)~0)
return -EINVAL;
ctrl-value = icd-gain;
return 0;
case V4L2_CID_EXPOSURE:
if (icd-exposure == (unsigned short)~0)
return -EINVAL;
ctrl-value = icd-exposure;
return 0;
}
return v4l2_device_call_until_err(ici-v4l2_dev, (__u32)icd, core,
g_ctrl, ctrl);
}
Why are these two cases and only these two handled by soc-camera rather than
being passed
on to the drivers?
Thanks,
Jonathan
--
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, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 12:31 PM, Steven Toth wrote: Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is borderline. Oh okay ... I wasn't sure how to translate those values before. I like my cable system at home to be atleast 32db (0x140) bare minimum, it's typically 0x160 (36db) for comfort. In your opinion, would I have enough justification for asking Comcast to increase the signal strength coming to my house? I'd like to avoid calling someone to come out to my house to say your TV works fine, what's the problem? and get slapped with a repair fee. I wasn't sure how well I could trust the SNR values reported by the card either... I wish I had a meter or something to test it on my own. When I move the computer directly to the input for the entire house, I get an increase of about 0.1dB. FYI, the signal strength is about 1dB higher for clear QAM signals. (The values I sent are for ATSC.) It's possible that the tuner and 1409 driver are a little more optimized under windows. How much attenuation can you add under windows with signal loss? It's probably reasonably close to the edge also. I tuned to the same channel under Windows, and I used the Signal Strength Indicator application from Hauppauge (downloadable under the Accessories page in the Support section). It's reporting a SNR of 29-30 dB, and the value for 'correctable' errors goes to a single-digit value about every 5 seconds -- following the same pattern seen with 'azap'. However, the difference is that 'uncorrectable' errors stays at 0. Under Linux, it seems that all errors are 'uncorrectable'. Does the error correction occur in the driver or in the chipset? Seems to me like maybe error correction is either not enabled or not implemented correctly by the driver? I agree that the SNR could be better, and if you think it is worth a try, I'll see what Comcast will do. However, because Windows and my TV work almost flawlessly, the Linux driver would ideally handle the signals at least as well as them... Let me know what else is helpful from me, and thanks again for your help. David -- 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 Jun 8 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11930:ed3781a79c73 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-rc7-armv5: OK 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-rc7-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc7-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc7-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc7-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc7-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc7): 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: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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 from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build 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: [PATCH 1/9] vpfe-capture bridge driver for DM355 DM6446
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@skynet.be]
Sent: Friday, June 05, 2009 12:44 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; Muralidharan Karicheri; Hans Verkuil
Subject: Re: [PATCH 1/9] vpfe-capture bridge driver for DM355 DM6446
Hi,
I've removed the points to which my response would just have been 'ok'.
On Wednesday 03 June 2009 16:46:05 Karicheri, Muralidharan wrote:
+#include media/tvp514x.h
We should try to get rid of the TVP514x dependency. See below where
TVP5146 support is explicit for a discussion on this.
[MK]Agree. Only reason this is included is to configure the vpfe hw
interface based on the sub device (tvp5146) output format. The output
from
TVP device is BT656. The bridge driver is expected to work with multiple
interfaces such as BT.656, BT.1120, RAW image data bus consisting of 10
bit
data, vsync, hsync etc. So I need to have a way of getting/setting hw
interface parameters based on sub device output interface. Currently this
support is not available in sub device.
Unfortunately. However, it's the right way to go. Let's all cross our
fingers
and hope Hans will be able to find some time in his busy schedule to
comment
on this :-)
[MK] Ok
I see some discussion in the mailing list for allowing bridge driver to
set
the platform data in the sub device using s_config or
v4l2_i2c_subdev_board(). I am not sure what will come out of this. Hans
had
a comment against DM6467 display driver to use the new v4l2 api
v4l2_i2c_new_probed_subdev_addr(). When using this API, I find that the
i2c
driver is probed without setting the platform data (assume this is not
defined statically using i2c_board_info in board setup file). Since both
sub-device and bridge driver needs to be aware of the interface or bus
that
are used for connecting the devices, I strongly feel a need for defining
a
structure for interface configuration in the v4l2-subdev.h, define the
values in board setup file and pass the same from bridge driver to sub
device as an argument to v4l2_i2c_new_probed_subdev_addr() and set the
same
before calling the probe. I have posted an RFC for this in the linux
media
mailing list. So this cannot be done at this time.
I'll try to comment your RFC, but I'm not familiar with v4l2-subdev yet.
+/* Since this is hw default, we will find this pix
format
*/ +temp = vpfe_lookup_hw_format(pixfmt-pixelformat); +
+} else {
+/* check if hw supports it */
+pix_fmt = vpfe_pix_fmts[temp];
+temp = 0;
+found = 0;
+while (ccdc_dev-hw_ops.enum_pix(hw_pix, temp) = 0) {
+if (pix_fmt-hw_fmt == hw_pix) {
+found = 1;
+break;
+}
+temp++;
Wouldn't it be better to have a try_frame_format CCDC operation for
this ?
[MK] vpfe capture can support multiple formats based on platform and ccdc
and previewer/resizer's availability. So vpfe capture has to query both
ccdc and previewer/resizer hw modules to check if a given pixel format
can
be used. Since try_frame_format() generally adjust the values to match
hardware, this cannot work in this situation. In my implementation, I can
query previewer/resizer if a pixel format is not supported in ccdc.
Are the formats supported by the CCDC, previewer and resizer modules
dynamic ?
If they can't change at runtime it would be easier to store them in a table
that can be directly accessed by the VPFE driver instead of using an
enumeration callback.
[MK] It is not dynamic. It depends on the platform and availability of
previewer resizer in the data path. Here is the list of formats supported per
platform.
DM6446 : CCDC (Raw Bayer 8 bit a-law compressed, Raw Bayer 16 bit uncompressed)
DM6446 : previewer (Raw Bayer 16 bit uncompressed, UYVY)
DM355 : CCDC (Raw Bayer 8 bit a-law compressed, Raw Bayer 16 bit uncompressed)
DM355 : previewer/resizer (Raw Bayer 16 bit uncompressed, UYVY)
DM365 : CCDC (Raw Bayer 8 bit a-law compressed, Raw Bayer 8 bit DPCM
compressed, Raw Bayer 16 bit uncompressed)
DM365 : previewer/resizer (Raw Bayer 16 bit uncompressed, UYVY, NV12)
So if you need to keep a table, you need to do it on a per platform basis.
It is more cleaner to Keep one table for all available formats and have a api
function in the ccdc hw device or previewer/resizer device to enumerate it's
formats, and then use the table above to lookup the format details as is done
in my driver. BTW, I have removed the intermediate vpfe pixel format as per
your comment.
+
+static int vpfe_g_fmt_vid_cap(struct file *file, void *priv,
+struct
Re: [PATCH 00/10 v2] soc-camera conversions
On Tue, 19 May 2009, Paul Mundt wrote: On Fri, May 15, 2009 at 07:18:45PM +0200, Guennadi Liakhovetski wrote: this is the next round of soc-camera conversions. Run-tested on i.MX31, PXA270, SH7722, compile-tested only for i.MX1. It should have been a straight-forward port of the previous version to a more current tree, but then I started converting soc_camera_platform, and things became a bit more complex... As a bonus, now soc-camera can handle not only i2c subdevices, and we can even drop the CONFIG_I2C dependency again. I'll also upload a comlpete stack somewhere a bit later, for example for those, wishing to test it on i.MX31, otherwise the series will not apply cleanly. I'd like to push the first 8 of them asap, 9 and 10 will still have to be reworked Paul, I put you on cc on all patches, because, unfortunately, several of them affect arch/sh. But I'll mention it explicitly in each such patch. Looks ok to me, there shouldn't be any problems with taking these all through the v4l tree. Feel free to add my Acked-by if you like. I guess we will find out in -next if there are any conflicts or not :-) Yes, can do this, thanks, but first these 3 patches (including Magnus' ack) have to be applied to sh: http://www.mail-archive.com/linux-media@vger.kernel.org/msg05223.html which in turn depend on http://www.mail-archive.com/linux-media@vger.kernel.org/msg04724.html and the latter one is already in the next tree. Would you like me to also merge and pull the above three patches via v4l or would you be applying them yourself? 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
[PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Mauro, Please pull from http://linuxtv.org/hg/~eandren/v4l-dvb/ for the following 2 changesets: 01/02: gspca - m5602-s5k4aa: Add vflip quirk for the Lenovo Y300 http://linuxtv.org/hg/~eandren/v4l-dvb/?cmd=changeset;node=0bf9d9e5b5d1 02/02: gspca - m5602-ov9650: Add vflip quirk for the ASUS A6VA http://linuxtv.org/hg/~eandren/v4l-dvb/?cmd=changeset;node=73079bd14c57 m5602_ov9650.c |7 +++ m5602_s5k4aa.c |6 ++ 2 files changed, 13 insertions(+) Thanks, Erik -- 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, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/08/2009 12:31 PM, Steven Toth wrote: Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is borderline. Oh okay ... I wasn't sure how to translate those values before. I like my cable system at home to be atleast 32db (0x140) bare minimum, it's typically 0x160 (36db) for comfort. In your opinion, would I have enough justification for asking Comcast to increase the signal strength coming to my house? I'd like to avoid calling someone to come out to my house to say your TV works fine, what's the problem? and get slapped with a repair fee. I wasn't sure how well I could trust the SNR values reported by the card either... I wish I had a meter or something to test it on my own. When I move the computer directly to the input for the entire house, I get an increase of about 0.1dB. No idea, I debug my own cable network issues. That being said, usually cable companies like to deliver 0db to the house which is nice and hot, then it gets split and energy loss occurs 9as well as noise injection). I usually take home some metering equipment from the office to sweep my home network. FYI, the signal strength is about 1dB higher for clear QAM signals. (The values I sent are for ATSC.) It's possible that the tuner and 1409 driver are a little more optimized under windows. How much attenuation can you add under windows with signal loss? It's probably reasonably close to the edge also. I tuned to the same channel under Windows, and I used the Signal Strength Indicator application from Hauppauge (downloadable under the Accessories page in the Support section). It's reporting a SNR of 29-30 dB, and the value for 'correctable' errors goes to a single-digit value about every 5 seconds -- following the same pattern seen with 'azap'. However, the difference is that 'uncorrectable' errors stays at 0. Under Linux, it seems that all errors are 'uncorrectable'. So you don't have much leg room with windows either, certainly not enough for my liking. The difference between zero errors and a small handful can be pretty small in RF terms. Does the error correction occur in the driver or in the chipset? Seems to me like maybe error correction is either not enabled or not implemented correctly by the driver? Error recovery is done in the chipset and is only as good as the RF signal reaching the demodulator. I agree that the SNR could be better, and if you think it is worth a try, I'll see what Comcast will do. However, because Windows and my TV work almost flawlessly, the Linux driver would ideally handle the signals at least as well as them... No idea and no I don't agree, just because your TV works doesn't mean the Linux driver has to be reliable. That's wishful thinking on your part and Comcast are not obliged to make your TV tuner work. Again, if you have 29-30db on Windows you don't have a lot of legroom for signal attenuation before you'll see errors. I frequently had windows reception errors when running at 31db with some boards. We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Is the mxl5005s Linux tuner driver perfect? Is it as good as windows? Not quite, but it's good for many people and it's unlikely to improve in the near future. Try installing a decent cable amp. Try looking at the MythTV wiki and support sites for improving your cable network. Let me know what else is helpful from me, and thanks again for your help. David No problem, your welcome. I hope this advice helps. Regards, -- Steven Toth - 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: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 04:36 PM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 4:20 PM, Steven Tothst...@kernellabs.com wrote: We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Comcast is coming tomorrow to check out the signal quality. They said that they expect to deliver SNR in the range of 33dB - 45dB to the premises. I will let you know how that affects Linux captures. Steven, One thing that is interesting is that he is getting BER/UNC errors even on ATSC, when he has a 30.2 dB signal. While I agree that the cable company could be sending a weak signal, 30 dB should be plenty for ATSC. Also, it's possible that the playback application/codec in question poorly handles recovery from MPEG errors such as discontinuity, which results in the experience appearing to be worse under Linux. I am actually comparing the TS files captured under both Linux and Windows side-by-side in the same environment, copying the files to other computers in my home. I can demux the video with Project-X which prints out the errors in the bitstream as it reads them. I can also observe the overall quality by playing it back with VLC, WinDVD, etc. When I use TMPGEnc Authoring Works 4 to read the file, the errors in the bitstream even seem to crash the application -- though obviously TMPGEnc is to blame for that. I'm going to see if I can find some cycles to do some testing here with s5h1409/s5h1411 and see if I can reproduce what David is seeing. Devin, I would really really appreciate this. I hesitated to e-mail this list for several weeks, because I wanted to investigate thoroughly first and avoid wasting anyone's time as much as possible. I hope you are able to reproduce this. David -- 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, s5h1409: chronic bit errors, only under Linux
On Mon, Jun 8, 2009 at 5:03 PM, David Ward david.w...@gatech.edu wrote: Devin, I would really really appreciate this. I hesitated to e-mail this list for several weeks, because I wanted to investigate thoroughly first and avoid wasting anyone's time as much as possible. I hope you are able to reproduce this. Well, I've got a few different combinations of s5h1409 tuners and demods (including the HVR-1600), so if I can reproduce the issue, I can probably narrow it down as to whether it's a tuner or a demod issue. I've spent a good bit of time analyzing the s5h1409 driver in the past, although I don't have the datasheet for the chip. Cheers, 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: [PATCH 3/9] dm355 ccdc module for vpfe capture driver
Laurent,
Laurent,
Thanks for reviewing this. See my response below for few comments. Rest of them
I have incorporated into my next patch.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+if (offset = ccdc_addr_size)
This should be .
+return __raw_readl(ccdc_base_addr + offset);
+else {
+dev_err(dev, offset exceeds ccdc register address space\n);
+return -1;
+}
+}
+
+static inline u32 regw(u32 val, u32 offset)
+{
+if (offset = ccdc_addr_size) {
This should be .
[MK] I removed above two checks since we are getting the required IO block
mapped and this check is not needed. if some reason there is an offset outside
the valid range, it is a bug and will be caught through oops, right?.
+__raw_writel(val, ccdc_base_addr + offset);
+return val;
+} else {
+dev_err(dev, offset exceeds ccdc register address space\n);
+return -1;
+}
+}
Can't you check that ccdc_addr_size is big enough in ccdc_set_ccdc_base ?
The
read/write access functions could then be made much simpler.
[MK] See above comment
+
+
+/* Query control. Only applicable for Bayer capture */
+static int ccdc_queryctrl(struct v4l2_queryctrl *qctrl)
+{
+int i, id;
+struct v4l2_queryctrl *control = NULL;
+
+dev_dbg(dev, ccdc_queryctrl: start\n);
+if (NULL == qctrl) {
Can this happen ?
[MK] No. removed
+dev_err(dev, ccdc_queryctrl : invalid user ptr\n);
+return -EINVAL;
+}
+
+if (VPFE_RAW_BAYER != ccdc_if_type) {
+dev_err(dev,
+ ccdc_queryctrl : Not doing Raw Bayer Capture\n);
+return -EINVAL;
+}
+
+id = qctrl-id;
+memset(qctrl, 0, sizeof(struct v4l2_queryctrl));
+for (i = 0; i CCDC_MAX_CONTROLS; i++) {
+control = ccdc_control_info[i];
+if (control-id == id)
+break;
+}
+if (i == CCDC_MAX_CONTROLS) {
+if (NULL == ctrl) {
+dev_err(dev, ccdc_setcontrol: invalid user ptr\n);
+return -EINVAL;
+}
+
+if (ccdc_if_type != VPFE_RAW_BAYER) {
+dev_err(dev,
+ ccdc_setcontrol: Not doing Raw Bayer Capture\n);
Should user-triggered errors use dev_err or dev_dbg ? I'm not sure we want
to
fill the kernel log with KERN_ERR message just because an application
doesn't
get its control ids right.
[MK] changed to dev_dbg
+}
+
+switch (ctrl-id) {
+case CCDC_CID_R_GAIN:
+gain-r_ye = ctrl-value CCDC_GAIN_MASK;
+break;
+case CCDC_CID_GR_GAIN:
+gain-gr_cy = ctrl-value CCDC_GAIN_MASK;
+break;
+case CCDC_CID_GB_GAIN:
+gain-gb_g = ctrl-value CCDC_GAIN_MASK;
+break;
+
+case CCDC_CID_B_GAIN:
+gain-b_mg = ctrl-value CCDC_GAIN_MASK;
+break;
case CCDC_CID_OFFSET: ?
+default:
+ccdc_hw_params_raw.ccdc_offset = ctrl-value
CCDC_OFFSET_MASK;
[MK] default is for offset. We are validating the ids above for any of the
checked values in the switch statement
+
+static void ccdc_reset(void)
+{
+int i;
+/* disable CCDC */
+dev_dbg(dev, \nstarting ccdc_reset...);
+ccdc_enable(0);
+/* set all registers to default value */
+for (i = 0; i = 0x15c; i += 4)
+regw(0, i);
Ouch ! Not all registers have a 0 default value. Beside, blindly resetting
all
registers sounds hackish. According to the documentation, the proper way to
reset the VPFE/VPSS is through the power sleep controller.
[MK] This function actually write default values in the registers since the
implementation assume this. So I have renamed it as ccdc_restore_defaults(). We
don't want to reset the ccdc here, only want to write default values.
+/* no culling support */
+regw(0x, CULH);
+regw(0xff, CULV);
+/* Set default Gain and Offset */
+ccdc_hw_params_raw.gain.r_ye = 256;
+ccdc_hw_params_raw.gain.gb_g = 256;
+ccdc_hw_params_raw.gain.gr_cy = 256;
+ccdc_hw_params_raw.gain.b_mg = 256;
+ccdc_hw_params_raw.ccdc_offset = 0;
+ccdc_config_gain_offset();
+/* up to 12 bit sensor */
+regw(0x0FFF, OUTCLIP);
+/* CCDC input Mux select directly from sensor */
+regw_bl(0x00, CCDCMUX);
+dev_dbg(dev, \nEnd of ccdc_reset...);
+}
+
+static int ccdc_open(struct device *device)
+{
+dev = device;
+ccdc_reset();
+return 0;
+}
+
+static int ccdc_close(struct device *device)
+{
+/* do nothing for now */
+return 0;
+}
+/*
+ * ccdc_setwin
+ *
+ * This function will configure the window size to
+ * be capture in CCDC reg
+ */
+static void ccdc_setwin(struct ccdc_imgwin
Re: funny colors from XC5000 on big endian systems
You indicated that you had reason to believe it's a PowerPC issue. Is there any reason that you came to that conclusion other than that you're running on ppc? I'm not discounting the possibility, but it would be good to know if you have other information that supports your theory. It was a hypothesis, but based on experience in seeing endian bugs in video code and hearing endian bugs in audio code. After using PowerPC long enough, you learn to jump to the endian conclusion pretty quickly. I was wrong! Ok, well that's good to know. I did look at the code and couldn't see how it could possibly be an endianness bug. Bear in mind that the analog support for the 950q is still relatively new, and its entirely possible there are some application specific bugs to be worked out as there is more testing. Could you please describe in more detail the *exact* configuration you are attempting, including the versions of the applications you are using and command line arguments you are passing. If I can reproduce the issue here then I can probably debug it much faster. I have a VCR connected to my 950Q using the coaxial interface. Kernel is 2.6.29.4. I am using streamer from Fedora's xawtv-3.95-11.fc11.ppc: v4lctl setchannel 3 streamer -r 30 -s 640x480 -f jpeg -i Television -n NTSC-M -c /dev/ video0 -o ~/Desktop/foo.avi -t 00:60:00 I am using gstreamer-plugins-good-0.10.14-2.fc11.ppc: gst-launch v4l2src ! ffmpegcolorspace ! ximagesink Mike -- 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: [linux-dvb] SAA7162 status
Hi guys, How does one find out what is left to be done with the above project. I have been following http://jusst.de/hg/saa716x closely and it's getting there the work that Manu A is heading up is awesome keep up the good work. I just wanted to know where you were at with the driver\s what is left to be done? because I may be able to offer some assistance if required...I’ll see what I can do anyway to get done and across the line. Thanks. -- 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 - Locking resources between V4L and DVB interfaces
Hi Rusty, Am Dienstag, den 26.05.2009, 13:51 -0600 schrieb Rusty Scott: Hello all, I talked to Mauro offline about this issue and he indicated that it was an area that could use some attention. So I have decided to take this issue on and am looking for comments about how this should work. Issue: The DVB and V4L interfaces are considered different devices from a system standpoint. However they often share a hardware resource, such as a tuner, on many cards. There is currently no locking on the shared resource, so one interface could interfere with the resources already in use by the other. My experience in the code tree and API are not very in depth. I've only helped maintain some card specific code to this point. I'm looking for comments and information on various ways to accomplish this and possible gotchas to watch out for. Any pointers, suggestions or other help on this would be appreciated. Thanks, Rusty if it is only about Mauro trying to distribute some work, it is ok, but if it should be only about some exams done soon, better forget about it. I don't expect the latter, but it would sound very similar. So, you start with Steven's friends multi frontend usage on the cx88. If you are still looking for work, the md8080 Medion Quad(ro) and some other at least triple devices on the saa7134 driver might be interesting concerning existing hardware based on reference designs. (This may include limitations only resolved in later chipsets, eventually...) 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: [PATCHv6 3 of 7] Add documentation description for FM Transmitter Extended Control Class
On Mon, 2009-06-08 at 13:47 +0200, Hans Verkuil wrote: OK, I had some time, so here are a few comments: From: Eduardo Valentin eduardo.valen...@nokia.com + rowentry spanname=descrConfigures the pre-emphasis value for broadcasting. +A pre-emphasis filter is applied to the broadcast to accentuate the high audio frequencies. +Depending on the region, a time constant of either 50 or 75 useconds is used. Possible values +are:/entry + /rowrow + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_FMTX_PREEMPHASIS_DISABLED/constantnbsp;/entry + entryNo pre-emphasis is applied./entry + /row + row + entryconstantV4L2_FMTX_PREEMPHASIS_50_uS/constantnbsp;/entry + entryA pre-emphasis of 50 uS is used./entry + /row + row + entryconstantV4L2_FMTX_PREEMPHASIS_75_uS/constantnbsp;/entry + entryA pre-emphasis of 75 uS is used./entry + /row + /tbody + /entrytbl + + /row Do you know when to use which pre-emphasis? I depends on what de-emphasis filter the receivers are using. This is usually a national or regional regulatory decision imposed upon the broadcasters and hence receiver manufacturers. The choice made by regulators probably depends on allowable field strength (chosen by regulators) for the broadcast area and the expected propagation conditions and man-made noise sources (which dominate in VHF). Preemphasis boosts the normally smaller magnitude, high frequency part of the FM signal spectrum. The receiver can then attenuate the received noise and knock down the higher frequency part of the FM signal back down to normal levels with a deemphasis filter. The end result is an imporved SNR for the high frequency part of the FM signal spectrum. The CX25843 datasheet actually has an OK picture. There is a similar MPEG control but I've never been able to find out when to use pre-emphasis and which mode should be used. I'd appreciate it if you can point me to some documentation on this issue. And perhaps that info should also be added to this doc. If you have audio that you know has a lot of high frequency content (televised music concert), you may wish to use pre-emphahsis filtering before compression, and not use it for something with mostly low freqs (a talk show). You of course have to have the pre-emphasis filters available and the ability to enable/disable them. The preemphasis parameters in MPEG are to describe the preemphasis added to the baseband audio, or the deepmhasis that must occur after the audio is decompressed back to baseband. The idea is that digitzation and compression processing are going to introduce noise that will be significant compared to the high frequency components of the audio. A preemphahsis filter amplifies these before sampling. That way, after reconstruction on the other end, the high frequency audio can be deemphasized with a complementary filter. MPEG can carry metadata specifying a 50/15 us or a CCITT J.17 filter characteristic. For 44.1 ksps, 50us and 15 us correspond to filter corner freqs of 1/(50 us * 2 * pi) = 3.183 kHz 1/(15 us * 2 * pi) = 10.61 kHz with a 10 dB change in gain between the two corners (I think). It looks like the CCITT J.17 curve corresponds to the pre-emphasis filter used by NICAM. There's a picture of the J.17 preemphasis curve here in section 4.1: http://tallyho.bc.nu/~steve/nicam.html The CX25843 data sheet also has a picture of a NICAM de-emphasis filter characteristic. (Someone should really pull out the standards and verify all that.) + row + entry spanname=idconstantV4L2_CID_TUNE_ANTENNA_CAPACITOR/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrThis selects the value of antenna tuning capacitor +manually or automatically if set to zero. Unit, range and step are driver-specific./entry Same question: is there a reason why the unit is driver-specific? Because for a peaking control, an absolute unit doesn't matter. It would probably be too much work to figure out what they Though for a capacitor, one would expect a unit to be some fraction of a Farad. If I'm guessing right, this value is used to tune an impedance matching circuit for maximum power transfer to the antenna. While tweaking this, I assume one is inspecting an output somewhere else for a peak or minimum level. This really seems like something you usually want to happen automatically with a control loop anyway (which is handled by the 0 case). Regards, Andy + /row + rowentry/entry/row + /tbody + /tgroup + /table +/section /section !-- Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: About the VIDIOC_DQBUF
hi ~~ Dongsoo, Nathaniel ~
I am sorry for disturbing you, and not descripe the question clear ~
Thanks very much for your help ~~
I know that I must stop preview with streamoff and re-configure with
s_fmt ~~ I have asked to you before ~!~
The full frame means a complete frame ~Because I just need to get the
frame data and post it to multimedia framework, so I want to consult to
you that if I can get a complete frame with memcpy ~~
I want to know that can I get a complete frame from buf.start to the
end , and the memory-lenth is buf.byteused ~
buf.byteused
|-|
buf.startend
在 2009-06-08一的 20:40 +0900，Dongsoo, Nathaniel Kim写道：
Hi,
Sorry I'm not an expert, you can expect expertise from maintainers not from
me.
But before answering your question about capturing, I'm not sure about
what the full frame means. I just assume that you meant to say the
biggest resolution of image frame, right?
So, when you are to capture a full resolution data while preview is
working, you need to stop preview with streamoff, re-configure
resolution with s_fmt to external camera module and start capturing
issuing streamon with re-configured resolution. I think you are
well-aware with this, aren't you? And in my opinion, memcpy may be
cool for that. What else are you expecting to use? and for what?
Anyway, I wish you luck.
Cheers,
Nate
On Mon, Jun 8, 2009 at 5:02 PM, xieyili@gmail.com wrote:
Hi Dongsoo, Nathaniel ~
You must be expert on V4l2 ~ Thanks very much for your help and advice
~!~
I used the MXC camera interface driver from Fressscale ,I readed the
driver interface just now ,and have fouded that the driver not modified
the buf.lenth but buf.byteused . You are very right , I will use the
buf.byteused instead of buf.length ~
There is also a problem I want to consult to you ~ Can i get a full
frame with the below method if the driver have no problem ?
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.byteused) ;
Because I just need to implement a hal for getting the frame data and
post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
what about your advice ?
Thanks a lot ~~
在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
Hello Xie,
I'm not sure which camera interface driver you are using, but it seems
to be camera interface driver's problem. Let me guess, are you using
pxa camera interface driver from Marvell?(proprietary but not in up
stream kernel)
It just looks like that camera interface driver is not returning
proper data in dqbuf.
And one more thing. I prefer to use byteused rather than length in
buf. because as far as I know the size of preview data from camera is
in byte unit which we need to copy to memory. But it should be
possible to use length, I guess..
Cheers,
Nate
On Mon, Jun 8, 2009 at 11:05 AM, xieyili@gmail.com wrote:
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(fds) ;
FD_SET(v4l2Fd, fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, fds, NULL, NULL, tv) ;
LOGD(The value of select return : %d\n, rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE(READ ERROR) ;
}
***/
if(-1 == rt){
LOGE(there is something wrong in select
function(select)) ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE(wait for data timeout in select) ;
return V4L2_TIMEOUT ;
}
memset(buf, 0, sizeof(buf)) ;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
buf.memory = V4L2_MEMORY_MMAP ;
if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, buf)){
LOGE(there is something wrong in dequeue
buffer(VIDIOC_DQBUF)) ;
return V4L2_IOCTL_ERROR ;
}
assert(i n_buf) ;
LOGE(buf.index 0buf.length = %d %d \n, buf.index ,
buf.length) ;
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.length) ;
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Mon, 2009-06-08 at 16:20 -0400, Steven Toth wrote: Try installing a decent cable amp. Try looking at the MythTV wiki and support sites for improving your cable network. If using an amp, be sure you pick one with appropriate gain and noise figure. Overdriving the mxl5005s with too much signal can degrade SNR as well. Here's my standard list of things to check: http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality Good luck. 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
