Re: [RFCv1 0/4] v4l: DMA buffer sharing support as a user
Hi, Since dma_buf is merged at v3.3-rc, I hope to merge this one also at this merge window. Now it's tested at OMAP. also it's used at exynos but not yet fully tested. Thank you, Kyungmin Park On 1/5/12, Sumit Semwal wrote: > Hello Everyone, > > A very happy new year 2012! :) > > This patchset is an RFC for the way videobuf2 can be adapted to add support > for > DMA buffer sharing framework[1]. > > The original patch-set for the idea, and PoC of buffer sharing was by > Tomasz Stanislawski , who demonstrated buffer > sharing > between two v4l2 devices[2]. This RFC is needed to adapt these patches to > the > changes that have happened in the DMA buffer sharing framework over past few > months. > > To begin with, I have tried to adapt only the dma-contig allocator, and only > as > a user of dma-buf buffer. I am currently working on the v4l2-as-an-exporter > changes, and will share as soon as I get it in some shape. > > As with the PoC [2], the handle for sharing buffers is a file-descriptor > (fd). > The usage documentation is also a part of [1]. > > So, the current RFC has the following limitations: > - Only buffer sharing as a buffer user, > - doesn't handle cases where even for a contiguous buffer, the sg_table can > have >more than one scatterlist entry. > > > Thanks and best regards, > ~Sumit. > > [1]: dma-buf patchset at: https://lkml.org/lkml/2011/12/26/29 > [2]: http://lwn.net/Articles/454389 > > Sumit Semwal (4): > v4l: Add DMABUF as a memory type > v4l:vb2: add support for shared buffer (dma_buf) > v4l:vb: remove warnings about MEMORY_DMABUF > v4l:vb2: Add dma-contig allocator as dma_buf user > > drivers/media/video/videobuf-core.c|4 + > drivers/media/video/videobuf2-core.c | 186 > +++- > drivers/media/video/videobuf2-dma-contig.c | 125 +++ > include/linux/videodev2.h |8 ++ > include/media/videobuf2-core.h | 30 + > 5 files changed, 352 insertions(+), 1 deletions(-) > > -- > 1.7.5.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
driver needed
Hi I have this usb tv card called pixelview playtv usb2 pro I have made a lot of attempts to install it on various linux kernel and systems but no lack till now this card has the following specs model No pv-tv309U+ ID 05e3:f102 Genesys Logic, Inc. VX7012 TV Box idProduct 0xf102 VX7012 TV Box is there any driver that supports this card?? can I do anything to make it work on linux?? My current linux distro is avlinux 5.0.2 Thank you in advance Pom -- 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: [Linaro-mm-sig] [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Mon, Jan 16, 2012 at 11:03 AM, Semwal, Sumit wrote:
>
> On Sun, Jan 15, 2012 at 2:08 AM, Sakari Ailus wrote:
>>
>> Hi Sumit,
>>
>> Thanks for the patch!
>
Hi Sakari,
Thanks for reviewing this :)
>>
>>
>>
>> Shouldn't the buffer mapping only be done at the first call to
>> __qbuf_dmabuf()? On latter calls, the cache would need to be handled
>> according to presence of V4L2_BUF_FLAG_NO_CACHE_CLEAN /
>> V4L2_BUF_FLAG_NO_CACHE_INVALIDATE in v4l2_buffer.
>
Well, the 'map / unmap' implementation is by design exporter-specific;
so the exporter of the buffer may choose to, depending on the use
case, 'map-and-keep' on first call to map_dmabuf, and do actual unmap
only at 'release' time. This will mean that the {map,unmap}_dmabuf
calls will be used mostly for 'access-bracketing' between multiple
users, and not for actual map/unmap each time.
Again, the framework is flexible enough to allow exporters to actually
map/unmap as required (think cases where backing-storage migration
might be needed while buffers are in use - in that case, when all
current users have called unmap_XXX() on a buffer, it can be migrated,
and the next map_XXX() calls could give different mappings back to the
users).
> The kernel 'users' of dma-buf [in case of this RFC, v4l2] should not ideally
> need to worry about the actual mapping/unmapping that is done; the buffer
> exporter in a particular use-case should be able to handle it.
>
>>
>> Same here, except reverse: this only should be done when the buffer is
>> destroyed --- either when the user explicitly calls reqbufs(0) or when
>> the file handle owning this buffer is being closed.
>>
>> Mapping buffers at every prepare_buf and unmapping them in dqbuf is
>> prohibitively expensive. Same goes for many other APIs than V4L2, I think.
>>
>> I wonder if the means to do this exists already.
>>
>> I have to admit I haven't followed the dma_buf discussion closely so I
>> might be missing something relevant here.
>
Hope the above explanation helps. Please do not hesitate to contact if
you need more details.
>>
>>
>> Kind regards,
>>
>> --
>> Sakari Ailus
>> sakari.ai...@iki.fi
Best regards,
~Sumit.
--
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: [ANNOUNCE] DVBv5 tools version 0.0.1
Em 15-01-2012 22:16, Mauro Carvalho Chehab escreveu:
> Em 15-01-2012 19:47, Antti Palosaari escreveu:
>> On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote:
>>> There was a bug at the error code handling on dvb-fe-tool: basically, if it
>>> can't open
>>> a device, it were using a NULL pointer. It was likely fixed by this commit:
>>>
>>> http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991
>>
>> That bug was fixed as I tested.
>>
>> But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls
>> get_frontent() ?
>
> That's what happens here, at the application level:
>
> $ strace dvb-fe-tool -d DVBC/ANNEX_A
>
> open("/dev/dvb/adapter0/frontend0", O_RDWR) = 3
> ioctl(3, FE_GET_INFO, 0xb070c4) = 0
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f37922be000
> write(1, "Device DRXK DVB-C DVB-T (/dev/dv"..., 68Device DRXK DVB-C DVB-T
> (/dev/dvb/adapter0/frontend0) capabilities:
> ) = 68
> write(1, "\tCAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC"..., 245 CAN_FEC_1_2 CAN_FEC_2_3
> CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO
> CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32
> CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_RECOVER CAN_TRANSMISSION_MODE_AUTO
> ) = 245
> ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
> write(1, "DVB API Version 5.5, Current v5 "..., 54DVB API Version 5.5,
> Current v5 delivery system: DVBT
> ) = 54
> ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
> write(1, "Supported delivery systems: DVBC"..., 62Supported delivery systems:
> DVBC/ANNEX_A DVBC/ANNEX_C [DVBT]
> ) = 62
> write(1, "Changing delivery system to: DVB"..., 42Changing delivery system
> to: DVBC/ANNEX_A
> ) = 42
> ioctl(3, FE_SET_PROPERTY, 0x7fff326ce340) = 0
> close(3)= 0
> exit_group(0) = ?
>
>
> The first FE_GET_PROPERTY reads the DVB API version and the current delivery
> system:
>
> parms->dvb_prop[0].cmd = DTV_API_VERSION;
> parms->dvb_prop[1].cmd = DTV_DELIVERY_SYSTEM;
>
> dtv_prop.num = 2;
> dtv_prop.props = parms->dvb_prop;
>
> /* Detect a DVBv3 device */
> if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
> parms->dvb_prop[0].u.data = 0x300;
> parms->dvb_prop[1].u.data = SYS_UNDEFINED;
> }
> parms->version = parms->dvb_prop[0].u.data;
> parms->current_sys = parms->dvb_prop[1].u.data;
>
> The second FE_GET_PROPERTY is used only if DVB API v5.5 or upper is detected,
> and does:
>
> parms->dvb_prop[0].cmd = DTV_ENUM_DELSYS;
> parms->n_props = 1;
> dtv_prop.num = 1;
> dtv_prop.props = parms->dvb_prop;
> if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
> perror("FE_GET_PROPERTY");
> dvb_v5_free(parms);
> close(fd);
> return NULL;
> }
>
> Both were called inside dvb_fe_open().
>
> The FE_SET_PROPERTY changes the property inside the DVBv5 cache,
> at dvb_set_sys():
>
> dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
> dvb_prop[0].u.data = sys;
> prop.num = 1;
> prop.props = dvb_prop;
>
> if (ioctl(parms->fd, FE_SET_PROPERTY, &prop) == -1) {
> perror("Set delivery system");
> return errno;
> }
>
> The FE_SET_PROPERTY doesn't call a DTV_TUNE, so it shouldn't be calling the
> set frontend methods inside the driver.
>
> So, from the userspace applications standpoint, I'm not seeing anything wrong.
>
>> That will cause this kind of calls in demod driver:
>> init()
>> get_frontend()
>> get_frontend()
>> sleep()
>>
>> My guess is that it resolves current delivery system. But as demod is
>> usually sleeping (not tuned) at that phase it does not know frontend
>> settings asked, like modulation etc. In case of cxd2820r those are available
>> after set_frontend() call. I think I will add check and return -EINVAL in
>> that case.
>
>
> What seems to be happening at dvb-core/dvb_frontend.h is due to this code:
>
> if(cmd == FE_GET_PROPERTY) {
> ...
> /*
> * Fills the cache out struct with the cache contents, plus
> * the data retrieved from get_frontend.
> */
> dtv_get_frontend(fe, NULL);
> for (i = 0; i < tvps->num; i++) {
> err = dtv_property_process_get(fe, c, tvp + i, file);
> if (err < 0)
> goto out;
> (tvp + i)->result = err;
> }
>
> E. g. even if the FE_GET_PROPERTY is only reading the DVB version and calling
> DTV_ENUM_DELSYS, it is calling the dtv_get_frontend() to retri
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
Em 15-01-2012 19:47, Antti Palosaari escreveu:
> On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote:
>> There was a bug at the error code handling on dvb-fe-tool: basically, if it
>> can't open
>> a device, it were using a NULL pointer. It was likely fixed by this commit:
>>
>> http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991
>
> That bug was fixed as I tested.
>
> But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls
> get_frontent() ?
That's what happens here, at the application level:
$ strace dvb-fe-tool -d DVBC/ANNEX_A
open("/dev/dvb/adapter0/frontend0", O_RDWR) = 3
ioctl(3, FE_GET_INFO, 0xb070c4) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f37922be000
write(1, "Device DRXK DVB-C DVB-T (/dev/dv"..., 68Device DRXK DVB-C DVB-T
(/dev/dvb/adapter0/frontend0) capabilities:
) = 68
write(1, "\tCAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC"..., 245CAN_FEC_1_2 CAN_FEC_2_3
CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32
CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_RECOVER CAN_TRANSMISSION_MODE_AUTO
) = 245
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, "DVB API Version 5.5, Current v5 "..., 54DVB API Version 5.5, Current
v5 delivery system: DVBT
) = 54
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, "Supported delivery systems: DVBC"..., 62Supported delivery systems:
DVBC/ANNEX_A DVBC/ANNEX_C [DVBT]
) = 62
write(1, "Changing delivery system to: DVB"..., 42Changing delivery system to:
DVBC/ANNEX_A
) = 42
ioctl(3, FE_SET_PROPERTY, 0x7fff326ce340) = 0
close(3)= 0
exit_group(0) = ?
The first FE_GET_PROPERTY reads the DVB API version and the current delivery
system:
parms->dvb_prop[0].cmd = DTV_API_VERSION;
parms->dvb_prop[1].cmd = DTV_DELIVERY_SYSTEM;
dtv_prop.num = 2;
dtv_prop.props = parms->dvb_prop;
/* Detect a DVBv3 device */
if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
parms->dvb_prop[0].u.data = 0x300;
parms->dvb_prop[1].u.data = SYS_UNDEFINED;
}
parms->version = parms->dvb_prop[0].u.data;
parms->current_sys = parms->dvb_prop[1].u.data;
The second FE_GET_PROPERTY is used only if DVB API v5.5 or upper is detected,
and does:
parms->dvb_prop[0].cmd = DTV_ENUM_DELSYS;
parms->n_props = 1;
dtv_prop.num = 1;
dtv_prop.props = parms->dvb_prop;
if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
perror("FE_GET_PROPERTY");
dvb_v5_free(parms);
close(fd);
return NULL;
}
Both were called inside dvb_fe_open().
The FE_SET_PROPERTY changes the property inside the DVBv5 cache,
at dvb_set_sys():
dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
dvb_prop[0].u.data = sys;
prop.num = 1;
prop.props = dvb_prop;
if (ioctl(parms->fd, FE_SET_PROPERTY, &prop) == -1) {
perror("Set delivery system");
return errno;
}
The FE_SET_PROPERTY doesn't call a DTV_TUNE, so it shouldn't be calling the
set frontend methods inside the driver.
So, from the userspace applications standpoint, I'm not seeing anything wrong.
> That will cause this kind of calls in demod driver:
> init()
> get_frontend()
> get_frontend()
> sleep()
>
> My guess is that it resolves current delivery system. But as demod is usually
> sleeping (not tuned) at that phase it does not know frontend settings asked,
> like modulation etc. In case of cxd2820r those are available after
> set_frontend() call. I think I will add check and return -EINVAL in that case.
What seems to be happening at dvb-core/dvb_frontend.h is due to this code:
if(cmd == FE_GET_PROPERTY) {
...
/*
* Fills the cache out struct with the cache contents, plus
* the data retrieved from get_frontend.
*/
dtv_get_frontend(fe, NULL);
for (i = 0; i < tvps->num; i++) {
err = dtv_property_process_get(fe, c, tvp + i, file);
if (err < 0)
goto out;
(tvp + i)->result = err;
}
E. g. even if the FE_GET_PROPERTY is only reading the DVB version and calling
DTV_ENUM_DELSYS, it is calling the dtv_get_frontend() to retrieve more data.
What it can be done is to do something like:
static bool need_get_frontend()
{
...
for (i = 0; i < tvps->num; i++)
...
}
if (need_get_frontend(tvps))
dtv_get_fro
Re: [RFC 06/17] v4l: Add selections documentation.
Hi Sakari, On Monday 09 January 2012 19:16:16 Sakari Ailus wrote: > Laurent Pinchart wrote: > > On Tuesday 20 December 2011 21:27:58 Sakari Ailus wrote: [snip] > >> The PADDED target > >> + provides the width and height for the padded image, > > > > Is it valid for both crop and compose rectangles ? > > I think all targets are valid for all rectangles. Should I mention that? > > The practical use cases may be more limited, though. I wonder if I > should remove the padded targets until we get use cases for them. I > included them for the reason that they also exist in the V4L2. > > Tomasz, Sylwester: do you have use for the PADDED targets? > > I think we also must define what will be done in cases where crop (on > either sink or source) / scaling / composition is not supported by the > subdev. That's currently undefined. I think it'd be most clear to return > an error code but I'm not sure which one --- EINVAL is an obvious > candidate but that is also returned when the pad is wrong. It looks > still like the best choice to me. If the rectangle isn't supported, EINVAL is appropriate. Do we need a way to discover what rectangles are supported ? If the rectangle is supported by the size is out of range, the driver should adjust it instead of returning an error. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cxd2820r: do not allow get_frontend() when demod is not initialized
This fixes bug introduced by multi-frontend to single-frontend change.
Finally HAS_LOCK is got back!
We are not allowed to access hardware in sleep mode...
Chip did not like when .get_frontend() reads some registers while
chip was sleeping and due to that HAS_LOCK bit was never gained.
TODO: We should add logic for dvb-core to drop out illegal calls like that.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb/frontends/cxd2820r_core.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c
b/drivers/media/dvb/frontends/cxd2820r_core.c
index 372a4e7..caae7f7 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -309,9 +309,14 @@ static int cxd2820r_read_status(struct dvb_frontend *fe,
fe_status_t *status)
static int cxd2820r_get_frontend(struct dvb_frontend *fe)
{
+ struct cxd2820r_priv *priv = fe->demodulator_priv;
int ret;
dbg("%s: delsys=%d", __func__, fe->dtv_property_cache.delivery_system);
+
+ if (priv->delivery_system == SYS_UNDEFINED)
+ return 0;
+
switch (fe->dtv_property_cache.delivery_system) {
case SYS_DVBT:
ret = cxd2820r_get_frontend_t(fe);
--
1.7.4.4
--
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: cx25840: improve audio for cx2388x drivers
Modified RegSpy.exe with patch, i used it to spot register changes in cx23885 and cx25840 chipsets. http://www.speedyshare.com/file/sVqSY/RegSpy.zip http://www.2shared.com/file/E_Gdj0ic/RegSpy.html Extra info: This RegSpy.exe is not enough, because some changes are fast, so if someone wants to use it it will be better to modify and remove unneded registers and change update time. I used this to display only 5 main values while recording window frame after frame to spot exact order of changes in registers. -- 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
cx25840: improve audio for cx2388x drivers
Modified RegSpy.exe with patch, i used it to spot register changes in cx23885 and cx25840 chipsets. http://www.speedyshare.com/file/sVqSY/RegSpy.zip http://www.2shared.com/file/E_Gdj0ic/RegSpy.html Extra info: This RegSpy.exe is not enough, because some changes are fast, so if someone wants to use it it will be better to modify and remove unneded registers and change update time. I used this to display only 5 main values while recording window frame after frame to spot exact order of changes in registers. M. -- 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: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote: There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit: http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991 That bug was fixed as I tested. But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls get_frontent() ? That will cause this kind of calls in demod driver: init() get_frontend() get_frontend() sleep() My guess is that it resolves current delivery system. But as demod is usually sleeping (not tuned) at that phase it does not know frontend settings asked, like modulation etc. In case of cxd2820r those are available after set_frontend() call. I think I will add check and return -EINVAL in that case. regards Antti -- http://palosaari.fi/ -- 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
v4l-utils migrated to autotools
Hello, I'm Gregor the Debian (and thus Ubuntu) Maintainer of v4l-utils. I took the challenge to convert the Makefile based build system into an autotools one. This weekend I polished the last bits and submitted my changes. If you build v4l-utils from source, please clean your tree via "git clean" after the pull. Then make sure you have autotools, libtool and pkg-config installed. Bootstrap the autotools environment by calling "autoreconf -vfi". The rest is the usual configure && make && make install. Thanks, Gregor -- 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 08/17] v4l: Image source control class
Hi Laurent, Laurent Pinchart wrote: > On Sunday 15 January 2012 20:44:02 Sakari Ailus wrote: >> Laurent Pinchart wrote: >>> On Saturday 14 January 2012 21:51:31 Sakari Ailus wrote: Laurent Pinchart wrote: > On Tuesday 20 December 2011 21:28:00 Sakari Ailus wrote: >> From: Sakari Ailus >> >> Add image source control class. This control class is intended to >> contain low level controls which deal with control of the image >> capture process --- the A/D converter in image sensors, for example. >> >> Signed-off-by: Sakari Ailus >> --- >> >> Documentation/DocBook/media/v4l/controls.xml | 101 >> + .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml >> | >> >> 6 + >> >> drivers/media/video/v4l2-ctrls.c | 10 ++ >> include/linux/videodev2.h | 10 ++ >> 4 files changed, 127 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..69ede83 >> 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -3356,6 +3356,107 @@ interface and may change in the future. >> >> >> >> >> >> + >> + >> + Image Source Control Reference >> + >> + >> +Experimental >> + >> +This is an > +linkend="experimental">experimental interface and may >> +change in the future. >> + >> + >> + >> +The Image Source control class is intended for low-level >> +control of image source devices such as image sensors. The >> +devices feature an analogue to digital converter and a bus > > Is the V4L2 documentation written in US or UK English ? US uses analog, > UK uses analogue. Analog would be shorter in control names. Both appear to be used, but the US English appears to be more commonly used. I guess it's mostly chosen by whatever happened to be used by the author of the patch. I prefer UK spelling which you might have noticed already. :-) >>> >>> Yes I have. I haven't checked whether V4L2 prefers the UK or US spelling. >>> I'll trust you on that. >> >> I have checked and most seem to have used US spelling. If you wish me to >> change it, I can do that. > > As you (and others) wish. > I remember there was a discussion on this topic years ago within the kernel community but I don't remember how it ended up with... LWN.net appears to remember better than I do, but by a quick check I can't find any definitive conclusion. http://lwn.net/Articles/44262/> http://lkml.org/lkml/2003/8/7/245> >> +transmitter to transmit the image data out of the device. >> + >> + >> + >> + Image Source Control IDs >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> +ID >> +Type >> + > align="left">Description + >> + >> + >> + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_CLASS >> + >> >> class >> >> + >> + >> +The IMAGE_SOURCE class >> descriptor. + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_VBLANK>> + >> >>integer >> >> + >> + >> +Vertical blanking. The idle >> +preriod after every frame during which no image data is > > s/preriod/period/ > >> +produced. The unit of vertical blanking is a line. Every >> +line has length of the image width plus horizontal >> +blanking at the pixel clock specified by struct >> +v4l2_mbus_framefmt > +/>. >> + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_HBLANK>> + >> >>integer >> >> + >> + >> +Horizontal blanking. The idle >> +preriod after every line of image data during which no > > s/preriod/period/ > >> +image data is produced. The unit of horizontal blanking is >> +pixels. >> + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_LINK_FREQ> tr y> + integer menu >> + >> + >> +Image source's data bus frequency. > > What's the frequency unit ? Sample/second ? Hz --- that's the unit of frequen
Re: Hauppage Nova: doesn't know how to handle a DVBv3 call to delivery system 0
On Sun, 2012-01-15 at 17:02 +, razza lists wrote:
> On 15 January 2012 16:22, Gianluca Gennari wrote:
> > Il 15/01/2012 16:04, razza lists ha scritto:
> >> On 15 January 2012 14:24, Mauro Carvalho Chehab wrote:
> >>> Em 15-01-2012 09:51, Gianluca Gennari escreveu:
> Il 15/01/2012 12:35, razza lists ha scritto:
> > On Sat, Jan 14, 2012 at 11:44 PM, Gianluca Gennari
> > wrote:
> >>
> >> Il 15/01/2012 00:41, RazzaList ha scritto:
> >>> I have followed the build instructions for the Hauppauge MyTV.t
> >>> device here
> >>> - http://linuxtv.org/wiki/index.php/Hauppauge_myTV.t and built the
> >>> drivers
> >>> as detailed here -
> >>> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_D
> >>> evice_Drivers on a CentOS 6.2 i386 build.
> >>>
> >>> When I use dvbscan, nothing happens. dmesg shows "
> >>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> >>> delivery system 0"
> >>>
> >>> [root@cos6 ~]# cd /usr/bin
> >>> [root@cos6 bin]# ./dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
> >>> /usr/share/dvb/dvb-t/channels.conf
> >>> [root@cos6 bin]# dmesg | grep dvb
> >>> dvb-usb: found a 'Hauppauge Nova-T MyTV.t' in warm state.
> >>> dvb-usb: will pass the complete MPEG2 transport stream to the software
> >>> demuxer.
> >>> dvb-usb: schedule remote query interval to 50 msecs.
> >>> dvb-usb: Hauppauge Nova-T MyTV.t successfully initialized and
> >>> connected.
> >>> usbcore: registered new interface driver dvb_usb_dib0700
> >>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> >>> delivery system 0
> >>>
> >>> I have searched but can't locate a fix. Any pointers?
> >>>
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe
> >>> linux-media" in
> >>> the body of a message to majord...@vger.kernel.org
> >>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> >> Hi,
> >> this patch will likely fix your problem:
> >>
> >> http://patchwork.linuxtv.org/patch/9492/
> >>
> >> Best regards,
> >> Gianluca
> >
> > It's very likely the case I'm doing something wrong and I apologise in
> > advance! However some help/guidance would be great...
> >
> > I have downloaded the sources as described in the basic approach here
> > -
> > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
> >
> > In the source there is no file called "dvb_frontend.c", so I assume I
> > start the media_build/build script?
> > If I do, eventually this creates
> > media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> >
> > I then apply the patch to
> > media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c, and I can
> > see the added elements...
> >
> > static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
> > {
> > struct dtv_frontend_properties *c = &fe->dtv_property_cache;
> > int i;
> > u32 delsys;
> >
> > delsys = c->delivery_system;
> > memset(c, 0, sizeof(struct dtv_frontend_properties));
> > c->delivery_system = delsys;
> >
> > c->state = DTV_CLEAR;
> >
> > dprintk("%s() Clearing cache for delivery system %d\n",
> > __func__,
> > c->delivery_system);
> >
> >
> > After a reboot (as I have not got a clue about unloading modules etc.)
> > I then execute make install but I still get the same error
> > "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> > delivery system 0" when I use dvbscan.
> >
>
> You are almost there.
> After you apply the patch, you have to recompile the entire source tree.
> You can do it launching the "make" command inside the linux/ folder.
> Then reinstall the drivers giving "make install" from the media_build/
> folder, and reboot.
> >>>
> >>> I've added the fixes for it today. So, tomorrow's tarballs should have
> >>> this
> >>> bug fixed.
> >>>
>
> Best regards,
> Gianluca
> --
> 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
> >>>
> >> I'm glad about that as I am getting nowhere fast. Looks like it's
> >> better to rebuild the box in the week and save wasting your time.
> >> After patching etc, I did manage to get a little bit further, but when
> >> using dvbscan I got an error:
> >>
> >> [root@cos6 bin]# dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
> >> /home/mythtv/channels.conf
> >> Unable to query frontend status
> >
> > According to the dvbscan wik
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote: Em 15-01-2012 18:03, Antti Palosaari escreveu: On 01/15/2012 08:37 PM, Antti Palosaari wrote: On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: On 10-01-2012 19:36, Antti Palosaari wrote: That seems to be due to cxd2820r bug introduced by multi-frontend to single-frontend change. Ok. Could you please fix it and send us a patch? I already sent it and few others too. CXD2820R is still missing HAS_LOCK bit in DVB-C mode... This change introduces too many bugs as I have been fixing those whole day and not even found all yet. But now I got that error: [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device or resource busy while opening /dev/dvb/adapter0/frontend0 Changing delivery system to: DVBC/ANNEX_A Segmentation fault (core dumped) There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit: http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991 OK, will try. Thanks Antti -- http://palosaari.fi/ -- 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: [ANNOUNCE] DVBv5 tools version 0.0.1
Em 15-01-2012 18:03, Antti Palosaari escreveu: > On 01/15/2012 08:37 PM, Antti Palosaari wrote: >> On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: >>> On 10-01-2012 19:36, Antti Palosaari wrote: Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? >> >> I still see that it changes delivery system automatically to the DVB-T. >> >> >> That is the latest commit: >> >> commit 149709f5b8a4a8678401facb5c670119751f6087 >> Author: Mauro Carvalho Chehab >> Date: Fri Jan 13 11:46:36 2012 -0200 >> >> [media] dvb-core: preserve the delivery system at cache clear >> >> The changeset 240ab508aa is incomplete, as the first thing that >> happens at cache clear is to do a memset with 0 to the cache. >> >> So, the delivery system needs to be explicitly preserved there. >> >> Signed-off-by: Mauro Carvalho Chehab >> >> >> And here is log: >> >> [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool >> --set-delsys=DVBC/ANNEX_A >> Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: >> CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 >> CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO >> CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 >> CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO >> DVB API Version 5.5, Current v5 delivery system: DVBT >> Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A >> Changing delivery system to: DVBC/ANNEX_A >> [crope@localhost code]$ scan ../fi-Oulu-c >> scanning ../fi-Oulu-c >> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >> initial transponder 33000 6875000 0 4 >> initial transponder 37000 6875000 0 4 >> initial transponder 36200 6875000 0 4 >> initial transponder 35400 6875000 0 4 >> initial transponder 34600 6875000 0 4 >> initial transponder 33800 6875000 0 4 >> initial transponder 32200 6875000 0 4 >> initial transponder 31400 6875000 0 4 >> initial transponder 37800 6875000 0 4 >> initial transponder 30600 6875000 0 4 >> initial transponder 29800 6875000 0 4 >> initial transponder 29000 6875000 0 5 >> initial transponder 27400 6875000 0 5 >> initial transponder 26600 6875000 0 5 >> initial transponder 25800 6875000 0 5 >> initial transponder 25000 6875000 0 5 >> initial transponder 24200 6875000 0 5 >> >>> tune to: 33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128 >> ^CERROR: interrupted by SIGINT, dumping partial result... >> dumping lists (0 services) >> Done. >> [crope@localhost code]$ scan ../fi-Oulu-c >> scanning ../fi-Oulu-c >> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >> initial transponder 33000 6875000 0 4 >> initial transponder 37000 6875000 0 4 >> initial transponder 36200 6875000 0 4 >> initial transponder 35400 6875000 0 4 >> initial transponder 34600 6875000 0 4 >> initial transponder 33800 6875000 0 4 >> initial transponder 32200 6875000 0 4 >> initial transponder 31400 6875000 0 4 >> initial transponder 37800 6875000 0 4 >> initial transponder 30600 6875000 0 4 >> initial transponder 29800 6875000 0 4 >> initial transponder 29000 6875000 0 5 >> initial transponder 27400 6875000 0 5 >> initial transponder 26600 6875000 0 5 >> initial transponder 25800 6875000 0 5 >> initial transponder 25000 6875000 0 5 >> initial transponder 24200 6875000 0 5 >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> WARNING: frontend type (OFDM) is not compatible with requested tuning >> type (QAM) >> ERROR: initial tuning failed >> dumping lists (0 services
[PATCH] cxd2820r: wait demod lock for DVB-C too
Fix yet another bug introduced be recent cxd2820r multi-frontend to
single-frontend change.
Finally, we have at least almost working picture for DVB-C too.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb/frontends/cxd2820r_core.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c
b/drivers/media/dvb/frontends/cxd2820r_core.c
index b789a90..372a4e7 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -492,6 +492,7 @@ static enum dvbfe_search cxd2820r_search(struct
dvb_frontend *fe)
/* frontend lock wait loop count */
switch (priv->delivery_system) {
case SYS_DVBT:
+ case SYS_DVBC_ANNEX_A:
i = 20;
break;
case SYS_DVBT2:
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove pointless linux/version.h include from drivers/media/dvb/frontends/tda18271c2dd.c
As pointed out by 'make versioncheck', there's no need for drivers/media/dvb/frontends/tda18271c2dd.c to #include , so this patch removes the include. Signed-off-by: Jesper Juhl --- drivers/media/dvb/frontends/tda18271c2dd.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c b/drivers/media/dvb/frontends/tda18271c2dd.c index 1b1bf20..fbd108e 100644 --- a/drivers/media/dvb/frontends/tda18271c2dd.c +++ b/drivers/media/dvb/frontends/tda18271c2dd.c @@ -29,7 +29,6 @@ #include #include #include -#include #include #include "dvb_frontend.h" -- 1.7.8.3 -- Jesper Juhlhttp://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- 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: White Balance Temperature
Laurent Pinchart ideasonboard.com> writes: > > Hi Aurel, > > On Sunday 15 January 2012 11:16:30 Aurel wrote: > > Hi there > > > > my "Live! Cam Socialize HD VF0610", Device ID: 041e:4080, Driver: uvcvideo > > is running perfectly on Fedora 16 Linux, except one thing: > > When I try to switch on "White Balance Temperature, Auto" or just try to > > change "White Balance Temperature" slider I get a failure message and it > > won't work. All other controls, like contrast, gamma, etc. are working. > > "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" produces an > > error message: > > "VIDIOC_S_CTRL: failed: Input/output error > > white_balance_temperature_auto: Input/output error" > > > > As soon as I boot Windows (inside Linux out of a Virtual Box), start the > > camera there and go back to Linux, I am able to adjust and switch on the > > White Balance things in Linux. > > "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" working fine > > after running the camera in Windows. > > > > Everytime I switch off my computer or disconnect the camera, I have to run > > the camera in Windows again, bevor I can adjust White Balance in Linux. > > > > What can I do to get White Balance controls working in Linux, without > > having to run the camera in Windows every time? > > Is there a special command I have to send to the camera for initializing or > > so? > > Not that I know of. If you use the stock UVC driver in Windows, without > having > installed a custom driver for your device, that's quite unlikely. > > Could you dump the value of all controls in Linux before and after booting > Windows ? > Many thanks for your quick reply Laurent! Here are the values before... [aurel@DualCore ~]$ v4l2-ctl -d 1 -L brightness (int): min=-128 max=127 step=1 default=0 value=0 contrast (int): min=64 max=255 step=1 default=128 value=128 saturation (int): min=0 max=255 step=1 default=128 value=128 hue (int): min=-128 max=127 step=1 default=0 value=0 white_balance_temperature_auto (bool) : default=1 value=0 gamma (int): min=72 max=500 step=1 default=100 value=128 gain (int): min=0 max=2 step=1 default=0 value=0 power_line_frequency (menu) : min=0 max=2 default=2 value=1 0: Disabled 1: 50 Hz 2: 60 Hz white_balance_temperature (int): min=2800 max=6500 step=1 default=4600 value=4600 sharpness (int): min=0 max=100 step=1 default=0 value=0 backlight_compensation (int): min=0 max=4 step=1 default=1 value=1 exposure_auto (menu) : min=0 max=3 default=1 value=3 1: Manual Mode 3: Aperture Priority Mode exposure_absolute (int): min=2 max=2 step=1 default=156 value=16777372 [aurel@DualCore ~]$ ...and after Windows... [aurel@DualCore ~]$ v4l2-ctl -d 1 -L brightness (int): min=-128 max=127 step=1 default=0 value=0 contrast (int): min=64 max=255 step=1 default=128 value=128 saturation (int): min=0 max=255 step=1 default=128 value=137 hue (int): min=-128 max=127 step=1 default=0 value=0 white_balance_temperature_auto (bool) : default=1 value=0 gamma (int): min=72 max=500 step=1 default=100 value=100 gain (int): min=0 max=2 step=1 default=0 value=0 power_line_frequency (menu) : min=0 max=2 default=2 value=1 0: Disabled 1: 50 Hz 2: 60 Hz white_balance_temperature (int): min=2800 max=6500 step=1 default=4600 value=4600 sharpness (int): min=0 max=100 step=1 default=0 value=0 backlight_compensation (int): min=0 max=4 step=1 default=1 value=1 exposure_auto (menu) : min=0 max=3 default=1 value=3 1: Manual Mode 3: Aperture Priority Mode exposure_absolute (int): min=2 max=2 step=1 default=156 value=16777372 [aurel@DualCore ~]$ ...not so much difference. And may be I didn't tell right before: I did install the original Live! Central 3 software by Creative in Windows. All I do is just start it and switch off again. The interesting thing here is the "exposure_absolute" value. Much too high, but can also be changed before Windows. Regards Aurel -- 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.ht
[PATCH 2/2] cxd2820r: do not switch to DVB-T when DVB-C fails
Fix another bug introduced by recent multi-frontend to single-frontend change.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb/frontends/cxd2820r_core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c
b/drivers/media/dvb/frontends/cxd2820r_core.c
index 93e1b12..b789a90 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -476,10 +476,10 @@ static enum dvbfe_search cxd2820r_search(struct
dvb_frontend *fe)
dbg("%s: delsys=%d", __func__, fe->dtv_property_cache.delivery_system);
/* switch between DVB-T and DVB-T2 when tune fails */
- if (priv->last_tune_failed && (priv->delivery_system !=
SYS_DVBC_ANNEX_A)) {
+ if (priv->last_tune_failed) {
if (priv->delivery_system == SYS_DVBT)
c->delivery_system = SYS_DVBT2;
- else
+ else if (priv->delivery_system == SYS_DVBT2)
c->delivery_system = SYS_DVBT;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] anysee: do not attach same frontend twice
cxd2820r implements only one frontend currently which
handles all the standards.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb/dvb-usb/anysee.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/anysee.c
b/drivers/media/dvb/dvb-usb/anysee.c
index df46015..ecc3add 100644
--- a/drivers/media/dvb/dvb-usb/anysee.c
+++ b/drivers/media/dvb/dvb-usb/anysee.c
@@ -877,24 +877,18 @@ static int anysee_frontend_attach(struct dvb_usb_adapter
*adap)
case ANYSEE_HW_508T2C: /* 20 */
/* E7 T2C */
+ if (state->fe_id)
+ break;
+
/* enable DVB-T/T2/C demod on IOE[5] */
ret = anysee_wr_reg_mask(adap->dev, REG_IOE, (1 << 5), 0x20);
if (ret)
goto error;
- if (state->fe_id == 0) {
- /* DVB-T/T2 */
- adap->fe_adap[state->fe_id].fe =
- dvb_attach(cxd2820r_attach,
- &anysee_cxd2820r_config,
- &adap->dev->i2c_adap, NULL);
- } else {
- /* DVB-C */
- adap->fe_adap[state->fe_id].fe =
- dvb_attach(cxd2820r_attach,
- &anysee_cxd2820r_config,
- &adap->dev->i2c_adap, adap->fe_adap[0].fe);
- }
+ /* attach demod */
+ adap->fe_adap[state->fe_id].fe = dvb_attach(cxd2820r_attach,
+ &anysee_cxd2820r_config, &adap->dev->i2c_adap,
+ NULL);
state->has_ci = true;
--
1.7.4.4
--
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 08/17] v4l: Image source control class
On 01/15/2012 08:30 PM, Sakari Ailus wrote: > Hi Sylwester, > > Sylwester Nawrocki wrote: >> On 01/14/2012 09:51 PM, Sakari Ailus wrote: > diff --git a/drivers/media/video/v4l2-ctrls.c > b/drivers/media/video/v4l2-ctrls.c index 083bb79..da1ec52 100644 > --- a/drivers/media/video/v4l2-ctrls.c > +++ b/drivers/media/video/v4l2-ctrls.c > @@ -606,6 +606,12 @@ const char *v4l2_ctrl_get_name(u32 id) > case V4L2_CID_FLASH_CHARGE: return "Charge"; > case V4L2_CID_FLASH_READY: return "Ready to > strobe"; > > + case V4L2_CID_IMAGE_SOURCE_CLASS: return "Image source controls"; > + case V4L2_CID_IMAGE_SOURCE_VBLANK: return "Vertical blanking"; > + case V4L2_CID_IMAGE_SOURCE_HBLANK: return "Horizontal blanking"; > + case V4L2_CID_IMAGE_SOURCE_LINK_FREQ: return "Link frequency"; > + case V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN: return "Analogue gain"; Please capitalize each word, as done for the other controls. >>> >>> This isn't done for the flash controls either, have you noticed that? >>> >>> Well, I guess I have to admit that they were added by myself. ;-) >>> >>> I can fix this for the next patchset. >> >> I don't want to be annoying (too much ;)) but the FLASH controls >> documentation >> is missing some tags in the text. Other classes use them for >> standard identifiers. > > Thanks for letting me know --- that could be fixed with the flash timing > control API, or unrelated to that. We should btw. continue discussion on > that one. :-) Sure, I remember having a patch for that style correction somewhere around. Certainly the Flash topic needs continuation, I'll get back to it shortly. I just need to do some more research about it and it is not of really high priority on my side now. Plus I have temporarily been out of order for the last week.. I have just prepared an auto focus controls draft patch. I'll post it hopefully tonight to move things forward. > Speaking of things to do... The colour of the object to point and press > V4L2_CID_DO_WHITE_BALANCE (or what was it called) to fix the white > balance --- is that white, gray, something else or implementation > dependent? I vaguely remember having seen some grayish plates being used > for that but I'm definitely not sure. :-) Any idea? As far as I know it should be always an object which is perceived as white. Something else don't seem to be terribly useful to set up white balance. Unfortunately I don't have much of experience with that yet. -- Regards, Sylwester -- 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: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/15/2012 08:37 PM, Antti Palosaari wrote: On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: On 10-01-2012 19:36, Antti Palosaari wrote: Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? I still see that it changes delivery system automatically to the DVB-T. That is the latest commit: commit 149709f5b8a4a8678401facb5c670119751f6087 Author: Mauro Carvalho Chehab Date: Fri Jan 13 11:46:36 2012 -0200 [media] dvb-core: preserve the delivery system at cache clear The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache. So, the delivery system needs to be explicitly preserved there. Signed-off-by: Mauro Carvalho Chehab And here is log: [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 >>> tune to: 33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128 ^CERROR: interrupted by SIGINT, dumping partial result... dumping lists (0 services) Done. [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) ERROR: initial tuning failed dumping lists (0 services) Done. [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CA
Re: [RFC 08/17] v4l: Image source control class
Hi Sakari, On Sunday 15 January 2012 20:44:02 Sakari Ailus wrote: > Laurent Pinchart wrote: > > On Saturday 14 January 2012 21:51:31 Sakari Ailus wrote: > >> Laurent Pinchart wrote: > >>> On Tuesday 20 December 2011 21:28:00 Sakari Ailus wrote: > From: Sakari Ailus > > Add image source control class. This control class is intended to > contain low level controls which deal with control of the image > capture process --- the A/D converter in image sensors, for example. > > Signed-off-by: Sakari Ailus > --- > > Documentation/DocBook/media/v4l/controls.xml | 101 > + .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml > | > > 6 + > > drivers/media/video/v4l2-ctrls.c | 10 ++ > include/linux/videodev2.h | 10 ++ > 4 files changed, 127 insertions(+), 0 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..69ede83 > 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -3356,6 +3356,107 @@ interface and may change in the future. > > > > > > + > + > + Image Source Control Reference > + > + > +Experimental > + > +This is an +linkend="experimental">experimental interface and may > +change in the future. > + > + > + > +The Image Source control class is intended for low-level > +control of image source devices such as image sensors. The > +devices feature an analogue to digital converter and a bus > >>> > >>> Is the V4L2 documentation written in US or UK English ? US uses analog, > >>> UK uses analogue. Analog would be shorter in control names. > >> > >> Both appear to be used, but the US English appears to be more commonly > >> used. I guess it's mostly chosen by whatever happened to be used by the > >> author of the patch. I prefer UK spelling which you might have noticed > >> already. :-) > > > > Yes I have. I haven't checked whether V4L2 prefers the UK or US spelling. > > I'll trust you on that. > > I have checked and most seem to have used US spelling. If you wish me to > change it, I can do that. As you (and others) wish. > >> I remember there was a discussion on this topic years ago within the > >> kernel community but I don't remember how it ended up with... LWN.net > >> appears to remember better than I do, but by a quick check I can't find > >> any definitive conclusion. > >> > >> http://lwn.net/Articles/44262/> > >> http://lkml.org/lkml/2003/8/7/245> > >> > +transmitter to transmit the image data out of the device. > + > + > + > + Image Source Control IDs > + > + > + > + > + > + > + > + > + > + > +ID > +Type > + align="left">Description + > + > + > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_CLASS > + > > class > > + > + > +The IMAGE_SOURCE class > descriptor. + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_VBLANK > + > > integer > > + > + > +Vertical blanking. The idle > +preriod after every frame during which no image data is > >>> > >>> s/preriod/period/ > >>> > +produced. The unit of vertical blanking is a line. Every > +line has length of the image width plus horizontal > +blanking at the pixel clock specified by struct > +v4l2_mbus_framefmt +/>. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_HBLANK > + > > integer > > + > + > +Horizontal blanking. The idle > +preriod after every line of image data during which no > >>> > >>> s/preriod/period/ > >>> > +image data is produced. The unit of horizontal blanking is > +pixels. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_LINK_FREQ tr y> + integer menu > + > + > +Image source's data bus frequency. > >>> > >>> What's the frequency unit ? Sample/second ? > >> > >> Hz --- that's the unit of frequency. I fixed
Re: [RFC 08/17] v4l: Image source control class
Hi Laurent, Laurent Pinchart wrote: > On Saturday 14 January 2012 21:51:31 Sakari Ailus wrote: >> Laurent Pinchart wrote: >>> On Tuesday 20 December 2011 21:28:00 Sakari Ailus wrote: From: Sakari Ailus Add image source control class. This control class is intended to contain low level controls which deal with control of the image capture process --- the A/D converter in image sensors, for example. Signed-off-by: Sakari Ailus --- Documentation/DocBook/media/v4l/controls.xml | 101 + .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml | 6 + drivers/media/video/v4l2-ctrls.c | 10 ++ include/linux/videodev2.h | 10 ++ 4 files changed, 127 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..69ede83 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3356,6 +3356,107 @@ interface and may change in the future. + + + Image Source Control Reference + + + Experimental + + This is an >>> + linkend="experimental">experimental interface and may + change in the future. + + + + The Image Source control class is intended for low-level + control of image source devices such as image sensors. The + devices feature an analogue to digital converter and a bus >>> >>> Is the V4L2 documentation written in US or UK English ? US uses analog, >>> UK uses analogue. Analog would be shorter in control names. >> >> Both appear to be used, but the US English appears to be more commonly >> used. I guess it's mostly chosen by whatever happened to be used by the >> author of the patch. I prefer UK spelling which you might have noticed >> already. :-) > > Yes I have. I haven't checked whether V4L2 prefers the UK or US spelling. > I'll > trust you on that. I have checked and most seem to have used US spelling. If you wish me to change it, I can do that. >> I remember there was a discussion on this topic years ago within the >> kernel community but I don't remember how it ended up with... LWN.net >> appears to remember better than I do, but by a quick check I can't find >> any definitive conclusion. >> >> http://lwn.net/Articles/44262/> >> http://lkml.org/lkml/2003/8/7/245> >> + transmitter to transmit the image data out of the device. + + + + Image Source Control IDs + + + + + + + + + + + ID + Type +>>> align="left">Description + + + + + + >>> spanname="id">V4L2_CID_IMAGE_SOURCE_CLASS + class + + + The IMAGE_SOURCE class descriptor. + + + >>> spanname="id">V4L2_CID_IMAGE_SOURCE_VBLANK + integer + + + Vertical blanking. The idle + preriod after every frame during which no image data is >>> >>> s/preriod/period/ >>> + produced. The unit of vertical blanking is a line. Every + line has length of the image width plus horizontal + blanking at the pixel clock specified by struct + v4l2_mbus_framefmt >>> + />. + + + >>> spanname="id">V4L2_CID_IMAGE_SOURCE_HBLANK + integer + + + Horizontal blanking. The idle + preriod after every line of image data during which no >>> >>> s/preriod/period/ >>> + image data is produced. The unit of horizontal blanking is + pixels. + + + >>> spanname="id">V4L2_CID_IMAGE_SOURCE_LINK_FREQ>>> y> + integer menu + + + Image source's data bus frequency. >>> >>> What's the frequency unit ? Sample/second ? >> >> Hz --- that's the unit of frequency. I fixed that in the new version. > > Is the user supposed to compute the pixel clock from this information ? > That's > what the text below seems to imply. Apparently I have forgotten to update this in the new patchset. But yes, these factors do define it. The sensors' internal clock tree will be involved and calculation is non-trivial. This is why we also have the PIXEL_RATE control --- where I will refer to in the next patchset. + Together with the media bus pixel code, bus type (clock + cycles per sample), the data bus frequency defines the + pixel clock. The + frame rate can be calculated from the pixel clock, image + width and height and horizontal and vertical blanking. The + fram
Re: [RFC 08/17] v4l: Image source control class
Hi Sylwester, Sylwester Nawrocki wrote: > On 01/14/2012 09:51 PM, Sakari Ailus wrote: diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 083bb79..da1ec52 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -606,6 +606,12 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_FLASH_CHARGE: return "Charge"; case V4L2_CID_FLASH_READY: return "Ready to strobe"; + case V4L2_CID_IMAGE_SOURCE_CLASS: return "Image source controls"; + case V4L2_CID_IMAGE_SOURCE_VBLANK: return "Vertical blanking"; + case V4L2_CID_IMAGE_SOURCE_HBLANK: return "Horizontal blanking"; + case V4L2_CID_IMAGE_SOURCE_LINK_FREQ: return "Link frequency"; + case V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN: return "Analogue gain"; >>> >>> Please capitalize each word, as done for the other controls. >> >> This isn't done for the flash controls either, have you noticed that? >> >> Well, I guess I have to admit that they were added by myself. ;-) >> >> I can fix this for the next patchset. > > I don't want to be annoying (too much ;)) but the FLASH controls documentation > is missing some tags in the text. Other classes use them for > standard identifiers. Thanks for letting me know --- that could be fixed with the flash timing control API, or unrelated to that. We should btw. continue discussion on that one. :-) Speaking of things to do... The colour of the object to point and press V4L2_CID_DO_WHITE_BALANCE (or what was it called) to fix the white balance --- is that white, gray, something else or implementation dependent? I vaguely remember having seen some grayish plates being used for that but I'm definitely not sure. :-) Any idea? Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[PULL] git://linuxtv.org/mkrufky/tuners LEDs | Add Support for LED feedback on WinTV Nova-TD / WinTV Duet
Mauro, Please pull from the LEDs branch on my tuners tree for patches that add support for LED signal lock feedback on WinTV Nova-TD / WinTV Duet The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610: Linus Torvalds (1): Linux 3.2 are available in the git repository at: git://linuxtv.org/mkrufky/tuners LEDs Jiri Slaby (4): DVB: dib0700, move Nova-TD Stick to a separate set DVB: dib0700, separate stk7070pd initialization DVB: dib0700, add corrected Nova-TD frontend_attach DVB: dib0700, add support for Nova-TD LEDs drivers/media/dvb/dvb-usb/dib0700.h |2 + drivers/media/dvb/dvb-usb/dib0700_devices.c | 150 --- 2 files changed, 139 insertions(+), 13 deletions(-) Cheers, 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
[PATCH FOR 3.3] cxd2820r: do not switch to DVB-T when DVB-C fails
Fix another bug introduced by recent multi-frontend to single-frontend
change.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb/frontends/cxd2820r_core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c
b/drivers/media/dvb/frontends/cxd2820r_core.c
index 93e1b12..b789a90 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -476,10 +476,10 @@ static enum dvbfe_search cxd2820r_search(struct
dvb_frontend *fe)
dbg("%s: delsys=%d", __func__, fe->dtv_property_cache.delivery_system);
/* switch between DVB-T and DVB-T2 when tune fails */
- if (priv->last_tune_failed && (priv->delivery_system !=
SYS_DVBC_ANNEX_A)) {
+ if (priv->last_tune_failed) {
if (priv->delivery_system == SYS_DVBT)
c->delivery_system = SYS_DVBT2;
- else
+ else if (priv->delivery_system == SYS_DVBT2)
c->delivery_system = SYS_DVBT;
}
--
1.7.4.4
--
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: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Jan 15 19:00:22 CET 2012 git hash:149709f5b8a4a8678401facb5c670119751f6087 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: On 10-01-2012 19:36, Antti Palosaari wrote: Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? I still see that it changes delivery system automatically to the DVB-T. That is the latest commit: commit 149709f5b8a4a8678401facb5c670119751f6087 Author: Mauro Carvalho Chehab Date: Fri Jan 13 11:46:36 2012 -0200 [media] dvb-core: preserve the delivery system at cache clear The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache. So, the delivery system needs to be explicitly preserved there. Signed-off-by: Mauro Carvalho Chehab And here is log: [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 >>> tune to: 33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128 ^CERROR: interrupted by SIGINT, dumping partial result... dumping lists (0 services) Done. [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) ERROR: initial tuning failed dumping lists (0 services) Done. [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AU
[PATCH FOR 3.3] anysee: do not attach same frontend twice
cxd2820r implements only one frontend currently which
handles all the standards.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb/dvb-usb/anysee.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/anysee.c
b/drivers/media/dvb/dvb-usb/anysee.c
index df46015..ecc3add 100644
--- a/drivers/media/dvb/dvb-usb/anysee.c
+++ b/drivers/media/dvb/dvb-usb/anysee.c
@@ -877,24 +877,18 @@ static int anysee_frontend_attach(struct
dvb_usb_adapter *adap)
case ANYSEE_HW_508T2C: /* 20 */
/* E7 T2C */
+ if (state->fe_id)
+ break;
+
/* enable DVB-T/T2/C demod on IOE[5] */
ret = anysee_wr_reg_mask(adap->dev, REG_IOE, (1 << 5), 0x20);
if (ret)
goto error;
- if (state->fe_id == 0) {
- /* DVB-T/T2 */
- adap->fe_adap[state->fe_id].fe =
- dvb_attach(cxd2820r_attach,
- &anysee_cxd2820r_config,
- &adap->dev->i2c_adap, NULL);
- } else {
- /* DVB-C */
- adap->fe_adap[state->fe_id].fe =
- dvb_attach(cxd2820r_attach,
- &anysee_cxd2820r_config,
- &adap->dev->i2c_adap, adap->fe_adap[0].fe);
- }
+ /* attach demod */
+ adap->fe_adap[state->fe_id].fe = dvb_attach(cxd2820r_attach,
+ &anysee_cxd2820r_config, &adap->dev->i2c_adap,
+ NULL);
state->has_ci = true;
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] uvcvideo: Implement compat_ioctl32 for custom ioctls
Support 32-bit/64-bit compatibility for the the UVCIOC_ ioctls.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/uvc/uvc_v4l2.c | 205
1 files changed, 205 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index f09ee8b..73ae152 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -11,6 +11,7 @@
*
*/
+#include
#include
#include
#include
@@ -1030,6 +1031,207 @@ static long uvc_v4l2_ioctl(struct file *file,
return video_usercopy(file, cmd, arg, uvc_v4l2_do_ioctl);
}
+#ifdef CONFIG_COMPAT
+struct uvc_xu_control_mapping32 {
+ __u32 id;
+ __u8 name[32];
+ __u8 entity[16];
+ __u8 selector;
+
+ __u8 size;
+ __u8 offset;
+ __u32 v4l2_type;
+ __u32 data_type;
+
+ compat_caddr_t menu_info;
+ __u32 menu_count;
+
+ __u32 reserved[4];
+};
+
+static int uvc_v4l2_get_xu_mapping(struct uvc_xu_control_mapping *kp,
+ const struct uvc_xu_control_mapping32 __user *up)
+{
+ struct uvc_menu_info __user *umenus;
+ struct uvc_menu_info __user *kmenus;
+ compat_caddr_t p;
+
+ if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
+ __copy_from_user(kp, up, offsetof(typeof(*up), menu_info)) ||
+ __get_user(kp->menu_count, &up->menu_count))
+ return -EFAULT;
+
+ memset(kp->reserved, 0, sizeof(kp->reserved));
+
+ if (kp->menu_count == 0) {
+ kp->menu_info = NULL;
+ return 0;
+ }
+
+ if (__get_user(p, &up->menu_info))
+ return -EFAULT;
+ umenus = compat_ptr(p);
+ if (!access_ok(VERIFY_READ, umenus, kp->menu_count * sizeof(*umenus)))
+ return -EFAULT;
+
+ kmenus = compat_alloc_user_space(kp->menu_count * sizeof(*kmenus));
+ if (kmenus == NULL)
+ return -EFAULT;
+ kp->menu_info = kmenus;
+
+ if (copy_in_user(kmenus, umenus, kp->menu_count * sizeof(*umenus)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int uvc_v4l2_put_xu_mapping(const struct uvc_xu_control_mapping *kp,
+ struct uvc_xu_control_mapping32 __user *up)
+{
+ struct uvc_menu_info __user *umenus;
+ struct uvc_menu_info __user *kmenus = kp->menu_info;
+ compat_caddr_t p;
+
+ if (!access_ok(VERIFY_WRITE, up, sizeof(*up)) ||
+ __copy_to_user(up, kp, offsetof(typeof(*up), menu_info)) ||
+ __put_user(kp->menu_count, &up->menu_count))
+ return -EFAULT;
+
+ __clear_user(up->reserved, sizeof(up->reserved));
+
+ if (kp->menu_count == 0)
+ return 0;
+
+ if (get_user(p, &up->menu_info))
+ return -EFAULT;
+ umenus = compat_ptr(p);
+ if (!access_ok(VERIFY_WRITE, umenus, kp->menu_count * sizeof(*umenus)))
+ return -EFAULT;
+
+ if (copy_in_user(umenus, kmenus, kp->menu_count * sizeof(*umenus)))
+ return -EFAULT;
+
+ return 0;
+}
+
+struct uvc_xu_control_query32 {
+ __u8 unit;
+ __u8 selector;
+ __u8 query;
+ __u16 size;
+ compat_caddr_t data;
+};
+
+static int uvc_v4l2_get_xu_query(struct uvc_xu_control_query *kp,
+ const struct uvc_xu_control_query32 __user *up)
+{
+ u8 __user *udata;
+ u8 __user *kdata;
+ compat_caddr_t p;
+
+ if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
+ __copy_from_user(kp, up, offsetof(typeof(*up), data)))
+ return -EFAULT;
+
+ if (kp->size == 0) {
+ kp->data = NULL;
+ return 0;
+ }
+
+ if (__get_user(p, &up->data))
+ return -EFAULT;
+ udata = compat_ptr(p);
+ if (!access_ok(VERIFY_READ, udata, kp->size))
+ return -EFAULT;
+
+ kdata = compat_alloc_user_space(kp->size);
+ if (kdata == NULL)
+ return -EFAULT;
+ kp->data = kdata;
+
+ if (copy_in_user(kdata, udata, kp->size))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int uvc_v4l2_put_xu_query(const struct uvc_xu_control_query *kp,
+ struct uvc_xu_control_query32 __user *up)
+{
+ u8 __user *udata;
+ u8 __user *kdata = kp->data;
+ compat_caddr_t p;
+
+ if (!access_ok(VERIFY_WRITE, up, sizeof(*up)) ||
+ __copy_to_user(up, kp, offsetof(typeof(*up), data)))
+ return -EFAULT;
+
+ if (kp->size == 0)
+ return 0;
+
+ if (get_user(p, &up->data))
+ return -EFAULT;
+ udata = compat_ptr(p);
+ if (!access_ok(VERIFY_READ, udata, kp->size))
+ return -EFAULT;
+
+ if (copy_in_user(udata, kdata, kp->size))
+ return -EFAULT;
+
+ return 0;
+}
+
+#define UVCIOC_CTRL_MAP32 _IOWR('u', 0x20, struct
uvc_xu
[PATCH v3 2/3] uvcvideo: Return -ENOTTY in case of unknown ioctl
-EINVAL is the wrong error code in that case, replace it with -ENOTTY. Signed-off-by: Laurent Pinchart Reviewed-by: Hans Verkuil --- drivers/media/video/uvc/uvc_v4l2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/uvc/uvc_v4l2.c b/drivers/media/video/uvc/uvc_v4l2.c index 2ae4f88..f09ee8b 100644 --- a/drivers/media/video/uvc/uvc_v4l2.c +++ b/drivers/media/video/uvc/uvc_v4l2.c @@ -1012,7 +1012,7 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, void *arg) default: uvc_trace(UVC_TRACE_IOCTL, "Unknown ioctl 0x%08x\n", cmd); - return -EINVAL; + return -ENOTTY; } return ret; -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] v4l: Add custom compat_ioctl32 operation
Drivers implementing custom ioctls need to handle 32-bit/64-bit
compatibility themselves. Provide them with a way to do so.
To avoid circular module dependencies, merge the v4l2-compat-ioctl32
module into videodev. There is no point in keeping them separate, as the
v4l2_compat_ioctl32() function is required by videodev if CONFIG_COMPAT
is set anyway.
Signed-off-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
---
drivers/media/video/Makefile |7 +++
drivers/media/video/v4l2-compat-ioctl32.c | 20 +++-
include/media/v4l2-dev.h |3 +++
3 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 3541388..9f33a95 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -12,14 +12,13 @@ omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
+ifeq ($(CONFIG_COMPAT),y)
+ videodev-objs += v4l2-compat-ioctl32.o
+endif
# V4L2 core modules
obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o
-ifeq ($(CONFIG_COMPAT),y)
- obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o
-endif
-
obj-$(CONFIG_VIDEO_V4L2_COMMON) += v4l2-common.o
# All i2c modules must come first:
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index af4419e..06328fa 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -14,12 +14,11 @@
*/
#include
-#include
#include
+#include
+#include
#include
-#ifdef CONFIG_COMPAT
-
static long native_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
{
long ret = -ENOIOCTLCMD;
@@ -937,6 +936,7 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
long v4l2_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long
arg)
{
+ struct video_device *vdev = video_devdata(file);
long ret = -ENOIOCTLCMD;
if (!file->f_op->unlocked_ioctl)
@@ -1025,14 +1025,16 @@ long v4l2_compat_ioctl32(struct file *file, unsigned
int cmd, unsigned long arg)
break;
default:
- printk(KERN_WARNING "compat_ioctl32: "
- "unknown ioctl '%c', dir=%d, #%d (0x%08x)\n",
- _IOC_TYPE(cmd), _IOC_DIR(cmd), _IOC_NR(cmd), cmd);
+ if (vdev->fops->compat_ioctl32)
+ ret = vdev->fops->compat_ioctl32(file, cmd, arg);
+
+ if (ret == -ENOIOCTLCMD)
+ printk(KERN_WARNING "compat_ioctl32: "
+ "unknown ioctl '%c', dir=%d, #%d (0x%08x)\n",
+ _IOC_TYPE(cmd), _IOC_DIR(cmd), _IOC_NR(cmd),
+ cmd);
break;
}
return ret;
}
EXPORT_SYMBOL_GPL(v4l2_compat_ioctl32);
-#endif
-
-MODULE_LICENSE("GPL");
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index c7c40f1..96d2221 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -62,6 +62,9 @@ struct v4l2_file_operations {
unsigned int (*poll) (struct file *, struct poll_table_struct *);
long (*ioctl) (struct file *, unsigned int, unsigned long);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
+#ifdef CONFIG_COMPAT
+ long (*compat_ioctl32) (struct file *, unsigned int, unsigned long);
+#endif
unsigned long (*get_unmapped_area) (struct file *, unsigned long,
unsigned long, unsigned long, unsigned long);
int (*mmap) (struct file *, struct vm_area_struct *);
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] compat_ioctl32 support for custom ioctls
Hi everybody, Here's the third version of the compat_ioctl32 support for V4L2 custom ioctls support. Compared to v2, the v4l2-compat-ioctl32 module has been merged into videodev to avoid circular modules dependencies (and also because having two separate modules didn't make much sense). Laurent Pinchart (3): v4l: Add custom compat_ioctl32 operation uvcvideo: Return -ENOTTY in case of unknown ioctl uvcvideo: Implement compat_ioctl32 for custom ioctls drivers/media/video/Makefile |7 +- drivers/media/video/uvc/uvc_v4l2.c| 207 - drivers/media/video/v4l2-compat-ioctl32.c | 20 ++-- include/media/v4l2-dev.h |3 + 4 files changed, 223 insertions(+), 14 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: White Balance Temperature
Hi Aurel, On Sunday 15 January 2012 11:16:30 Aurel wrote: > Hi there > > my "Live! Cam Socialize HD VF0610", Device ID: 041e:4080, Driver: uvcvideo > is running perfectly on Fedora 16 Linux, except one thing: > When I try to switch on "White Balance Temperature, Auto" or just try to > change "White Balance Temperature" slider I get a failure message and it > won't work. All other controls, like contrast, gamma, etc. are working. > "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" produces an > error message: > "VIDIOC_S_CTRL: failed: Input/output error > white_balance_temperature_auto: Input/output error" > > As soon as I boot Windows (inside Linux out of a Virtual Box), start the > camera there and go back to Linux, I am able to adjust and switch on the > White Balance things in Linux. > "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" working fine > after running the camera in Windows. > > Everytime I switch off my computer or disconnect the camera, I have to run > the camera in Windows again, bevor I can adjust White Balance in Linux. > > What can I do to get White Balance controls working in Linux, without > having to run the camera in Windows every time? > Is there a special command I have to send to the camera for initializing or > so? Not that I know of. If you use the stock UVC driver in Windows, without having installed a custom driver for your device, that's quite unlikely. Could you dump the value of all controls in Linux before and after booting Windows ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH FOR v3.3] uvcvideo: Avoid division by 0 in timestamp calculation
Use system timestamps if the timestamp can't be computed from the data sent by the device. Signed-off-by: Laurent Pinchart --- drivers/media/video/uvc/uvc_video.c | 14 +- 1 files changed, 9 insertions(+), 5 deletions(-) This patches fixes a kernel division by 0 introduced in v3.3. I'll send a pull request for v3.3-rc in a couple of days if there's no comment. diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c index c7e69b8..4a44f9a 100644 --- a/drivers/media/video/uvc/uvc_video.c +++ b/drivers/media/video/uvc/uvc_video.c @@ -611,9 +611,11 @@ void uvc_video_clock_update(struct uvc_streaming *stream, delta_stc = buf->pts - (1UL << 31); x1 = first->dev_stc - delta_stc; x2 = last->dev_stc - delta_stc; + if (x1 == x2) + goto done; + y1 = (first->dev_sof + 2048) << 16; y2 = (last->dev_sof + 2048) << 16; - if (y2 < y1) y2 += 2048 << 16; @@ -631,14 +633,16 @@ void uvc_video_clock_update(struct uvc_streaming *stream, x1, x2, y1, y2, clock->sof_offset); /* Second step, SOF to host clock conversion. */ - ts = timespec_sub(last->host_ts, first->host_ts); x1 = (uvc_video_clock_host_sof(first) + 2048) << 16; x2 = (uvc_video_clock_host_sof(last) + 2048) << 16; - y1 = NSEC_PER_SEC; - y2 = (ts.tv_sec + 1) * NSEC_PER_SEC + ts.tv_nsec; - if (x2 < x1) x2 += 2048 << 16; + if (x1 == x2) + goto done; + + ts = timespec_sub(last->host_ts, first->host_ts); + y1 = NSEC_PER_SEC; + y2 = (ts.tv_sec + 1) * NSEC_PER_SEC + ts.tv_nsec; /* Interpolated and host SOF timestamps can wrap around at slightly * different times. Handle this by adding or removing 2048 to or from -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-ctl PATCH 1/1] libmediactl: Implement MEDIA_ENT_ID_FLAG_NEXT in media_get_entity_by_id()
Hi Sakari,
On Sunday 15 January 2012 16:40:56 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Saturday 14 January 2012 20:33:36 Sakari Ailus wrote:
> >> Signed-off-by: Sakari Ailus
> >> ---
> >>
> >> src/mediactl.c |9 +++--
> >> src/mediactl.h |4 +++-
> >> 2 files changed, 10 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/mediactl.c b/src/mediactl.c
> >> index 5b8c587..f62fcdf 100644
> >> --- a/src/mediactl.c
> >> +++ b/src/mediactl.c
> >> @@ -81,8 +81,13 @@ struct media_entity *media_get_entity_by_id(struct
> >> media_device *media, for (i = 0; i< media->entities_count; ++i) {
> >>
> >>struct media_entity *entity =&media->entities[i];
> >>
> >> - if (entity->info.id == id)
> >> - return entity;
> >> + if (!(id& MEDIA_ENT_ID_FLAG_NEXT)) {
> >> + if (entity->info.id == id)
> >> + return entity;
> >> + } else {
> >> + if (entity->info.id>= (id& ~MEDIA_ENT_ID_FLAG_NEXT)
> >> + return entity;
> >> + }
> >
> > Just one question that hasn't crossed my mind before, why do you need
> > this ? If you want to enumerate entities in an application you can just
> > iterate over media_device::entities.
>
> We do have the MEDIA_ENT_ID_FLAG_NEXT flag which is intended to help in
> entity enumeration. Currently the range of entity ids is contiguous in
> all practical implementation but will that always be the case, also in
> the future? A few things might break in the kernel if the range is
> non-contiguous as well, but that's still internal to the kernel.
>
> However, this is a user space library and if this interface change is
> not made, we essentially are making a promise that the entity ranges
> will always be contiguous.
I definitely don't want to make that promise, but what's the point in calling
media_get_entity_by_id() for entity enumeration instead of iterating over the
media_device::entities array ?
> I wouldn't as there's no need to do so.
>
> I you think about programmable hardware, entities there are logical
> rather than physical and their existence may be dependent on multiple
> factors.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage Nova: doesn't know how to handle a DVBv3 call to delivery system 0
On 15 January 2012 16:22, Gianluca Gennari wrote:
> Il 15/01/2012 16:04, razza lists ha scritto:
>> On 15 January 2012 14:24, Mauro Carvalho Chehab wrote:
>>> Em 15-01-2012 09:51, Gianluca Gennari escreveu:
Il 15/01/2012 12:35, razza lists ha scritto:
> On Sat, Jan 14, 2012 at 11:44 PM, Gianluca Gennari
> wrote:
>>
>> Il 15/01/2012 00:41, RazzaList ha scritto:
>>> I have followed the build instructions for the Hauppauge MyTV.t device
>>> here
>>> - http://linuxtv.org/wiki/index.php/Hauppauge_myTV.t and built the
>>> drivers
>>> as detailed here -
>>> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_D
>>> evice_Drivers on a CentOS 6.2 i386 build.
>>>
>>> When I use dvbscan, nothing happens. dmesg shows "
>>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>>> delivery system 0"
>>>
>>> [root@cos6 ~]# cd /usr/bin
>>> [root@cos6 bin]# ./dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
>>> /usr/share/dvb/dvb-t/channels.conf
>>> [root@cos6 bin]# dmesg | grep dvb
>>> dvb-usb: found a 'Hauppauge Nova-T MyTV.t' in warm state.
>>> dvb-usb: will pass the complete MPEG2 transport stream to the software
>>> demuxer.
>>> dvb-usb: schedule remote query interval to 50 msecs.
>>> dvb-usb: Hauppauge Nova-T MyTV.t successfully initialized and connected.
>>> usbcore: registered new interface driver dvb_usb_dib0700
>>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>>> delivery system 0
>>>
>>> I have searched but can't locate a fix. Any pointers?
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media"
>>> in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Hi,
>> this patch will likely fix your problem:
>>
>> http://patchwork.linuxtv.org/patch/9492/
>>
>> Best regards,
>> Gianluca
>
> It's very likely the case I'm doing something wrong and I apologise in
> advance! However some help/guidance would be great...
>
> I have downloaded the sources as described in the basic approach here
> -
> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
>
> In the source there is no file called "dvb_frontend.c", so I assume I
> start the media_build/build script?
> If I do, eventually this creates
> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
>
> I then apply the patch to
> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c, and I can
> see the added elements...
>
> static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
> {
> struct dtv_frontend_properties *c = &fe->dtv_property_cache;
> int i;
> u32 delsys;
>
> delsys = c->delivery_system;
> memset(c, 0, sizeof(struct dtv_frontend_properties));
> c->delivery_system = delsys;
>
> c->state = DTV_CLEAR;
>
> dprintk("%s() Clearing cache for delivery system %d\n", __func__,
> c->delivery_system);
>
>
> After a reboot (as I have not got a clue about unloading modules etc.)
> I then execute make install but I still get the same error
> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> delivery system 0" when I use dvbscan.
>
You are almost there.
After you apply the patch, you have to recompile the entire source tree.
You can do it launching the "make" command inside the linux/ folder.
Then reinstall the drivers giving "make install" from the media_build/
folder, and reboot.
>>>
>>> I've added the fixes for it today. So, tomorrow's tarballs should have this
>>> bug fixed.
>>>
Best regards,
Gianluca
--
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
>>>
>> I'm glad about that as I am getting nowhere fast. Looks like it's
>> better to rebuild the box in the week and save wasting your time.
>> After patching etc, I did manage to get a little bit further, but when
>> using dvbscan I got an error:
>>
>> [root@cos6 bin]# dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
>> /home/mythtv/channels.conf
>> Unable to query frontend status
>
> According to the dvbscan wiki page:
>
> http://linuxtv.org/wiki/index.php/Dvbscan
>
> if you get this error you should try other scanning utilities, like scan
> or w_scan. You can also try a real application, like Kaffeine.
>
> Best regards,
> Gianluca
>
>>
>> Dmesg output:
>> usb 1-3: new high speed USB device using ehci_hcd and address 2
>
Re: Hauppage Nova: doesn't know how to handle a DVBv3 call to delivery system 0
Il 15/01/2012 16:04, razza lists ha scritto:
> On 15 January 2012 14:24, Mauro Carvalho Chehab wrote:
>> Em 15-01-2012 09:51, Gianluca Gennari escreveu:
>>> Il 15/01/2012 12:35, razza lists ha scritto:
On Sat, Jan 14, 2012 at 11:44 PM, Gianluca Gennari
wrote:
>
> Il 15/01/2012 00:41, RazzaList ha scritto:
>> I have followed the build instructions for the Hauppauge MyTV.t device
>> here
>> - http://linuxtv.org/wiki/index.php/Hauppauge_myTV.t and built the
>> drivers
>> as detailed here -
>> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_D
>> evice_Drivers on a CentOS 6.2 i386 build.
>>
>> When I use dvbscan, nothing happens. dmesg shows "
>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>> delivery system 0"
>>
>> [root@cos6 ~]# cd /usr/bin
>> [root@cos6 bin]# ./dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
>> /usr/share/dvb/dvb-t/channels.conf
>> [root@cos6 bin]# dmesg | grep dvb
>> dvb-usb: found a 'Hauppauge Nova-T MyTV.t' in warm state.
>> dvb-usb: will pass the complete MPEG2 transport stream to the software
>> demuxer.
>> dvb-usb: schedule remote query interval to 50 msecs.
>> dvb-usb: Hauppauge Nova-T MyTV.t successfully initialized and connected.
>> usbcore: registered new interface driver dvb_usb_dib0700
>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>> delivery system 0
>>
>> I have searched but can't locate a fix. Any pointers?
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>
>
> Hi,
> this patch will likely fix your problem:
>
> http://patchwork.linuxtv.org/patch/9492/
>
> Best regards,
> Gianluca
It's very likely the case I'm doing something wrong and I apologise in
advance! However some help/guidance would be great...
I have downloaded the sources as described in the basic approach here
-
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
In the source there is no file called "dvb_frontend.c", so I assume I
start the media_build/build script?
If I do, eventually this creates
media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
I then apply the patch to
media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c, and I can
see the added elements...
static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int i;
u32 delsys;
delsys = c->delivery_system;
memset(c, 0, sizeof(struct dtv_frontend_properties));
c->delivery_system = delsys;
c->state = DTV_CLEAR;
dprintk("%s() Clearing cache for delivery system %d\n", __func__,
c->delivery_system);
After a reboot (as I have not got a clue about unloading modules etc.)
I then execute make install but I still get the same error
"dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
delivery system 0" when I use dvbscan.
>>>
>>> You are almost there.
>>> After you apply the patch, you have to recompile the entire source tree.
>>> You can do it launching the "make" command inside the linux/ folder.
>>> Then reinstall the drivers giving "make install" from the media_build/
>>> folder, and reboot.
>>
>> I've added the fixes for it today. So, tomorrow's tarballs should have this
>> bug fixed.
>>
>>>
>>> Best regards,
>>> Gianluca
>>> --
>>> 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
>>
> I'm glad about that as I am getting nowhere fast. Looks like it's
> better to rebuild the box in the week and save wasting your time.
> After patching etc, I did manage to get a little bit further, but when
> using dvbscan I got an error:
>
> [root@cos6 bin]# dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
> /home/mythtv/channels.conf
> Unable to query frontend status
According to the dvbscan wiki page:
http://linuxtv.org/wiki/index.php/Dvbscan
if you get this error you should try other scanning utilities, like scan
or w_scan. You can also try a real application, like Kaffeine.
Best regards,
Gianluca
>
> Dmesg output:
> usb 1-3: new high speed USB device using ehci_hcd and address 2
> usb 1-3: New USB device found, idVendor=2040, idProduct=7080
> usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-3: Product: myTV.t
> usb 1-3: Manufacturer: Eskape Lab
Re: [RFC 08/17] v4l: Image source control class
Hi Sakari, On 01/14/2012 09:51 PM, Sakari Ailus wrote: >>> diff --git a/drivers/media/video/v4l2-ctrls.c >>> b/drivers/media/video/v4l2-ctrls.c index 083bb79..da1ec52 100644 >>> --- a/drivers/media/video/v4l2-ctrls.c >>> +++ b/drivers/media/video/v4l2-ctrls.c >>> @@ -606,6 +606,12 @@ const char *v4l2_ctrl_get_name(u32 id) >>> case V4L2_CID_FLASH_CHARGE: return "Charge"; >>> case V4L2_CID_FLASH_READY: return "Ready to strobe"; >>> >>> + case V4L2_CID_IMAGE_SOURCE_CLASS: return "Image source controls"; >>> + case V4L2_CID_IMAGE_SOURCE_VBLANK: return "Vertical blanking"; >>> + case V4L2_CID_IMAGE_SOURCE_HBLANK: return "Horizontal blanking"; >>> + case V4L2_CID_IMAGE_SOURCE_LINK_FREQ: return "Link frequency"; >>> + case V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN: return "Analogue gain"; >> >> Please capitalize each word, as done for the other controls. > > This isn't done for the flash controls either, have you noticed that? > > Well, I guess I have to admit that they were added by myself. ;-) > > I can fix this for the next patchset. I don't want to be annoying (too much ;)) but the FLASH controls documentation is missing some tags in the text. Other classes use them for standard identifiers. Regards, Sylwester -- 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: [media-ctl PATCH 1/1] libmediactl: Implement MEDIA_ENT_ID_FLAG_NEXT in media_get_entity_by_id()
Hi Laurent,
Laurent Pinchart wrote:
On Saturday 14 January 2012 20:33:36 Sakari Ailus wrote:
Signed-off-by: Sakari Ailus
---
src/mediactl.c |9 +++--
src/mediactl.h |4 +++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/mediactl.c b/src/mediactl.c
index 5b8c587..f62fcdf 100644
--- a/src/mediactl.c
+++ b/src/mediactl.c
@@ -81,8 +81,13 @@ struct media_entity *media_get_entity_by_id(struct
media_device *media, for (i = 0; i< media->entities_count; ++i) {
struct media_entity *entity =&media->entities[i];
- if (entity->info.id == id)
- return entity;
+ if (!(id& MEDIA_ENT_ID_FLAG_NEXT)) {
+ if (entity->info.id == id)
+ return entity;
+ } else {
+ if (entity->info.id>= (id& ~MEDIA_ENT_ID_FLAG_NEXT)
+ return entity;
+ }
Just one question that hasn't crossed my mind before, why do you need this ?
If you want to enumerate entities in an application you can just iterate over
media_device::entities.
We do have the MEDIA_ENT_ID_FLAG_NEXT flag which is intended to help in
entity enumeration. Currently the range of entity ids is contiguous in
all practical implementation but will that always be the case, also in
the future? A few things might break in the kernel if the range is
non-contiguous as well, but that's still internal to the kernel.
However, this is a user space library and if this interface change is
not made, we essentially are making a promise that the entity ranges
will always be contiguous.
I wouldn't as there's no need to do so.
I you think about programmable hardware, entities there are logical
rather than physical and their existence may be dependent on multiple
factors.
--
Sakari Ailus
sakari.ai...@iki.fi
--
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: Hauppage Nova: doesn't know how to handle a DVBv3 call to delivery system 0
On 15 January 2012 14:24, Mauro Carvalho Chehab wrote:
> Em 15-01-2012 09:51, Gianluca Gennari escreveu:
>> Il 15/01/2012 12:35, razza lists ha scritto:
>>> On Sat, Jan 14, 2012 at 11:44 PM, Gianluca Gennari
>>> wrote:
Il 15/01/2012 00:41, RazzaList ha scritto:
> I have followed the build instructions for the Hauppauge MyTV.t device
> here
> - http://linuxtv.org/wiki/index.php/Hauppauge_myTV.t and built the drivers
> as detailed here -
> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_D
> evice_Drivers on a CentOS 6.2 i386 build.
>
> When I use dvbscan, nothing happens. dmesg shows "
> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> delivery system 0"
>
> [root@cos6 ~]# cd /usr/bin
> [root@cos6 bin]# ./dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
> /usr/share/dvb/dvb-t/channels.conf
> [root@cos6 bin]# dmesg | grep dvb
> dvb-usb: found a 'Hauppauge Nova-T MyTV.t' in warm state.
> dvb-usb: will pass the complete MPEG2 transport stream to the software
> demuxer.
> dvb-usb: schedule remote query interval to 50 msecs.
> dvb-usb: Hauppauge Nova-T MyTV.t successfully initialized and connected.
> usbcore: registered new interface driver dvb_usb_dib0700
> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> delivery system 0
>
> I have searched but can't locate a fix. Any pointers?
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>
Hi,
this patch will likely fix your problem:
http://patchwork.linuxtv.org/patch/9492/
Best regards,
Gianluca
>>>
>>> It's very likely the case I'm doing something wrong and I apologise in
>>> advance! However some help/guidance would be great...
>>>
>>> I have downloaded the sources as described in the basic approach here
>>> -
>>> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
>>>
>>> In the source there is no file called "dvb_frontend.c", so I assume I
>>> start the media_build/build script?
>>> If I do, eventually this creates
>>> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
>>>
>>> I then apply the patch to
>>> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c, and I can
>>> see the added elements...
>>>
>>> static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
>>> {
>>> struct dtv_frontend_properties *c = &fe->dtv_property_cache;
>>> int i;
>>> u32 delsys;
>>>
>>> delsys = c->delivery_system;
>>> memset(c, 0, sizeof(struct dtv_frontend_properties));
>>> c->delivery_system = delsys;
>>>
>>> c->state = DTV_CLEAR;
>>>
>>> dprintk("%s() Clearing cache for delivery system %d\n", __func__,
>>> c->delivery_system);
>>>
>>>
>>> After a reboot (as I have not got a clue about unloading modules etc.)
>>> I then execute make install but I still get the same error
>>> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>>> delivery system 0" when I use dvbscan.
>>>
>>
>> You are almost there.
>> After you apply the patch, you have to recompile the entire source tree.
>> You can do it launching the "make" command inside the linux/ folder.
>> Then reinstall the drivers giving "make install" from the media_build/
>> folder, and reboot.
>
> I've added the fixes for it today. So, tomorrow's tarballs should have this
> bug fixed.
>
>>
>> Best regards,
>> Gianluca
>> --
>> 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
>
I'm glad about that as I am getting nowhere fast. Looks like it's
better to rebuild the box in the week and save wasting your time.
After patching etc, I did manage to get a little bit further, but when
using dvbscan I got an error:
[root@cos6 bin]# dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
/home/mythtv/channels.conf
Unable to query frontend status
Dmesg output:
usb 1-3: new high speed USB device using ehci_hcd and address 2
usb 1-3: New USB device found, idVendor=2040, idProduct=7080
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product: myTV.t
usb 1-3: Manufacturer: Eskape Labs
usb 1-3: SerialNumber: 4030928317
usb 1-3: configuration #1 chosen from 1 choice
WARNING: You are using an experimental version of the media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
240ab508aa9fb7a294b0ecb563b19ead000b2463
Re: Hauppage Nova: doesn't know how to handle a DVBv3 call to delivery system 0
Em 15-01-2012 09:51, Gianluca Gennari escreveu:
> Il 15/01/2012 12:35, razza lists ha scritto:
>> On Sat, Jan 14, 2012 at 11:44 PM, Gianluca Gennari
>> wrote:
>>>
>>> Il 15/01/2012 00:41, RazzaList ha scritto:
I have followed the build instructions for the Hauppauge MyTV.t device here
- http://linuxtv.org/wiki/index.php/Hauppauge_myTV.t and built the drivers
as detailed here -
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_D
evice_Drivers on a CentOS 6.2 i386 build.
When I use dvbscan, nothing happens. dmesg shows "
dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
delivery system 0"
[root@cos6 ~]# cd /usr/bin
[root@cos6 bin]# ./dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
/usr/share/dvb/dvb-t/channels.conf
[root@cos6 bin]# dmesg | grep dvb
dvb-usb: found a 'Hauppauge Nova-T MyTV.t' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: Hauppauge Nova-T MyTV.t successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_dib0700
dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
delivery system 0
I have searched but can't locate a fix. Any pointers?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>>
>>> Hi,
>>> this patch will likely fix your problem:
>>>
>>> http://patchwork.linuxtv.org/patch/9492/
>>>
>>> Best regards,
>>> Gianluca
>>
>> It's very likely the case I'm doing something wrong and I apologise in
>> advance! However some help/guidance would be great...
>>
>> I have downloaded the sources as described in the basic approach here
>> -
>> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
>>
>> In the source there is no file called "dvb_frontend.c", so I assume I
>> start the media_build/build script?
>> If I do, eventually this creates
>> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
>>
>> I then apply the patch to
>> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c, and I can
>> see the added elements...
>>
>> static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
>> {
>> struct dtv_frontend_properties *c = &fe->dtv_property_cache;
>> int i;
>> u32 delsys;
>>
>> delsys = c->delivery_system;
>> memset(c, 0, sizeof(struct dtv_frontend_properties));
>> c->delivery_system = delsys;
>>
>> c->state = DTV_CLEAR;
>>
>> dprintk("%s() Clearing cache for delivery system %d\n", __func__,
>> c->delivery_system);
>>
>>
>> After a reboot (as I have not got a clue about unloading modules etc.)
>> I then execute make install but I still get the same error
>> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>> delivery system 0" when I use dvbscan.
>>
>
> You are almost there.
> After you apply the patch, you have to recompile the entire source tree.
> You can do it launching the "make" command inside the linux/ folder.
> Then reinstall the drivers giving "make install" from the media_build/
> folder, and reboot.
I've added the fixes for it today. So, tomorrow's tarballs should have this
bug fixed.
>
> Best regards,
> Gianluca
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-ctl PATCH 1/1] libmediactl: Implement MEDIA_ENT_ID_FLAG_NEXT in media_get_entity_by_id()
Hi Sakari,
Thanks for the patch.
On Saturday 14 January 2012 20:33:36 Sakari Ailus wrote:
> Signed-off-by: Sakari Ailus
> ---
> src/mediactl.c |9 +++--
> src/mediactl.h |4 +++-
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/mediactl.c b/src/mediactl.c
> index 5b8c587..f62fcdf 100644
> --- a/src/mediactl.c
> +++ b/src/mediactl.c
> @@ -81,8 +81,13 @@ struct media_entity *media_get_entity_by_id(struct
> media_device *media, for (i = 0; i < media->entities_count; ++i) {
> struct media_entity *entity = &media->entities[i];
>
> - if (entity->info.id == id)
> - return entity;
> + if (!(id & MEDIA_ENT_ID_FLAG_NEXT)) {
> + if (entity->info.id == id)
> + return entity;
> + } else {
> + if (entity->info.id >= (id & ~MEDIA_ENT_ID_FLAG_NEXT)
> + return entity;
> + }
Just one question that hasn't crossed my mind before, why do you need this ?
If you want to enumerate entities in an application you can just iterate over
media_device::entities.
> }
>
> return NULL;
> diff --git a/src/mediactl.h b/src/mediactl.h
> index 1b47b7e..4d3892e 100644
> --- a/src/mediactl.h
> +++ b/src/mediactl.h
> @@ -164,7 +164,9 @@ struct media_entity *media_get_entity_by_name(struct
> media_device *media, * @param media - media device.
> * @param id - entity ID.
> *
> - * Search for an entity with an ID equal to @a id.
> + * Search for an entity with an ID equal to @a id. If id flag
> + * MEDIA_ENT_ID_FLAG_NEXT is present, an entity with ID greater or equal
> to + * @a id will be returned.
> *
> * @return A pointer to the entity if found, or NULL otherwise.
> */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [regression] v4l: Add custom compat_ioctl32 operation
On Sunday, January 15, 2012 14:14:13 Laurent Pinchart wrote: > Hi Alexey, > > On Sunday 15 January 2012 10:09:54 Oleksij Rempel (Alexey Fisher) wrote: > > hi Laurent, > > > > this patch seem to create circular module dependency. I get this error: > > WARNING: Module > > /lib/modules/3.2.0-00660-g1801bbe-dirty/kernel/drivers/media/video/videodev > > .ko ignored, due to loop > > WARNING: Loop detected: > > /lib/modules/3.2.0-00660-g1801bbe-dirty/kernel/drivers/media/video/v4l2-com > > pat-ioctl32.ko needs videodev.ko which needs v4l2-compat-ioctl32.ko again! > > Thanks for the report. > > Hans, what do you think about the patch below ? > > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 3541388..8c4a94d 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -17,7 +17,7 @@ videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o > v4l2-fh.o \ > > obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o > ifeq ($(CONFIG_COMPAT),y) > - obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o > + videodev-objs += v4l2-compat-ioctl32.o > endif > > obj-$(CONFIG_VIDEO_V4L2_COMMON) += v4l2-common.o > > I don't see a very compelling reason to put v4l2_compat_ioctl32() in a > separate module. If that fine with you, I'll also remove the #ifdef > CONFIG_COMPAT from v4l2-compat-ioctl32.c. Seems reasonable. Although I suggest that you move up the 'ifeq - endif' part to right after the 'videodev-objs := ...' line in the makefile. That's more logical in this case. Regards, Hans > > > commit bf5aa456853816f807a46c0d944efb997142ffaf > > Author: Laurent Pinchart > > Date: Mon Dec 19 00:41:19 2011 +0100 > > > > v4l: Add custom compat_ioctl32 operation > > > > Drivers implementing custom ioctls need to handle 32-bit/64-bit > > compatibility themselves. Provide them with a way to do so. > > > > Signed-off-by: Laurent Pinchart > > Reviewed-by: Hans Verkuil > > -- 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: [regression] v4l: Add custom compat_ioctl32 operation
Hi Alexey, On Sunday 15 January 2012 10:09:54 Oleksij Rempel (Alexey Fisher) wrote: > hi Laurent, > > this patch seem to create circular module dependency. I get this error: > WARNING: Module > /lib/modules/3.2.0-00660-g1801bbe-dirty/kernel/drivers/media/video/videodev > .ko ignored, due to loop > WARNING: Loop detected: > /lib/modules/3.2.0-00660-g1801bbe-dirty/kernel/drivers/media/video/v4l2-com > pat-ioctl32.ko needs videodev.ko which needs v4l2-compat-ioctl32.ko again! Thanks for the report. Hans, what do you think about the patch below ? diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 3541388..8c4a94d 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -17,7 +17,7 @@ videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \ obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o ifeq ($(CONFIG_COMPAT),y) - obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o + videodev-objs += v4l2-compat-ioctl32.o endif obj-$(CONFIG_VIDEO_V4L2_COMMON) += v4l2-common.o I don't see a very compelling reason to put v4l2_compat_ioctl32() in a separate module. If that fine with you, I'll also remove the #ifdef CONFIG_COMPAT from v4l2-compat-ioctl32.c. > commit bf5aa456853816f807a46c0d944efb997142ffaf > Author: Laurent Pinchart > Date: Mon Dec 19 00:41:19 2011 +0100 > > v4l: Add custom compat_ioctl32 operation > > Drivers implementing custom ioctls need to handle 32-bit/64-bit > compatibility themselves. Provide them with a way to do so. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Hans Verkuil -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage Nova: doesn't know how to handle a DVBv3 call to delivery system 0
Il 15/01/2012 12:35, razza lists ha scritto:
> On Sat, Jan 14, 2012 at 11:44 PM, Gianluca Gennari
> wrote:
>>
>> Il 15/01/2012 00:41, RazzaList ha scritto:
>>> I have followed the build instructions for the Hauppauge MyTV.t device here
>>> - http://linuxtv.org/wiki/index.php/Hauppauge_myTV.t and built the drivers
>>> as detailed here -
>>> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_D
>>> evice_Drivers on a CentOS 6.2 i386 build.
>>>
>>> When I use dvbscan, nothing happens. dmesg shows "
>>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>>> delivery system 0"
>>>
>>> [root@cos6 ~]# cd /usr/bin
>>> [root@cos6 bin]# ./dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
>>> /usr/share/dvb/dvb-t/channels.conf
>>> [root@cos6 bin]# dmesg | grep dvb
>>> dvb-usb: found a 'Hauppauge Nova-T MyTV.t' in warm state.
>>> dvb-usb: will pass the complete MPEG2 transport stream to the software
>>> demuxer.
>>> dvb-usb: schedule remote query interval to 50 msecs.
>>> dvb-usb: Hauppauge Nova-T MyTV.t successfully initialized and connected.
>>> usbcore: registered new interface driver dvb_usb_dib0700
>>> dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>>> delivery system 0
>>>
>>> I have searched but can't locate a fix. Any pointers?
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Hi,
>> this patch will likely fix your problem:
>>
>> http://patchwork.linuxtv.org/patch/9492/
>>
>> Best regards,
>> Gianluca
>
> It's very likely the case I'm doing something wrong and I apologise in
> advance! However some help/guidance would be great...
>
> I have downloaded the sources as described in the basic approach here
> -
> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
>
> In the source there is no file called "dvb_frontend.c", so I assume I
> start the media_build/build script?
> If I do, eventually this creates
> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
>
> I then apply the patch to
> media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c, and I can
> see the added elements...
>
> static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
> {
> struct dtv_frontend_properties *c = &fe->dtv_property_cache;
> int i;
> u32 delsys;
>
> delsys = c->delivery_system;
> memset(c, 0, sizeof(struct dtv_frontend_properties));
> c->delivery_system = delsys;
>
> c->state = DTV_CLEAR;
>
> dprintk("%s() Clearing cache for delivery system %d\n", __func__,
> c->delivery_system);
>
>
> After a reboot (as I have not got a clue about unloading modules etc.)
> I then execute make install but I still get the same error
> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> delivery system 0" when I use dvbscan.
>
You are almost there.
After you apply the patch, you have to recompile the entire source tree.
You can do it launching the "make" command inside the linux/ folder.
Then reinstall the drivers giving "make install" from the media_build/
folder, and reboot.
Best regards,
Gianluca
--
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: Hauppage Nova: doesn't know how to handle a DVBv3 call to delivery system 0
On Sat, Jan 14, 2012 at 11:44 PM, Gianluca Gennari wrote:
>
> Il 15/01/2012 00:41, RazzaList ha scritto:
> > I have followed the build instructions for the Hauppauge MyTV.t device here
> > - http://linuxtv.org/wiki/index.php/Hauppauge_myTV.t and built the drivers
> > as detailed here -
> > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_D
> > evice_Drivers on a CentOS 6.2 i386 build.
> >
> > When I use dvbscan, nothing happens. dmesg shows "
> > dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> > delivery system 0"
> >
> > [root@cos6 ~]# cd /usr/bin
> > [root@cos6 bin]# ./dvbscan /usr/share/dvb/dvb-t/uk-Hannington >
> > /usr/share/dvb/dvb-t/channels.conf
> > [root@cos6 bin]# dmesg | grep dvb
> > dvb-usb: found a 'Hauppauge Nova-T MyTV.t' in warm state.
> > dvb-usb: will pass the complete MPEG2 transport stream to the software
> > demuxer.
> > dvb-usb: schedule remote query interval to 50 msecs.
> > dvb-usb: Hauppauge Nova-T MyTV.t successfully initialized and connected.
> > usbcore: registered new interface driver dvb_usb_dib0700
> > dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> > delivery system 0
> >
> > I have searched but can't locate a fix. Any pointers?
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> Hi,
> this patch will likely fix your problem:
>
> http://patchwork.linuxtv.org/patch/9492/
>
> Best regards,
> Gianluca
It's very likely the case I'm doing something wrong and I apologise in
advance! However some help/guidance would be great...
I have downloaded the sources as described in the basic approach here
-
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
In the source there is no file called "dvb_frontend.c", so I assume I
start the media_build/build script?
If I do, eventually this creates
media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
I then apply the patch to
media_build/linux/drivers/media/dvb/dvb-core/dvb_frontend.c, and I can
see the added elements...
static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int i;
u32 delsys;
delsys = c->delivery_system;
memset(c, 0, sizeof(struct dtv_frontend_properties));
c->delivery_system = delsys;
c->state = DTV_CLEAR;
dprintk("%s() Clearing cache for delivery system %d\n", __func__,
c->delivery_system);
After a reboot (as I have not got a clue about unloading modules etc.)
I then execute make install but I still get the same error
"dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
delivery system 0" when I use dvbscan.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] [media] tlg2300: fix up check_firmware() return
The caller doesn't check the return value of check_firmware() but static
checkers complain. It currently returns negative error codes, or zero
or greater on success but since the return type is boolean the values
are truncated to one or zero. I've changed it to return an int,
negative on error and zero on success.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/video/tlg2300/pd-main.c
b/drivers/media/video/tlg2300/pd-main.c
index 129f135..c096b3f 100644
--- a/drivers/media/video/tlg2300/pd-main.c
+++ b/drivers/media/video/tlg2300/pd-main.c
@@ -374,7 +374,7 @@ static inline void set_map_flags(struct poseidon *pd,
struct usb_device *udev)
}
#endif
-static bool check_firmware(struct usb_device *udev, int *down_firmware)
+static int check_firmware(struct usb_device *udev, int *down_firmware)
{
void *buf;
int ret;
@@ -398,7 +398,7 @@ static bool check_firmware(struct usb_device *udev, int
*down_firmware)
*down_firmware = 1;
return firmware_download(udev);
}
- return ret;
+ return 0;
}
static int poseidon_probe(struct usb_interface *interface,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] [media] saa7164: remove duplicate initialization
These were initialized twice by mistake. They were defined the same way
both times so this doesn't change how the code works.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/video/saa7164/saa7164-cards.c
b/drivers/media/video/saa7164/saa7164-cards.c
index 971591d..5b72da5 100644
--- a/drivers/media/video/saa7164/saa7164-cards.c
+++ b/drivers/media/video/saa7164/saa7164-cards.c
@@ -269,8 +269,6 @@ struct saa7164_board saa7164_boards[] = {
.portb = SAA7164_MPEG_DVB,
.portc = SAA7164_MPEG_ENCODER,
.portd = SAA7164_MPEG_ENCODER,
- .portc = SAA7164_MPEG_ENCODER,
- .portd = SAA7164_MPEG_ENCODER,
.porte = SAA7164_MPEG_VBI,
.portf = SAA7164_MPEG_VBI,
.chiprev= SAA7164_CHIP_REV3,
@@ -333,8 +331,6 @@ struct saa7164_board saa7164_boards[] = {
.portd = SAA7164_MPEG_ENCODER,
.porte = SAA7164_MPEG_VBI,
.portf = SAA7164_MPEG_VBI,
- .porte = SAA7164_MPEG_VBI,
- .portf = SAA7164_MPEG_VBI,
.chiprev= SAA7164_CHIP_REV3,
.unit = {{
.id = 0x28,
--
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
White Balance Temperature
Hi there my "Live! Cam Socialize HD VF0610", Device ID: 041e:4080, Driver: uvcvideo is running perfectly on Fedora 16 Linux, except one thing: When I try to switch on "White Balance Temperature, Auto" or just try to change "White Balance Temperature" slider I get a failure message and it won't work. All other controls, like contrast, gamma, etc. are working. "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" produces an error message: "VIDIOC_S_CTRL: failed: Input/output error white_balance_temperature_auto: Input/output error" As soon as I boot Windows (inside Linux out of a Virtual Box), start the camera there and go back to Linux, I am able to adjust and switch on the White Balance things in Linux. "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" working fine after running the camera in Windows. Everytime I switch off my computer or disconnect the camera, I have to run the camera in Windows again, bevor I can adjust White Balance in Linux. What can I do to get White Balance controls working in Linux, without having to run the camera in Windows every time? Is there a special command I have to send to the camera for initializing or so? Best regards Aurel -- 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: v4l: how to get blanking clock count?
Hi Scott, On Wed, Jan 04, 2012 at 05:59:45PM +0800, Scott Jiang wrote: > >> If I disable this interrupt, other errors like fifo underflow are ignored. > >> Perhaps I can add a parameter in platform data to let user decide to > >> register this interrupt or not. > > > > I think a more generic solution would be preferrable. If that causes > > ignoring real errors, that's of course bad. I wonder if there would be a > > way around that. > > > > Is there a publicly available datasheet for the bridge that I could take a > > look at? > > > Yes, > http://www.analog.com/en/processors-dsp/blackfin/adsp-bf548/processors/technical-documentation/index.html. > There is a hardware reference manual for bf54x, bridge is eppi. Yeah, indeed it's the first time I see hardware like this. So to support this properly, we truly need the new sensor control interface and an ability to make those blanking values unchangeable. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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
