linux-media@vger.kernel.org

[Mauro Carvalho Chehab]

Em Tue, 02 Sep 2014 06:42:42 + (GMT)
Changbing Xiong  escreveu:

> > Actually, poll() may return an error as well (from poll() manpage):
> 
> > "RETURN VALUE
> >On success, a positive number is returned; this is the number of 
> > struc‐
> >tures which have nonzero revents fields (in other words, those 
> > descrip‐
> >tors  with events or errors reported).  A value of 0 indicates that 
> > the
> >call timed out and no file descriptors were ready.   On  error,  -1  
> > is
> >returned, and errno is set appropriately."
> 
> > So, if the Kernel returns -ENODEV, the glibc poll() wrapper would return -1
> > and errno will be ENODEV. Never actually tested if this works on poll()
> > though.
> 
> > Actually, poll() may return an error as well (from poll() manpage):
> 
> > "RETURN VALUE
> >On success, a positive number is returned; this is the number of 
> > struc‐
> >tures which have nonzero revents fields (in other words, those 
> > descrip‐
> >tors  with events or errors reported).  A value of 0 indicates that 
> > the
> >call timed out and no file descriptors were ready.   On  error,  -1  
> > is
> >returned, and errno is set appropriately."
> 
> > So, if the Kernel returns -ENODEV, the glibc poll() wrapper would return -1
> > and errno will be ENODEV. Never actually tested if this works on poll()
> > though.
> 
> maybe the poll() manpage is wrong.
> The standard system call poll() can not get -ENODEV from errno. 

Well, it would likely put ENODEV at errno (and not -ENODEV).

> My experiment has proved that I was right(return -ENODEV directly in 
> dvb_dvr_poll).  
> and you can also check code of do_poll() and do_sys_poll() in select.c file, 
> it also shows that -ENODEV is invalid.

Yeah, I'll check it there. Poll have some different handling, so
it is possible that it only accepts a subset of error codes.

Btw, I'm not against returning POLLERR there. Just not sure at
this point what would be the best approach. Anyway, read and
all other syscalls should return -ENODEV.

> please also check that.

Sure I will.
> 
> thanks!
> Xiong changbing
> 
> --- Original Message ---
> Sender : Mauro Carvalho Chehab Director/SRBR-Open 
> Source/삼성전자
> Date : 九月 02, 2014 15:00 (GMT+09:00)
> Title : Re: [PATCH 3/3] media: check status of dmxdev->exit in poll functions 
> of demux&dvr
> 
> Em Tue, 02 Sep 2014 03:16:00 + (GMT)
> Changbing Xiong escreveu:
> 
> > 
> > > Well, we may start returning -ENODEV when such event happens. 
> > 
> > > At the frontend, we could use fe->exit = DVB_FE_DEVICE_REMOVED to
> > > signalize it. I don't think that the demod frontend has something
> > > similar.
> > 
> > > Yet, it should be up to the userspace application to properly handle 
> > > the error codes and close the devices on fatal non-recovery errors like
> > > ENODEV. 
> > 
> > > So, what we can do, at Kernel level, is to always return -ENODEV when
> > > the device is known to be removed, and double check libdvbv5 if it
> > > handles such error properly.
> > 
> >  well, we do not use libdvbv5,
> 
> The upstream stuff I maintain, related to it, are the media subsystems
> and libdvbv5. Of course, other apps will need to be patched as well.
> 
> > and  -ENODEV can be returned by read syscall,  
> > but for poll syscall,
> 
> Actually, poll() may return an error as well (from poll() manpage):
> 
> "RETURN VALUE
>On success, a positive number is returned; this is the number of struc‐
>tures which have nonzero revents fields (in other words, those descrip‐
>tors  with events or errors reported).  A value of 0 indicates that the
>call timed out and no file descriptors were ready.   On  error,  -1  is
>returned, and errno is set appropriately."
> 
> So, if the Kernel returns -ENODEV, the glibc poll() wrapper would return -1
> and errno will be ENODEV. Never actually tested if this works on poll()
> though.
> 
> >  -ENODEV can never be returned to user, as negative number
> >  is invalid  type for poll returned value. please refer to my second patch.
> > 
> > and in our usage, whether to read the device is up to the poll result. if 
> > tuner is plugged out, 
> > and there is no data in dvr ringbuffer. then user code will still go on 
> > polling the dvr device and never stop.
> > if POLLERR is returned, then user will perform read dvr, and then -ENODEV 
> > can be got, and 
> > user will stop polling dvr device.
> 
> Your app should be also be handling poll() errors, as there are already
> other errors that poll() can return.
> 
> > the first patch is enough to fix the deadlock issue.
> > the second patch is used to correct the wrong type of returned value.
> > the third patch is used to provide user a better controlling logic.
> 
> I'll take a deeper look and do some tests on your patches likely
> tomorrow. 
> 
> Regards,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"

Re: [PATCH] videobuf: Allow reqbufs(0) to free current buffers

[Marek Szyprowski]

Hello,

On 2014-09-01 17:36, Hans de Goede wrote:

Hi,

On 09/01/2014 03:29 PM, Hans Verkuil wrote:

Hi Hans,

At first glance this looks fine. But making changes in videobuf is always scary 
:-)
so I hope Marek can look at this as well.

How well was this tested?

I ran some tests on bttv which all ran well.

Note that the code already allowed for going from say 4 buffers to 1,
and the old code path for reqbufs was already calling __videobuf_free()
before re-allocating the buffers again. So in essence this just changes
things to allow the 4 buffers to 1 case to also be 4 buffers to 0.


The patch looks fine and the explanation is also convincing, so it 
turned out
that this long standing issue can be fixed quite easily, however I don't 
have

any hardware to do the tests right now.

Acked-by: Marek Szyprowski 


On 08/31/2014 12:19 PM, Hans de Goede wrote:

All the infrastructure for this is already there, and despite our desires for
the old videobuf code to go away, it is currently still in use in 18 drivers.

Allowing reqbufs(0) makes these drivers behave consistent with modern drivers,
making live easier for userspace, see e.g. :
https://bugzilla.gnome.org/show_bug.cgi?id=735660

Signed-off-by: Hans de Goede 
---
  drivers/media/v4l2-core/videobuf-core.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf-core.c 
b/drivers/media/v4l2-core/videobuf-core.c
index fb5ee5d..b91a266 100644
--- a/drivers/media/v4l2-core/videobuf-core.c
+++ b/drivers/media/v4l2-core/videobuf-core.c
@@ -441,11 +441,6 @@ int videobuf_reqbufs(struct videobuf_queue *q,
unsigned int size, count;
int retval;
  
-	if (req->count < 1) {

-   dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
-   return -EINVAL;
-   }
-
if (req->memory != V4L2_MEMORY_MMAP &&
req->memory != V4L2_MEMORY_USERPTR  &&
req->memory != V4L2_MEMORY_OVERLAY) {
@@ -471,6 +466,12 @@ int videobuf_reqbufs(struct videobuf_queue *q,
goto done;
}
  
+	if (req->count == 0) {

+   dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
+   retval = __videobuf_free(q);
+   goto done;
+   }
+
count = req->count;
if (count > VIDEO_MAX_FRAME)
count = VIDEO_MAX_FRAME;




Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] videobuf: Allow reqbufs(0) to free current buffers

[Hans Verkuil]

On 09/01/14 17:36, Hans de Goede wrote:
> Hi,
> 
> On 09/01/2014 03:29 PM, Hans Verkuil wrote:
>> Hi Hans,
>>
>> At first glance this looks fine. But making changes in videobuf is always 
>> scary :-)
>> so I hope Marek can look at this as well.
>>
>> How well was this tested?
> 
> I ran some tests on bttv which all ran well.
> 
> Note that the code already allowed for going from say 4 buffers to 1,
> and the old code path for reqbufs was already calling __videobuf_free()
> before re-allocating the buffers again. So in essence this just changes
> things to allow the 4 buffers to 1 case to also be 4 buffers to 0.

The code looks good and I've tested it with cx88 which worked (well, except
for the zillion other bugs in cx88, but that's another story). I do want to
do a few more tests on Friday, though. This time with a more stable driver.

I think we should consider adding this to the stable tree as well.

Regards,

Hans

> 
> Regards,
> 
> Hans
> 
> 
>>
>> I'll try do test this as well.
>>
>> Regards,
>>
>>  Hans
>>
>> On 08/31/2014 12:19 PM, Hans de Goede wrote:
>>> All the infrastructure for this is already there, and despite our desires 
>>> for
>>> the old videobuf code to go away, it is currently still in use in 18 
>>> drivers.
>>>
>>> Allowing reqbufs(0) makes these drivers behave consistent with modern 
>>> drivers,
>>> making live easier for userspace, see e.g. :
>>> https://bugzilla.gnome.org/show_bug.cgi?id=735660
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  drivers/media/v4l2-core/videobuf-core.c | 11 ++-
>>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf-core.c 
>>> b/drivers/media/v4l2-core/videobuf-core.c
>>> index fb5ee5d..b91a266 100644
>>> --- a/drivers/media/v4l2-core/videobuf-core.c
>>> +++ b/drivers/media/v4l2-core/videobuf-core.c
>>> @@ -441,11 +441,6 @@ int videobuf_reqbufs(struct videobuf_queue *q,
>>> unsigned int size, count;
>>> int retval;
>>>  
>>> -   if (req->count < 1) {
>>> -   dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
>>> -   return -EINVAL;
>>> -   }
>>> -
>>> if (req->memory != V4L2_MEMORY_MMAP &&
>>> req->memory != V4L2_MEMORY_USERPTR  &&
>>> req->memory != V4L2_MEMORY_OVERLAY) {
>>> @@ -471,6 +466,12 @@ int videobuf_reqbufs(struct videobuf_queue *q,
>>> goto done;
>>> }
>>>  
>>> +   if (req->count == 0) {
>>> +   dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
>>> +   retval = __videobuf_free(q);
>>> +   goto done;
>>> +   }
>>> +
>>> count = req->count;
>>> if (count > VIDEO_MAX_FRAME)
>>> count = VIDEO_MAX_FRAME;
>>>
>>

--
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: s5p-mfc should allow multiple call to REQBUFS before we start streaming

[Kamil Debski]

Hi Hans, Nicolas,

Hans, would you mind commenting on this?

> From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
> Sent: Monday, September 01, 2014 5:46 PM
> 
> 
> Le 2014-09-01 05:43, Kamil Debski a écrit :
> > Hi Nicolas,
> >
> >
> >> From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
> >> Sent: Friday, August 29, 2014 3:47 PM
> >>
> >> Hi Kamil,
> >>
> >> after a discussion on IRC, we concluded that s5p-mfc have this bug
> >> that disallow multiple reqbufs calls before streaming. This has the
> >> impact that it forces to call REQBUFS(0) before setting the new
> >> number of buffers during re-negotiation, and is against the spec too.
> > I was out of office last week. Could you shed more light on this
> subject?
> > Do you have the irc log?
> 
> Sorry I didn't record this one, but feel free to ping Hans V.
> >> As an example, in reqbufs_output() REQBUFS is only allowed in
> >> QUEUE_FREE state, and setting buffers exits this state. We think
> that
> >> the call to
> >>  >> electrons.com/ident?i=reqbufs_output>s5p_mfc_open_mfc_inst()
> >> should be post-poned until STREAMON is called.
> >> 
> > How is this connected to the renegotiation scenario?
> > Are you sure you wanted to mention s5p_mfc_open_mfc_inst?
> This limitation in MFC causes an important conflict between old
> videobuf and new videobuf2 drivers. Old videobuf driver (before Hans G.
> proposed
> patch) refuse REQBUFS(0). As MFC code has this bug that refuse
> REBBUFS(N) if buffers are already allocated, it makes all this
> completely incompatible. This open_mfc call seems to be the only reason
> REQBUFS() cannot be called multiple time, though I must say you are
> better placed then me to figure this out.

After MFCs decoding is initialized it has a fixed number of buffers.
Changing
this can be done when the stream changes its properties and resolution
change is initiated. Even then all buffers have to be
unmapped/reallocated/mapped.

There is a single hardware call that is a part of hardware initialization
that sets the buffers' addresses.

Changing the number of buffers during decoding without explicit reason to do
so (resolution change/stream properties change) would be problematic. For 
hardware it is very close to reinitiating decoding - it needs to be done on
an I-frame, the header needs to be present. Otherwise some buffers would be
lost and corruption would be introduced (lack of reference frames).

I think you mentioned negotiating the number of buffers? Did you use the
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE control?

I understand that before calling REQBUFS(N) with the new N value you
properly
unmap the buffers just like the documentation is telling?

"Applications can call VIDIOC_REQBUFS again to change the number of buffers,
however this cannot succeed when any buffers are still mapped. A count value
of zero frees all buffers, after aborting or finishing any DMA in progress,
an implicit VIDIOC_STREAMOFF." [1]

Could you tell me what is the scenario where you want to use the REQBUFS(N)
to change number of buffers? Maybe I could understand better the problem.

> 
> cheers,
> Nicolas

[1] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland


--
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] videobuf-dma-contig: replace vm_iomap_memory() with remap_pfn_range().

[Fancy Fang]

When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core
will assign the corresponding offset to the 'boff' field of the
videobuf_buffer for each requested buffer sequentially. Later, user
may call mmap() to map one or all of the buffers with the 'offset'
parameter which is equal to its 'boff' value. Obviously, the 'offset'
value is only used to find the matched buffer instead of to be the
real offset from the buffer's physical start address as used by
vm_iomap_memory(). So, in some case that if the offset is not zero,
vm_iomap_memory() will fail.

Signed-off-by: Fancy Fang 
---
 drivers/media/v4l2-core/videobuf-dma-contig.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c 
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index bf80f0f..8bd9889 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -305,7 +305,9 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
/* Try to remap memory */
size = vma->vm_end - vma->vm_start;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-   retval = vm_iomap_memory(vma, mem->dma_handle, size);
+   retval = remap_pfn_range(vma, vma->vm_start,
+mem->dma_handle >> PAGE_SHIFT,
+size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ",
retval);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: s5p-mfc should allow multiple call to REQBUFS before we start streaming

[Hans Verkuil]

On 09/02/14 11:02, Kamil Debski wrote:
> Hi Hans, Nicolas,
> 
> Hans, would you mind commenting on this?
> 
>> From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
>> Sent: Monday, September 01, 2014 5:46 PM
>>
>>
>> Le 2014-09-01 05:43, Kamil Debski a écrit :
>>> Hi Nicolas,
>>>
>>>
 From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
 Sent: Friday, August 29, 2014 3:47 PM

 Hi Kamil,

 after a discussion on IRC, we concluded that s5p-mfc have this bug
 that disallow multiple reqbufs calls before streaming. This has the
 impact that it forces to call REQBUFS(0) before setting the new
 number of buffers during re-negotiation, and is against the spec too.
>>> I was out of office last week. Could you shed more light on this
>> subject?
>>> Do you have the irc log?
>>
>> Sorry I didn't record this one, but feel free to ping Hans V.
 As an example, in reqbufs_output() REQBUFS is only allowed in
 QUEUE_FREE state, and setting buffers exits this state. We think
>> that
 the call to
 s5p_mfc_open_mfc_inst()
 should be post-poned until STREAMON is called.
 
>>> How is this connected to the renegotiation scenario?
>>> Are you sure you wanted to mention s5p_mfc_open_mfc_inst?
>> This limitation in MFC causes an important conflict between old
>> videobuf and new videobuf2 drivers. Old videobuf driver (before Hans G.
>> proposed
>> patch) refuse REQBUFS(0). As MFC code has this bug that refuse
>> REBBUFS(N) if buffers are already allocated, it makes all this
>> completely incompatible. This open_mfc call seems to be the only reason
>> REQBUFS() cannot be called multiple time, though I must say you are
>> better placed then me to figure this out.
> 
> After MFCs decoding is initialized it has a fixed number of buffers.
> Changing
> this can be done when the stream changes its properties and resolution
> change is initiated. Even then all buffers have to be
> unmapped/reallocated/mapped.
> 
> There is a single hardware call that is a part of hardware initialization
> that sets the buffers' addresses.

But is reqbufs the right place to initial MFC decoding? Wouldn't start_streaming
be a much more logical place for this? Until start_streaming is called apps
are free to request more buffers (with CREATE_BUFS), or request a new set of
buffers (REQBUFS(N)). Only once start_streaming is called does everything
have to be locked down and changes are no longer allowed until after
stop_streaming() (or as long as buffers are still mapped).

I see no reason why REQBUFS should be doing anything other than requesting
buffers.

Regards,

Hans

> 
> Changing the number of buffers during decoding without explicit reason to do
> so (resolution change/stream properties change) would be problematic. For 
> hardware it is very close to reinitiating decoding - it needs to be done on
> an I-frame, the header needs to be present. Otherwise some buffers would be
> lost and corruption would be introduced (lack of reference frames).
> 
> I think you mentioned negotiating the number of buffers? Did you use the
> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE control?
> 
> I understand that before calling REQBUFS(N) with the new N value you
> properly
> unmap the buffers just like the documentation is telling?
> 
> "Applications can call VIDIOC_REQBUFS again to change the number of buffers,
> however this cannot succeed when any buffers are still mapped. A count value
> of zero frees all buffers, after aborting or finishing any DMA in progress,
> an implicit VIDIOC_STREAMOFF." [1]
> 
> Could you tell me what is the scenario where you want to use the REQBUFS(N)
> to change number of buffers? Maybe I could understand better the problem.
> 
>>
>> cheers,
>> Nicolas
> 
> [1] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> 
> Best wishes,
> 

--
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 v2] [media] v4l2: add V4L2 pixel format array and helper functions

[Philipp Zabel]

Hi Hans,

Am Donnerstag, den 28.08.2014, 19:41 +0200 schrieb Hans Verkuil:
> On 08/28/2014 07:32 PM, Hans Verkuil wrote:
> > On 08/28/2014 07:18 PM, Mauro Carvalho Chehab wrote:
> >> I really don't see any gain on applying such patch. If the concern is
> >> just about properly naming the pixel formats, it is a way easier to use
> >> some defines for the names, and use the defines.
> > 
> > It's not just the names, also the bit depth etc. Most drivers need that 
> > information
> > and having it in a central place simplifies driver design. Yes, it slightly
> > increases the amount of memory, but that is insignificant compared to the 
> > huge
> > amount of memory necessary for video buffers. And reducing driver 
> > complexity is
> > always good since that has always been the main problem with drivers, not 
> > memory
> > or code performance.
> 
> I just want to add that we should try out any core solution with an existing 
> driver
> (e.g. saa7134) to see if whatever solution we come up with actually makes 
> drivers
> less complex. The saa7134 is from what I've seen fairly representative of 
> most in
> that is has additional fields besides the name, fourcc and depth that are 
> driver
> specific. So how will that be handled...

my main motivation was unification of the format description strings
(well, not wanting to come up with possibly new ones for every driver),
but reducing driver complexity is a nice side effect.

I think saa7134 won't benefit a whole lot. It still needs to keep that
list for the custom saa7134_format fields, but at least the common ones
can be moved into a struct v4l2_pixfmt_info.

The global array mostly has the potential to remove a little boilerplate
from a lot of the simple cases that are happy with the per-format info
already provided by the array.

regards
Philipp

--
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] Linux Kernel Media mini-summit on Oct, 16-17 in Düsseldorf, Germany

[Philipp Zabel]

Hi,

Am Mittwoch, den 13.08.2014, 10:14 -0300 schrieb Mauro Carvalho Chehab:
> Hi,
> 
> As there are still too things to be discussed in order to improve media
> stuff, and most of the developers nowadays are located in Europe and
> usually go to ELCE, we're scheduling a two day mini-summit in Düsseldorf,
> Germany, on Thrusday/Friday.

Is this a tentative schedule, or is the date set? I.e. can I book a
hotel until Friday now and not worry about having to reschedule?

thanks
Philipp

--
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: s5p-mfc should allow multiple call to REQBUFS before we start streaming

[Kamil Debski]

Hi Hans,

> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: Tuesday, September 02, 2014 11:29 AM
> 
> On 09/02/14 11:02, Kamil Debski wrote:
> > Hi Hans, Nicolas,
> >
> > Hans, would you mind commenting on this?
> >
> >> From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
> >> Sent: Monday, September 01, 2014 5:46 PM
> >>
> >>
> >> Le 2014-09-01 05:43, Kamil Debski a écrit :
> >>> Hi Nicolas,
> >>>
> >>>
>  From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
>  Sent: Friday, August 29, 2014 3:47 PM
> 
>  Hi Kamil,
> 
>  after a discussion on IRC, we concluded that s5p-mfc have this bug
>  that disallow multiple reqbufs calls before streaming. This has
> the
>  impact that it forces to call REQBUFS(0) before setting the new
>  number of buffers during re-negotiation, and is against the spec
> too.
> >>> I was out of office last week. Could you shed more light on this
> >> subject?
> >>> Do you have the irc log?
> >>
> >> Sorry I didn't record this one, but feel free to ping Hans V.
>  As an example, in reqbufs_output() REQBUFS is only allowed in
>  QUEUE_FREE state, and setting buffers exits this state. We think
> >> that
>  the call to
>    electrons.com/ident?i=reqbufs_output>s5p_mfc_open_mfc_inst()
>  should be post-poned until STREAMON is called.
>  
> >>> How is this connected to the renegotiation scenario?
> >>> Are you sure you wanted to mention s5p_mfc_open_mfc_inst?
> >> This limitation in MFC causes an important conflict between old
> >> videobuf and new videobuf2 drivers. Old videobuf driver (before Hans
> G.
> >> proposed
> >> patch) refuse REQBUFS(0). As MFC code has this bug that refuse
> >> REBBUFS(N) if buffers are already allocated, it makes all this
> >> completely incompatible. This open_mfc call seems to be the only
> >> reason
> >> REQBUFS() cannot be called multiple time, though I must say you are
> >> better placed then me to figure this out.
> >
> > After MFCs decoding is initialized it has a fixed number of buffers.
> > Changing
> > this can be done when the stream changes its properties and
> resolution
> > change is initiated. Even then all buffers have to be
> > unmapped/reallocated/mapped.
> >
> > There is a single hardware call that is a part of hardware
> > initialization that sets the buffers' addresses.
> 
> But is reqbufs the right place to initial MFC decoding? Wouldn't
> start_streaming be a much more logical place for this? Until
> start_streaming is called apps are free to request more buffers (with
> CREATE_BUFS), or request a new set of buffers (REQBUFS(N)). Only once
> start_streaming is called does everything have to be locked down and
> changes are no longer allowed until after
> stop_streaming() (or as long as buffers are still mapped).
> 
> I see no reason why REQBUFS should be doing anything other than
> requesting buffers.

Hans, initializing MFC decoding is quite complicated. Saying that it is
initialized in reqbufs is not true.

Initialization starts with opening an instance. Then OUTPUT queue is set
up and stream on. Then MFC can parse the header, know how big the CAPTURE
buffers are and how many of them are necessary. Then CAPTURE queue can be
configured - reqbufs, query_bufs, mapping...

If the problem is that you cannot use REQBUFS(N) to change the number of
buffers then I think it can be changed with some amount of work.

MFC does not support CREATE_BUFS call as this would be problematic.
A new buffers cannot be added without invalidating current buffers, which
will break continuity of the stream and most likely cause corruption in
subsequent frames. That is how the hardware works - buffers cannot be added
freely. Before starting decoding CREATE_BUFS could be possibly used, but in
case of resolution change I think it would cause a problem.

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland

> 
> Regards,
> 
>   Hans
> 
> >
> > Changing the number of buffers during decoding without explicit
> reason
> > to do so (resolution change/stream properties change) would be
> > problematic. For hardware it is very close to reinitiating decoding -
> > it needs to be done on an I-frame, the header needs to be present.
> > Otherwise some buffers would be lost and corruption would be
> introduced (lack of reference frames).
> >
> > I think you mentioned negotiating the number of buffers? Did you use
> > the V4L2_CID_MIN_BUFFERS_FOR_CAPTURE control?
> >
> > I understand that before calling REQBUFS(N) with the new N value you
> > properly unmap the buffers just like the documentation is telling?
> >
> > "Applications can call VIDIOC_REQBUFS again to change the number of
> > buffers, however this cannot succeed when any buffers are still
> > mapped. A count value of zero frees all buffers, after aborting or
> > finishing any DMA in progress, an implicit VIDIOC_STREAMOFF." [1]
> >
> > Could you t

Re: strange empia device

[Andy Walls]

On September 2, 2014 2:28:23 AM EDT, Lorenzo Marcantonio 
 wrote:
>On Mon, Sep 01, 2014 at 07:58:52PM -0400, Andy Walls wrote:
>> A Merlin firmware of 16 kB strongly suggests that this chip has an
>> integarted Conexant CX25843 (Merlin Audio + Thresher Video = Mako)
>> Broadtcast A/V decoder core.  The chip might only have a Merlin
>> integrated, but so far I've never encountered that.  It will be easy
>> enough to tell, if the Thresher registers don't respond or only
>respond
>> with junk.
>
>However I strongly suspect that these drivers are for a whole *family*
>of empia device. The oem ini by roxio talks about three different
>parts... probably they give one sys file for everyone and the oem
>customizes the ini.
>
>In short the merlin fw may not be actually used for *this* part but
>only
>for other empia devices/configurations.
>
>Otherwise I wonder *why* a fscking 1.5MB of sys driver for a mostly
>dumb
>capture device...

Yeah.  I guess you can analyze the USB captures of the Windows driver and see 
if it looks like cx25843 registers are being accessed.  If so, you are that 
much closer to a working linux driver.  If not, you still have an unknown 
decoder as a big hurdle.

Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: s5p-mfc should allow multiple call to REQBUFS before we start streaming

[Nicolas Dufresne]

Le 2014-09-02 05:02, Kamil Debski a écrit

This limitation in MFC causes an important conflict between old
videobuf and new videobuf2 drivers. Old videobuf driver (before Hans G.
proposed
patch) refuse REQBUFS(0). As MFC code has this bug that refuse
REBBUFS(N) if buffers are already allocated, it makes all this
completely incompatible. This open_mfc call seems to be the only reason
REQBUFS() cannot be called multiple time, though I must say you are
better placed then me to figure this out.

After MFCs decoding is initialized it has a fixed number of buffers.
Changing
this can be done when the stream changes its properties and resolution
change is initiated. Even then all buffers have to be
unmapped/reallocated/mapped.

There is a single hardware call that is a part of hardware initialization
that sets the buffers' addresses.

Changing the number of buffers during decoding without explicit reason to do
so (resolution change/stream properties change) would be problematic. For
hardware it is very close to reinitiating decoding - it needs to be done on
an I-frame, the header needs to be present. Otherwise some buffers would be
lost and corruption would be introduced (lack of reference frames).

I think you mentioned negotiating the number of buffers? Did you use the
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE control?
That is true, though the issue isn't there. Let's say you haven't 
started decoding yet. You do REQBUFS(2). because the hardware need that. 
Then  before you start anything else, the topology of your display path 
is change, and the application need an extra 2 buffers to work properly. 
With all other drivers, all we'd have to do is REQBUFS(5), with MFC we 
would need to do REQBUFS(0) and then REQBUFS(5). This is a bug, there is 
no reason to force this extra step.


I understand that before calling REQBUFS(N) with the new N value you
properly
unmap the buffers just like the documentation is telling?

As describe in the scenario, nothing has been mapped yet.


"Applications can call VIDIOC_REQBUFS again to change the number of buffers,
however this cannot succeed when any buffers are still mapped. A count value
of zero frees all buffers, after aborting or finishing any DMA in progress,
an implicit VIDIOC_STREAMOFF." [1]
As you can see, the spec says it can be changed, having this extra step 
to change it does not seems compliant to me, at least it's not consistent.



cheers,
Nicolas
--
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

Corrupt images, when capturing images from multiple cameras using the V4L2 driver

[Mácha , Karel]

Hello, 

I would like to grab images from multiple cameras under using the V4L2
API. I followed the presentation under found on
http://linuxtv.org/downloads/presentations/summit_jun_2010/20100206-fosdem.pdf 
used the code and adapted it sightly for my purpose. It works very well
for 1 camera.

However Once I begin to grab images from multiple cameras (successively)
I get corrupt images. I uploaded an example image to
http://www.directupload.net/file/d/3733/9c4jx3pv_png.htm

Although I set the right resolution for the camera (744 x 480), the
output of buffer.bytesused, after the VIDIOC_DQBUF does not correspond
with the expected value (744x480 = 357120). This would probably explain
the corrupt images.

The more camera I use, the less buffer.bytesused I get and the more
stripes are in the image. Could you please give me a hint, what am I
doing wrong ?

Thanks, Karel

Here is the minimal C code I use for my application:


int main()
{
/* # INIT # */

int numOfCameras = 6;
int xRes = 744;
int yRes = 480;
int exposure = 2000;
unsigned int timeBetweenSnapshots = 2; // in sec
char fileName[sizeof "./output/image 000 from camera 0.PNG"];

static const char *devices[] = { "/dev/video0", "/dev/video1",
"/dev/video2", "/dev/video3", "/dev/video4", "/dev/video5",
"/dev/video6", "/dev/video7" };

struct v4l2_capability cap[8];
struct v4l2_control control[8];
struct v4l2_format format[8];
struct v4l2_requestbuffers req[8];
struct v4l2_buffer buffer[8];

int type = V4L2_BUF_TYPE_VIDEO_CAPTURE; // had to declare the type here
because of the loop

unsigned int i;
unsigned int j;
unsigned int k;

int fd[8];
void **mem[8];
//unsigned char **mem[8];

/* # OPEN DEVICE # */

for (j = 0; j < numOfCameras; ++j) {

fd[j] = open(devices[j], O_RDWR);
ioctl(fd[j], VIDIOC_QUERYCAP, &cap[j]);


/* # CAM CONTROLL ### */

control[j].id = V4L2_CID_EXPOSURE_AUTO;
control[j].value = V4L2_EXPOSURE_SHUTTER_PRIORITY;
ioctl(fd[j], VIDIOC_S_CTRL, &control[j]);

control[j].id = V4L2_CID_EXPOSURE_ABSOLUTE;
control[j].value = exposure;
ioctl(fd[j], VIDIOC_S_CTRL, &control[j]);

/* # FORMAT # */

ioctl(fd[j], VIDIOC_G_FMT, &format[j]);
format[j].type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
format[j].fmt.pix.width = xRes;
format[j].fmt.pix.height = yRes;
//format.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV;
format[j].fmt.pix.pixelformat = V4L2_PIX_FMT_GREY;
ioctl(fd[j], VIDIOC_S_FMT, &format[j]);

/* # REQ BUF  */

req[j].type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
req[j].count = 4;
req[j].memory = V4L2_MEMORY_MMAP;
ioctl(fd[j], VIDIOC_REQBUFS, &req[j]);
mem[j] = malloc(req[j].count * sizeof(*mem));

/* # MMAP # */

for (i = 0; i < req[j].count; ++i) {
buffer[j].type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buffer[j].memory = V4L2_MEMORY_MMAP;
buffer[j].index = i;
ioctl(fd[j], VIDIOC_QUERYBUF, &buffer[j]);
mem[j][i] = mmap(0, buffer[j].length,
PROT_READ|PROT_WRITE,
MAP_SHARED, fd[j], buffer[j].m.offset);
}

/* # CREATE QUEUE ### */

for (i = 0; i < req[j].count; ++i) {
buffer[j].type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buffer[j].memory = V4L2_MEMORY_MMAP;
buffer[j].index = i;
ioctl(fd[j], VIDIOC_QBUF, &buffer[j]);
}

} /* ### ### end of camera init ### ### */

/* # STREAM ON # */
for (j = 0; j < numOfCameras; ++j) {

ioctl(fd[j], VIDIOC_STREAMON, &type);
}


/* # GET FRAME # */

k = 0;
while (!kbhit()){
k ++;

for (j = 0; j < numOfCameras; j++) {

buffer[j].type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buffer[j].memory = V4L2_MEMORY_MMAP;
usleep(10);
ioctl(fd[j], VIDIOC_DQBUF, &buffer[j]);
printf("\nBuffer {%p}, Buf.

Re: [ANNOUNCE] Linux Kernel Media mini-summit on Oct, 16-17 in Düsseldorf, Germany

[Mauro Carvalho Chehab]

Em Tue, 02 Sep 2014 12:03:34 +0200
Philipp Zabel  escreveu:

> Hi,
> 
> Am Mittwoch, den 13.08.2014, 10:14 -0300 schrieb Mauro Carvalho Chehab:
> > Hi,
> > 
> > As there are still too things to be discussed in order to improve media
> > stuff, and most of the developers nowadays are located in Europe and
> > usually go to ELCE, we're scheduling a two day mini-summit in Düsseldorf,
> > Germany, on Thrusday/Friday.
> 
> Is this a tentative schedule, or is the date set? I.e. can I book a
> hotel until Friday now and not worry about having to reschedule?

It is all set.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 27/35] [media] s5p-jpeg: Get rid of a warning

[Kamil Debski]

Hi Mauro,

A subsequent patch by Jacek Anaszewski [1] is resoling this problem in
a better way. If you don't mind I will take his patch.

[1] [1/4] s5p-jpeg: Avoid assigning readl result
https://patchwork.linuxtv.org/patch/25661/

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland


> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
> Sent: Tuesday, August 26, 2014 11:55 PM
> 
> drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c: In function
> 's5p_jpeg_clear_int':
> drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c:327:16: warning: variable
> 'reg' set but not used [-Wunused-but-set-variable]
>   unsigned long reg;
> ^
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c
> b/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c
> index 52407d790726..0d37bed088df 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c
> @@ -326,7 +326,7 @@ void s5p_jpeg_clear_int(void __iomem *regs)  {
>   unsigned long reg;
> 
> - reg = readl(regs + S5P_JPGINTST);
> + readl(regs + S5P_JPGINTST);
>   writel(S5P_INT_RELEASE, regs + S5P_JPGCOM);
>   reg = readl(regs + S5P_JPGOPR);
>  }
> --
> 1.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 27/35] [media] s5p-jpeg: Get rid of a warning

[Mauro Carvalho Chehab]

Em Tue, 02 Sep 2014 15:02:43 +0200
Kamil Debski  escreveu:

> Hi Mauro,
> 
> A subsequent patch by Jacek Anaszewski [1] is resoling this problem in
> a better way. If you don't mind I will take his patch.

No Problem.

> [1] [1/4] s5p-jpeg: Avoid assigning readl result
> https://patchwork.linuxtv.org/patch/25661/
> 
> Best wishes,

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ADV76xx : Endpoint parsing

[Jean-Michel Hautbois]

Hi,

I am trying to understand how endpoint parsing is done in adv7604/11
and the main objective is to get adv7604 endpoint parsing from DT for
all its ports (4 HDMI and one VGA as input, one output).
I am stuck on the function adv7604_parse_dt().
Tell me if I am wrong, but this function takes the first endpoint from
DT, puts the node, and that's all...

At least for ADV7611, there is two endpoints : one HDMI as input, one output.
I am not even sure that this function gets both...

And last but not least, how can we get support for all endpoints in
the ADV7604 case ?

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] media: fix kernel deadlock due to tuner pull-out while playing

[Mauro Carvalho Chehab]

Hi Changbing,

All 3 patches on this series seem OK on my eyes. I'll do some tests with them
and see what happens.

Yet, there are some issues on the way you're sending the patches.

First of all, it seems that patchwork is messing with your From:, removing
your name. I just fixed it there.

Em Thu, 21 Aug 2014 10:04:25 +0800
Changbing Xiong  escreveu:

> Enviroment: odroidx2 + Hauppauge(WinTV-Aero-M)
> Normally, ADAP_STREAMING bit is set in dvb_usb_start_feed and cleared in 
> dvb_usb_stop_feed.
> But in exceptional cases, for example, when the tv is playing programs, and 
> the tuner is pulled out.
> then dvb_usbv2_disconnect is called, it will first call 
> dvb_usbv2_adapter_frontend_exit to stop
> dvb_frontend_thread, and then call dvb_usbv2_adapter_dvb_exit to clear 
> ADAP_STREAMING bit, At this point,
> if dvb_frontend_thread is sleeping and wait for ADAP_STREAMING to be cleared 
> to get out of sleep.
> then dvb_frontend_thread can never be stoped, because clearing ADAP_STREAMING 
> bit is performed after
> dvb_frontend_thread is stopped(i.e. performed in dvb_usbv2_adapter_dvb_exit), 
> So deadlock becomes true.

Second, please avoid big lines and just one paragraph. I rewrote this.

It is really boring and harder to understand when it is like that. Also,
we generally use no more than 72 cols on the patches, as we want to be
able to read them well with 80 cols standard tty terminals.

See the patch that will be merged.

>  drivers/media/usb/dvb-usb-v2/dvb_usb_core.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  mode change 100644 => 100755 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c

Third, why are you changing the mode on all your 3 patches?

It makes no sense to transform a .c file into an exec file.

No need to further action from you, as I already fixed them when
applying, but please fix your environment to avoid future rework
from the maintainers.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange empia device

[Frank Schäfer]

Am 02.09.2014 um 08:28 schrieb Lorenzo Marcantonio:
> On Mon, Sep 01, 2014 at 07:58:52PM -0400, Andy Walls wrote:
>> A Merlin firmware of 16 kB strongly suggests that this chip has an
>> integarted Conexant CX25843 (Merlin Audio + Thresher Video = Mako)
>> Broadtcast A/V decoder core.  The chip might only have a Merlin
>> integrated, but so far I've never encountered that.  It will be easy
>> enough to tell, if the Thresher registers don't respond or only respond
>> with junk.
> However I strongly suspect that these drivers are for a whole *family*
> of empia device. The oem ini by roxio talks about three different
> parts... probably they give one sys file for everyone and the oem
> customizes the ini.
>
> In short the merlin fw may not be actually used for *this* part but only
> for other empia devices/configurations.
>
> Otherwise I wonder *why* a fscking 1.5MB of sys driver for a mostly dumb
> capture device...
Right. There is also no firmware upload in the USB-log I have checked.

Regards,
Frank
--
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

Fwd: Hauppauge WinTV-HVR 1900 high BER and unable to switch to Composite input

[Kaya Saman]

Hi,

a quick update on this one. I found out the image and sound corruption 
seems to be mainly due to the TV Headend plugin.


Using the tool: femon -H

and the output from TV Headend directly it clearly shows that yes there 
is a high BER however, most of it seems to be corrected. The uncorrected 
figure shown in femon seems to be 1958 though on occasion it will jump 
up pretty high.


Viewing through VLC or the browser plugin doesn't seem to be an issue 
however, as the image is pretty stable and clear.


So that simply leaves the remaining issue of accessing the devices 
analog inputs?


Both composite and S-video.

Disabling the running PVR software in this case TVH (as I am also 
testing with MythTV), then running mplayer /dev/video0 on the box simply 
doesn't work:


The direct output is this:

==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 55.52.102 (internal)
Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
==
==
Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
AUDIO: 48000 Hz, 2 ch, s16le, 224.0 kbit/14.58% (ratio: 28000->192000)
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, 
II, III)

==
[AO OSS] audio_setup: Can't open audio device /dev/dsp: No such file or 
directory
[AO_ALSA] alsa-lib: pcm_hw.c:1557:(snd_pcm_hw_open) open 
'/dev/snd/pcmC1D7p' failed (-16): Device or resource busy

[AO_ALSA] alsa-lib: pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
[AO_ALSA] Playback open error: Device or resource busy
AO: [pulse] Init failed: Connection refused
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such 
file or directory)

attempt to connect to server failed
[JACK] cannot open server
[AO SDL] Samplerate: 48000Hz Channels: Stereo Format s16le
[AO_ALSA] alsa-lib: pcm_hw.c:1557:(snd_pcm_hw_open) open 
'/dev/snd/pcmC1D7p' failed (-16): Device or resource busy

[AO_ALSA] alsa-lib: pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
[AO SDL] Unable to open audio: No available audio device
DVB card number must be between 1 and 4
AO: [null] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [x11] 720x480 => 720x540 Planar YV12
Shared memory not supported
Reverting to normal Xlib
[swscaler @ 0x7f1ef7587a00]using unscaled yuv420p -> bgra special converter
A:   0.9 V:   0.8 A-V:  0.101 ct: -0.004   3/  3 ??% ??% ??,?% 1 0
[VD_FFMPEG] DRI failure.
A:  10.8 V:   2.8 A-V:  8.048 ct: -0.086  52/ 52 11% 829%  4.5% 50 0


   
    Your system is too SLOW to play this!  
   

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
  - Try -ao sdl or use the OSS emulation of ALSA.
  - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
  - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
  - Don't try to play a big DVD/DivX on a slow CPU! Try some of the 
lavdopts,

e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
  - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
  - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
  - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.

Xlib:  extension "GLX" missing on display "localhost:10.0".4.5% 53 0


Exiting... (Quit)


Again if I try PVR mode:

 mplayer pvr://dev/video
MPlayer SVN-r37224 (C) 2000-2014 MPlayer Team
210 audio & 441 video codecs
mplayer: could not open config files /home/htpc/.lircrc and /etc/lirc/lircrc
mplayer: No such file or directory
Failed to read LIRC config file ~/.lircrc.

Playing pvr://dev/video.
[v4l2] select channel list europe-east, entries 133
[v4l2] unable to find channel dev/video
[pvr] Using device /dev/video0
[pvr] Detected WinTV HVR-1900 Model 73xxx
[v4l2] Available video inputs: '#0, television' '#1, composite' '#2, 
s-video'

[v4l2] Available audio inputs: '#0, PVRUSB2 Audio'
[v4l2] Available norms: '#0, PAL' '#1, PAL-BG' '#2, PAL-H' '#3, PAL-I' 
'#4, PAL-DK' '#5, SECAM' '#6, SECAM-B' '#7, SECAM-G' '#8, SECAM-H' '#9, 
SECAM-DK' '#10, SECAM-L' '#11, SECAM-Lc'

[v4l2] Using current set frequency 61250, to set channel
[v4l2] unable to find frequency 61250
[pvr] can't set v4l2 settings
Failed to open pvr://dev/

Re: [GIT PULL FINAL 16/21] m88ts2022: rename device state (priv => s)

[Mauro Carvalho Chehab]

Em Fri, 22 Aug 2014 13:58:08 +0300
Antti Palosaari  escreveu:

> I like short names for things which are used everywhere overall the
> driver. Due to that rename device state pointer from 'priv' to 's'.

Please, don't do that. "s" is generally used on several places for string.
If you want a shorter name, call it "st" for example.

Regards,
Mauro

> 
> Signed-off-by: Antti Palosaari 
> ---
>  drivers/media/tuners/m88ts2022.c  | 190 
> +-
>  drivers/media/tuners/m88ts2022_priv.h |   2 +-
>  2 files changed, 96 insertions(+), 96 deletions(-)
> 
> diff --git a/drivers/media/tuners/m88ts2022.c 
> b/drivers/media/tuners/m88ts2022.c
> index f51b107..43856df 100644
> --- a/drivers/media/tuners/m88ts2022.c
> +++ b/drivers/media/tuners/m88ts2022.c
> @@ -19,7 +19,7 @@
>  #include "m88ts2022_priv.h"
>  
>  /* write multiple registers */
> -static int m88ts2022_wr_regs(struct m88ts2022_priv *priv,
> +static int m88ts2022_wr_regs(struct m88ts2022 *s,
>   u8 reg, const u8 *val, int len)
>  {
>  #define MAX_WR_LEN 3
> @@ -28,7 +28,7 @@ static int m88ts2022_wr_regs(struct m88ts2022_priv *priv,
>   u8 buf[MAX_WR_XFER_LEN];
>   struct i2c_msg msg[1] = {
>   {
> - .addr = priv->client->addr,
> + .addr = s->client->addr,
>   .flags = 0,
>   .len = 1 + len,
>   .buf = buf,
> @@ -41,11 +41,11 @@ static int m88ts2022_wr_regs(struct m88ts2022_priv *priv,
>   buf[0] = reg;
>   memcpy(&buf[1], val, len);
>  
> - ret = i2c_transfer(priv->client->adapter, msg, 1);
> + ret = i2c_transfer(s->client->adapter, msg, 1);
>   if (ret == 1) {
>   ret = 0;
>   } else {
> - dev_warn(&priv->client->dev,
> + dev_warn(&s->client->dev,
>   "%s: i2c wr failed=%d reg=%02x len=%d\n",
>   KBUILD_MODNAME, ret, reg, len);
>   ret = -EREMOTEIO;
> @@ -55,7 +55,7 @@ static int m88ts2022_wr_regs(struct m88ts2022_priv *priv,
>  }
>  
>  /* read multiple registers */
> -static int m88ts2022_rd_regs(struct m88ts2022_priv *priv, u8 reg,
> +static int m88ts2022_rd_regs(struct m88ts2022 *s, u8 reg,
>   u8 *val, int len)
>  {
>  #define MAX_RD_LEN 1
> @@ -64,12 +64,12 @@ static int m88ts2022_rd_regs(struct m88ts2022_priv *priv, 
> u8 reg,
>   u8 buf[MAX_RD_XFER_LEN];
>   struct i2c_msg msg[2] = {
>   {
> - .addr = priv->client->addr,
> + .addr = s->client->addr,
>   .flags = 0,
>   .len = 1,
>   .buf = ®,
>   }, {
> - .addr = priv->client->addr,
> + .addr = s->client->addr,
>   .flags = I2C_M_RD,
>   .len = len,
>   .buf = buf,
> @@ -79,12 +79,12 @@ static int m88ts2022_rd_regs(struct m88ts2022_priv *priv, 
> u8 reg,
>   if (WARN_ON(len > MAX_RD_LEN))
>   return -EINVAL;
>  
> - ret = i2c_transfer(priv->client->adapter, msg, 2);
> + ret = i2c_transfer(s->client->adapter, msg, 2);
>   if (ret == 2) {
>   memcpy(val, buf, len);
>   ret = 0;
>   } else {
> - dev_warn(&priv->client->dev,
> + dev_warn(&s->client->dev,
>   "%s: i2c rd failed=%d reg=%02x len=%d\n",
>   KBUILD_MODNAME, ret, reg, len);
>   ret = -EREMOTEIO;
> @@ -94,19 +94,19 @@ static int m88ts2022_rd_regs(struct m88ts2022_priv *priv, 
> u8 reg,
>  }
>  
>  /* write single register */
> -static int m88ts2022_wr_reg(struct m88ts2022_priv *priv, u8 reg, u8 val)
> +static int m88ts2022_wr_reg(struct m88ts2022 *s, u8 reg, u8 val)
>  {
> - return m88ts2022_wr_regs(priv, reg, &val, 1);
> + return m88ts2022_wr_regs(s, reg, &val, 1);
>  }
>  
>  /* read single register */
> -static int m88ts2022_rd_reg(struct m88ts2022_priv *priv, u8 reg, u8 *val)
> +static int m88ts2022_rd_reg(struct m88ts2022 *s, u8 reg, u8 *val)
>  {
> - return m88ts2022_rd_regs(priv, reg, val, 1);
> + return m88ts2022_rd_regs(s, reg, val, 1);
>  }
>  
>  /* write single register with mask */
> -static int m88ts2022_wr_reg_mask(struct m88ts2022_priv *priv,
> +static int m88ts2022_wr_reg_mask(struct m88ts2022 *s,
>   u8 reg, u8 val, u8 mask)
>  {
>   int ret;
> @@ -114,7 +114,7 @@ static int m88ts2022_wr_reg_mask(struct m88ts2022_priv 
> *priv,
>  
>   /* no need for read if whole reg is written */
>   if (mask != 0xff) {
> - ret = m88ts2022_rd_regs(priv, reg, &u8tmp, 1);
> + ret = m88ts2022_rd_regs(s, reg, &u8tmp, 1);
>   if (ret)
>   return ret;
>  
> @@ -123,13 +123,13 @@ static int m88ts2022_wr_reg_mask(struct m88ts2022_priv 
> *priv,
>   val |= u8tmp;
>  

Re: [GIT PULL FINAL 00/21] misc DTV stuff for 3.18

[Mauro Carvalho Chehab]

Em Fri, 22 Aug 2014 13:57:52 +0300
Antti Palosaari  escreveu:

> Moikka
> I picked these from patchwork and this is just final review before
> PULL request I will send very shortly. I don't expect any change
> requests at this late, without a very good reason :)
> 
> However, I could add some tags until Mauro PULLs to master.
> 
> regards
> Antti
> 
> Antti Palosaari (10):
>   dvb-usb-v2: remove dvb_usb_device NULL check
>   msi2500: remove unneeded local pointer on msi2500_isoc_init()
>   m88ts2022: fix 32bit overflow on filter calc
>   m88ts2022: fix coding style issues
>   m88ts2022: rename device state (priv => s)

As I didn't apply the above patch...

>   m88ts2022: clean up logging
>   m88ts2022: convert to RegMap I2C API
>   m88ts2022: change parameter type of m88ts2022_cmd

Those tree patches also didn't apply.

>   m88ds3103: change .set_voltage() implementation
>   m88ds3103: fix coding style issues
> 
> CrazyCat (1):
>   si2168: DVB-T2 PLP selection implemented
> 
> Olli Salonen (9):
>   si2168: clean logging
>   si2157: clean logging
>   si2168: add ts_mode setting and move to si2168_init
>   em28xx: add ts mode setting for PCTV 292e
>   cxusb: add ts mode setting for TechnoTrend CT2-4400
>   sp2: Add I2C driver for CIMaX SP2 common interface module
>   cxusb: Add support for TechnoTrend TT-connect CT2-4650 CI
>   cxusb: Add read_mac_address for TT CT2-4400 and CT2-4650
>   si2157: Add support for delivery system SYS_ATSC
> 
> nibble.max (1):
>   m88ds3103: implement set voltage and TS clock
> 
>  drivers/media/dvb-core/dvb-usb-ids.h   |   1 +
>  drivers/media/dvb-frontends/Kconfig|   7 +
>  drivers/media/dvb-frontends/Makefile   |   1 +
>  drivers/media/dvb-frontends/m88ds3103.c| 101 +--
>  drivers/media/dvb-frontends/m88ds3103.h|  35 ++-
>  drivers/media/dvb-frontends/si2168.c   | 101 ---
>  drivers/media/dvb-frontends/si2168.h   |   6 +
>  drivers/media/dvb-frontends/si2168_priv.h  |   1 +
>  drivers/media/dvb-frontends/sp2.c  | 441 
> +
>  drivers/media/dvb-frontends/sp2.h  |  53 
>  drivers/media/dvb-frontends/sp2_priv.h |  50 
>  drivers/media/tuners/Kconfig   |   1 +
>  drivers/media/tuners/m88ts2022.c   | 355 +--
>  drivers/media/tuners/m88ts2022_priv.h  |   5 +-
>  drivers/media/tuners/si2157.c  |  55 ++--
>  drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c |   2 +-
>  drivers/media/usb/dvb-usb/Kconfig  |   2 +-
>  drivers/media/usb/dvb-usb/cxusb.c  | 128 -
>  drivers/media/usb/dvb-usb/cxusb.h  |   4 +
>  drivers/media/usb/em28xx/em28xx-dvb.c  |   5 +-
>  drivers/media/usb/msi2500/msi2500.c|   9 +-
>  21 files changed, 1022 insertions(+), 341 deletions(-)
>  create mode 100644 drivers/media/dvb-frontends/sp2.c
>  create mode 100644 drivers/media/dvb-frontends/sp2.h
>  create mode 100644 drivers/media/dvb-frontends/sp2_priv.h
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/12] dvbv5 scan tables for Brazil

[Olliver Schinagl]

Ah, you sent this to my +list e-mail, I have a backlog there of 10k 
mails due to a new job there now :)


I pulled from your repository, and pushed it upstream.

Thanks!

Olliver


On 08/31/2014 06:57 PM, Mauro Carvalho Chehab wrote:

Ping.

Em Sun, 27 Jul 2014 22:39:25 -0300
Mauro Carvalho Chehab  escreveu:


Hi Olliver,x

Em Thu, 12 Jun 2014 21:59:13 +0200
Olliver Schinagl  escreveu:


Mauro,

Sorry for my late reply!!

I've tried to merge your patches, but besides some blank line errors, I got:

fatal: cannot convert from true to UTF-8

I upgraded to git 2.0.0 and kept getting the error, atleast for 02.

My git-foo is not strong enough to figure out whats going on here, or if
the error is on my end or not. If it is on your end, could you re-send
the patch series with the correct formatting?


Weird... the patches are already in UTF-8. I just re-checked and
applied them without any issue. I didn't even get any blank line errors.

I suspect that something got mangled when you saved the patches from a
file.

I'm enclosing a tarball with all of them. As the patches are using
UTF-8 encoding (due to the name of the Brazilian cities and due to
the channel names that have accents), you need to be sure that you're
using UTF-8 on your distribution.

Here, I'm using:

LANG=pt_BR.UTF-8

On my environment, to be sure that my charset is UTF-8.

Anyway, you can also pull from my git tree directly with:
git pull git://linuxtv.org/mchehab/dtv-scan-tables.git

It will miss your SOB on the patches, though, but you can sign
them either with git rebase or with git filter, with something like:

$ git branch base
$ git pull git://linuxtv.org/mchehab/dtv-scan-tables.git
$ git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: Olliver Schinagl 
"' base..HEAD
$ git branch -d base


Regards,
Mauro


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 1/2] tw68: add support for Techwell tw68xx PCI grabber boards

[Mauro Carvalho Chehab]

Em Tue, 26 Aug 2014 08:33:12 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Add support for the tw68 driver. The driver has been out-of-tree for many
> years on gitorious: https://gitorious.org/tw68/tw68-v2
> 
> I have refactored and ported that driver to the latest V4L2 core frameworks.
> 
> Tested with my Techwell tw6805a and tw6816 grabber boards.
> 
> Signed-off-by: Hans Verkuil 

I would be expecting here the  William M. Brack's SOB too.

Also, the best is to add his original work on one patch (without Kbuild
stuff) and your changes on a separate patch. That helps us to identify
what are your contributions to his code, and what was his original
copyright wording.

> ---
>  drivers/media/pci/Kconfig   |1 +
>  drivers/media/pci/Makefile  |1 +
>  drivers/media/pci/tw68/Kconfig  |   10 +
>  drivers/media/pci/tw68/Makefile |3 +
>  drivers/media/pci/tw68/tw68-core.c  |  434 ++
>  drivers/media/pci/tw68/tw68-reg.h   |  195 +++
>  drivers/media/pci/tw68/tw68-risc.c  |  230 
>  drivers/media/pci/tw68/tw68-video.c | 1060 
> +++
>  drivers/media/pci/tw68/tw68.h   |  231 
>  9 files changed, 2165 insertions(+)
>  create mode 100644 drivers/media/pci/tw68/Kconfig
>  create mode 100644 drivers/media/pci/tw68/Makefile
>  create mode 100644 drivers/media/pci/tw68/tw68-core.c
>  create mode 100644 drivers/media/pci/tw68/tw68-reg.h
>  create mode 100644 drivers/media/pci/tw68/tw68-risc.c
>  create mode 100644 drivers/media/pci/tw68/tw68-video.c
>  create mode 100644 drivers/media/pci/tw68/tw68.h
> 
> diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
> index 5c16c9c..9332807 100644
> --- a/drivers/media/pci/Kconfig
> +++ b/drivers/media/pci/Kconfig
> @@ -20,6 +20,7 @@ source "drivers/media/pci/ivtv/Kconfig"
>  source "drivers/media/pci/zoran/Kconfig"
>  source "drivers/media/pci/saa7146/Kconfig"
>  source "drivers/media/pci/solo6x10/Kconfig"
> +source "drivers/media/pci/tw68/Kconfig"
>  endif
>  
>  if MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT
> diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
> index dc2ebbe..73d9c0f 100644
> --- a/drivers/media/pci/Makefile
> +++ b/drivers/media/pci/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_VIDEO_CX88) += cx88/
>  obj-$(CONFIG_VIDEO_BT848) += bt8xx/
>  obj-$(CONFIG_VIDEO_SAA7134) += saa7134/
>  obj-$(CONFIG_VIDEO_SAA7164) += saa7164/
> +obj-$(CONFIG_VIDEO_TW68) += tw68/
>  obj-$(CONFIG_VIDEO_MEYE) += meye/
>  obj-$(CONFIG_STA2X11_VIP) += sta2x11/
>  obj-$(CONFIG_VIDEO_SOLO6X10) += solo6x10/
> diff --git a/drivers/media/pci/tw68/Kconfig b/drivers/media/pci/tw68/Kconfig
> new file mode 100644
> index 000..5425ba1
> --- /dev/null
> +++ b/drivers/media/pci/tw68/Kconfig
> @@ -0,0 +1,10 @@
> +config VIDEO_TW68
> + tristate "Techwell tw68x Video For Linux"
> + depends on VIDEO_DEV && PCI && VIDEO_V4L2
> + select I2C_ALGOBIT
> + select VIDEOBUF2_DMA_SG
> + ---help---
> +   Support for Techwell tw68xx based frame grabber boards.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called tw68.
> diff --git a/drivers/media/pci/tw68/Makefile b/drivers/media/pci/tw68/Makefile
> new file mode 100644
> index 000..3d02f28
> --- /dev/null
> +++ b/drivers/media/pci/tw68/Makefile
> @@ -0,0 +1,3 @@
> +tw68-objs := tw68-core.o tw68-video.o tw68-risc.o
> +
> +obj-$(CONFIG_VIDEO_TW68) += tw68.o
> diff --git a/drivers/media/pci/tw68/tw68-core.c 
> b/drivers/media/pci/tw68/tw68-core.c
> new file mode 100644
> index 000..baf93af
> --- /dev/null
> +++ b/drivers/media/pci/tw68/tw68-core.c
> @@ -0,0 +1,434 @@
> +/*
> + *  tw68-core.c
> + *  Core functions for the Techwell 68xx driver
> + *
> + *  Much of this code is derived from the cx88 and sa7134 drivers, which
> + *  were in turn derived from the bt87x driver.  The original work was by
> + *  Gerd Knorr; more recently the code was enhanced by Mauro Carvalho Chehab,
> + *  Hans Verkuil, Andy Walls and many others.  Their work is gratefully
> + *  acknowledged.  Full credit goes to them - any problems within this code
> + *  are mine.
> + *
> + *  Copyright (C) 2009  William M. Brack
> + *
> + *  Refactored and updated to the latest v4l core frameworks:
> + *
> + *  Copyright (C) 2014 Hans Verkuil 
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#incl

Re: [GIT PULL FOR v3.18] Add vivid test driver, remove old vivi test driver

[Mauro Carvalho Chehab]

Em Fri, 29 Aug 2014 08:30:16 +0200
Hans Verkuil  escreveu:

> Hi Mauro,
> 
> This adds the new vivid driver as a replacement for the old vivi.
> 
> This pull request is identical to the v2 patch series posted earlier:
> 
> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/81354
> 
> except for the final patch that removes the vivi driver which is new to this
> pull request.
> 
> One question: the vivid driver (like the vivi driver) is not build by default.

We should never build a driver by default. What makes sense is to enable
dependent drivers by default, not main ones.

> Should that be changed? In my opinion this driver should be enabled by 
> distros,
> so I am in favor of changing Kconfig. Let me know if you agree and I'll make a
> follow up patch or you can change this yourself.

If you want the distros to enable it, you should talk to the distro
maintainers. I think that, on most, the best way of doing that is to
open bugzillas.

IMHO, it doesn't make sense for distros to enable it at their
mainstream Kernel, but it does make sense for them to enable on
their debug kernels (on distros that provide both, like Fedora).
Just my 2 cents.

But, again, it is up to the distro Kernel maintainer to decide.

Regards,
Mauro
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit b250392f7b5062cf026b1423e27265e278fd6b30:
> 
>   [media] media: ttpci: fix av7110 build to be compatible with 
> CONFIG_INPUT_EVDEV (2014-08-21 15:25:38 -0500)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git vivid2
> 
> for you to fetch changes up to d5f410f54e87ba420de839dec4e806707cc2aff2:
> 
>   vivi: remove driver, it's replaced by vivid. (2014-08-25 13:49:53 +0200)
> 
> 
> Hans Verkuil (13):
>   vb2: fix multiplanar read() with non-zero data_offset
>   vivid.txt: add documentation for the vivid driver
>   vivid: add core driver code
>   vivid: add the control handling code
>   vivid: add the video capture and output parts
>   vivid: add VBI capture and output code
>   vivid: add the kthread code that controls the video rate
>   vivid: add a simple framebuffer device for overlay testing
>   vivid: add the Test Pattern Generator
>   vivid: add support for radio receivers and transmitters
>   vivid: add support for software defined radio
>   vivid: enable the vivid driver
>   vivi: remove driver, it's replaced by vivid.
> 
>  Documentation/video4linux/vivid.txt   | 1109 
> +++
>  drivers/media/platform/Kconfig|   15 +-
>  drivers/media/platform/Makefile   |2 +-
>  drivers/media/platform/vivi.c | 1542 
> -
>  drivers/media/platform/vivid/Kconfig  |   19 +
>  drivers/media/platform/vivid/Makefile |6 +
>  drivers/media/platform/vivid/vivid-core.c | 1390 
> ++
>  drivers/media/platform/vivid/vivid-core.h |  520 
> ++
>  drivers/media/platform/vivid/vivid-ctrls.c| 1502 
> +++
>  drivers/media/platform/vivid/vivid-ctrls.h|   34 ++
>  drivers/media/platform/vivid/vivid-kthread-cap.c  |  885 
> +
>  drivers/media/platform/vivid/vivid-kthread-cap.h  |   26 ++
>  drivers/media/platform/vivid/vivid-kthread-out.c  |  304 +
>  drivers/media/platform/vivid/vivid-kthread-out.h  |   26 ++
>  drivers/media/platform/vivid/vivid-osd.c  |  400 +
>  drivers/media/platform/vivid/vivid-osd.h  |   27 ++
>  drivers/media/platform/vivid/vivid-radio-common.c |  189 
>  drivers/media/platform/vivid/vivid-radio-common.h |   40 ++
>  drivers/media/platform/vivid/vivid-radio-rx.c |  287 
>  drivers/media/platform/vivid/vivid-radio-rx.h |   31 ++
>  drivers/media/platform/vivid/vivid-radio-tx.c |  141 ++
>  drivers/media/platform/vivid/vivid-radio-tx.h |   29 ++
>  drivers/media/platform/vivid/vivid-rds-gen.c  |  165 +++
>  drivers/media/platform/vivid/vivid-rds-gen.h  |   53 +++
>  drivers/media/platform/vivid/vivid-sdr-cap.c  |  499 
> +
>  drivers/media/platform/vivid/vivid-sdr-cap.h  |   34 ++
>  drivers/media/platform/vivid/vivid-tpg-colors.c   |  310 +
>  drivers/media/platform/vivid/vivid-tpg-colors.h   |   64 +++
>  drivers/media/platform/vivid/vivid-tpg.c  | 1439 
> 
>  drivers/media/platform/vivid/vivid-tpg.h  |  438 +++
>  drivers/media/platform/vivid/vivid-vbi-cap.c  |  356 +++
>  drivers/media/platform/vivid/viv

Re: [PATCH 00/12] dvbv5 scan tables for Brazil

[Mauro Carvalho Chehab]

Em Tue, 02 Sep 2014 20:59:13 +0200
Olliver Schinagl  escreveu:

> Ah, you sent this to my +list e-mail, I have a backlog there of 10k 
> mails due to a new job there now :)

Ah! Well, a 10K backlog is not huge... mine is bigger, but what
I do is to split emails on several inboxes, using a sieve filter.

> 
> I pulled from your repository, and pushed it upstream.

Thanks!

> 
> Thanks!
> 
> Olliver
> 
> 
> On 08/31/2014 06:57 PM, Mauro Carvalho Chehab wrote:
> > Ping.
> >
> > Em Sun, 27 Jul 2014 22:39:25 -0300
> > Mauro Carvalho Chehab  escreveu:
> >
> >> Hi Olliver,x
> >>
> >> Em Thu, 12 Jun 2014 21:59:13 +0200
> >> Olliver Schinagl  escreveu:
> >>
> >>> Mauro,
> >>>
> >>> Sorry for my late reply!!
> >>>
> >>> I've tried to merge your patches, but besides some blank line errors, I 
> >>> got:
> >>>
> >>> fatal: cannot convert from true to UTF-8
> >>>
> >>> I upgraded to git 2.0.0 and kept getting the error, atleast for 02.
> >>>
> >>> My git-foo is not strong enough to figure out whats going on here, or if
> >>> the error is on my end or not. If it is on your end, could you re-send
> >>> the patch series with the correct formatting?
> >>
> >> Weird... the patches are already in UTF-8. I just re-checked and
> >> applied them without any issue. I didn't even get any blank line errors.
> >>
> >> I suspect that something got mangled when you saved the patches from a
> >> file.
> >>
> >> I'm enclosing a tarball with all of them. As the patches are using
> >> UTF-8 encoding (due to the name of the Brazilian cities and due to
> >> the channel names that have accents), you need to be sure that you're
> >> using UTF-8 on your distribution.
> >>
> >> Here, I'm using:
> >>
> >> LANG=pt_BR.UTF-8
> >>
> >> On my environment, to be sure that my charset is UTF-8.
> >>
> >> Anyway, you can also pull from my git tree directly with:
> >>git pull git://linuxtv.org/mchehab/dtv-scan-tables.git
> >>
> >> It will miss your SOB on the patches, though, but you can sign
> >> them either with git rebase or with git filter, with something like:
> >>
> >>$ git branch base
> >>$ git pull git://linuxtv.org/mchehab/dtv-scan-tables.git
> >>$ git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: 
> >> Olliver Schinagl "' base..HEAD
> >>$ git branch -d base
> >>
> >>
> >> Regards,
> >> Mauro
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 1/2] tw68: add support for Techwell tw68xx PCI grabber boards

[Hans Verkuil]

On 09/02/2014 09:21 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 26 Aug 2014 08:33:12 +0200
> Hans Verkuil  escreveu:
> 
>> From: Hans Verkuil 
>>
>> Add support for the tw68 driver. The driver has been out-of-tree for many
>> years on gitorious: https://gitorious.org/tw68/tw68-v2
>>
>> I have refactored and ported that driver to the latest V4L2 core frameworks.
>>
>> Tested with my Techwell tw6805a and tw6816 grabber boards.
>>
>> Signed-off-by: Hans Verkuil 
> 
> I would be expecting here the  William M. Brack's SOB too.

Sorry, that's not possible. The only email I have no longer works. I googled
to see if I could find another email without success. I met him years
ago during an ELC and he was a retired engineer, so he may not even be
around anymore. His gitorious.org repo has been inactive for over two years.

> 
> Also, the best is to add his original work on one patch (without Kbuild
> stuff) and your changes on a separate patch. That helps us to identify
> what are your contributions to his code, and what was his original
> copyright wording.

Are you sure you want that in the mainline kernel? His code is in gitorious,
a link to that is in the commit log. I'm not too keen to add code to the
kernel which is promptly being overwritten by another version. An alternative
might be to add a link to that repo to tw68-core.c as well so that it is
not just in the commit log but also in the source code.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 1/2] tw68: add support for Techwell tw68xx PCI grabber boards

[Mauro Carvalho Chehab]

Em Tue, 02 Sep 2014 21:54:24 +0200
Hans Verkuil  escreveu:

> On 09/02/2014 09:21 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 26 Aug 2014 08:33:12 +0200
> > Hans Verkuil  escreveu:
> > 
> >> From: Hans Verkuil 
> >>
> >> Add support for the tw68 driver. The driver has been out-of-tree for many
> >> years on gitorious: https://gitorious.org/tw68/tw68-v2
> >>
> >> I have refactored and ported that driver to the latest V4L2 core 
> >> frameworks.
> >>
> >> Tested with my Techwell tw6805a and tw6816 grabber boards.
> >>
> >> Signed-off-by: Hans Verkuil 
> > 
> > I would be expecting here the  William M. Brack's SOB too.
> 
> Sorry, that's not possible. The only email I have no longer works. I googled
> to see if I could find another email without success. I met him years
> ago during an ELC and he was a retired engineer, so he may not even be
> around anymore. His gitorious.org repo has been inactive for over two years.
> 
> > 
> > Also, the best is to add his original work on one patch (without Kbuild
> > stuff) and your changes on a separate patch. That helps us to identify
> > what are your contributions to his code, and what was his original
> > copyright wording.
> 
> Are you sure you want that in the mainline kernel? His code is in gitorious,
> a link to that is in the commit log. I'm not too keen to add code to the
> kernel which is promptly being overwritten by another version. An alternative
> might be to add a link to that repo to tw68-core.c as well so that it is
> not just in the commit log but also in the source code.

There's no way to warrant that his gitorious repository will stay there
forever. We need to have the reference code somewhere, if something ever
complain about copyrights, especially since you're not able to contact
the author of the driver.

> 
> Regards,
> 
>   Hans
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git:media_tree/master] [media] atmel-isi: Fix a truncate warning

[Guennadi Liakhovetski]

On Tue, 26 Aug 2014, Mauro Carvalho Chehab wrote:

> This is an automatic generated email to let you know that the following patch 
> were queued at the 
> http://git.linuxtv.org/media_tree.git tree:
> 
> Subject: [media] atmel-isi: Fix a truncate warning
> Author:  Mauro Carvalho Chehab 
> Date:Fri Aug 22 05:53:27 2014 -0500
> 
>drivers/media/platform/soc_camera/atmel-isi.c: In function 
> 'start_streaming':
>drivers/media/platform/soc_camera/atmel-isi.c:397:26: warning: large 
> integer implicitly truncated to unsigned type [-Woverflow]
>  isi_writel(isi, ISI_INTDIS, ~0UL);
>  ^
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Mauro Carvalho Chehab 
> 
>  drivers/media/platform/soc_camera/atmel-isi.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> ---
> 
> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=9842a417d46bf40f2d460120016b6392d3ac32c9
> 
> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
> b/drivers/media/platform/soc_camera/atmel-isi.c
> index f87012b..96a4b11 100644
> --- a/drivers/media/platform/soc_camera/atmel-isi.c
> +++ b/drivers/media/platform/soc_camera/atmel-isi.c
> @@ -394,7 +394,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned 
> int count)
>   return ret;
>   }
>   /* Disable all interrupts */
> - isi_writel(isi, ISI_INTDIS, ~0UL);
> + isi_writel(isi, ISI_INTDIS, (u32)~0UL);

Uhm... Wouldn't it have been much better to just remove the 'L' above to 
make it "~0U" ?.. Too late, I guess.

Thanks
Guennadi

>  
>   spin_lock_irq(&isi->lock);
>   /* Clear any pending interrupt */
> 
> ___
> linuxtv-commits mailing list
> linuxtv-comm...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
> 
--
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

[linuxtv-media:master 495/499] drivers/media/platform/vivid/vivid-core.c:834:2: error: implicit declaration of function 'vzalloc'

[kbuild test robot]

Hi Hans,

First bad commit (maybe != root cause):

tree:   git://linuxtv.org/media_tree.git master
head:   6c1c423a54b5b3a6c9c9561c7ef32aee0fda7253
commit: e75420dd25bc9d7b6f4e3b4c4f6c778b610c8cda [495/499] [media] vivid: 
enable the vivid driver
config: make ARCH=ia64 allmodconfig

All error/warnings:

   drivers/media/platform/vivid/vivid-core.c: In function 
'vivid_create_instance':
>> drivers/media/platform/vivid/vivid-core.c:834:2: error: implicit declaration 
>> of function 'vzalloc' [-Werror=implicit-function-declaration]
 dev->scaled_line = vzalloc(MAX_ZOOM * MAX_WIDTH);
 ^
>> drivers/media/platform/vivid/vivid-core.c:834:19: warning: assignment makes 
>> pointer from integer without a cast
 dev->scaled_line = vzalloc(MAX_ZOOM * MAX_WIDTH);
  ^
>> drivers/media/platform/vivid/vivid-core.c:837:20: warning: assignment makes 
>> pointer from integer without a cast
 dev->blended_line = vzalloc(MAX_ZOOM * MAX_WIDTH);
   ^
>> drivers/media/platform/vivid/vivid-core.c:842:2: error: implicit declaration 
>> of function 'vmalloc' [-Werror=implicit-function-declaration]
 dev->edid = vmalloc(256 * 128);
 ^
>> drivers/media/platform/vivid/vivid-core.c:842:12: warning: assignment makes 
>> pointer from integer without a cast
 dev->edid = vmalloc(256 * 128);
   ^
>> drivers/media/platform/vivid/vivid-core.c:1276:2: error: implicit 
>> declaration of function 'vfree' [-Werror=implicit-function-declaration]
 vfree(dev->scaled_line);
 ^
   cc1: some warnings being treated as errors
--
   drivers/media/platform/vivid/vivid-vbi-gen.c: In function 
'vivid_vbi_gen_sliced':
>> drivers/media/platform/vivid/vivid-vbi-gen.c:206:2: error: implicit 
>> declaration of function 'memset' [-Werror=implicit-function-declaration]
 memset(vbi->data, 0, sizeof(vbi->data));
 ^
>> drivers/media/platform/vivid/vivid-vbi-gen.c:206:2: warning: incompatible 
>> implicit declaration of built-in function 'memset'
   cc1: some warnings being treated as errors
--
   drivers/media/platform/vivid/vivid-vid-cap.c: In function 
'vidioc_s_fmt_vid_overlay':
>> drivers/media/platform/vivid/vivid-vid-cap.c:1109:3: error: implicit 
>> declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
  new_bitmap = vzalloc(bitmap_size);
  ^
>> drivers/media/platform/vivid/vivid-vid-cap.c:1109:14: warning: assignment 
>> makes pointer from integer without a cast
  new_bitmap = vzalloc(bitmap_size);
 ^
>> drivers/media/platform/vivid/vivid-vid-cap.c:1114:4: error: implicit 
>> declaration of function 'vfree' [-Werror=implicit-function-declaration]
   vfree(new_bitmap);
   ^
   cc1: some warnings being treated as errors
--
   drivers/media/platform/vivid/vivid-rds-gen.c: In function 
'vivid_rds_gen_fill':
>> drivers/media/platform/vivid/vivid-rds-gen.c:158:3: error: implicit 
>> declaration of function 'strlcpy' [-Werror=implicit-function-declaration]
  strlcpy(rds->radiotext,
  ^
   cc1: some warnings being treated as errors
--
   drivers/media/platform/vivid/vivid-tpg.c: In function 'tpg_alloc':
>> drivers/media/platform/vivid/vivid-tpg.c:125:4: error: implicit declaration 
>> of function 'vzalloc' [-Werror=implicit-function-declaration]
   tpg->lines[pat][plane] = vzalloc(max_w * 2 * pixelsz);
   ^
>> drivers/media/platform/vivid/vivid-tpg.c:125:27: warning: assignment makes 
>> pointer from integer without a cast
   tpg->lines[pat][plane] = vzalloc(max_w * 2 * pixelsz);
  ^
>> drivers/media/platform/vivid/vivid-tpg.c:133:29: warning: assignment makes 
>> pointer from integer without a cast
  tpg->contrast_line[plane] = vzalloc(max_w * pixelsz);
^
>> drivers/media/platform/vivid/vivid-tpg.c:136:26: warning: assignment makes 
>> pointer from integer without a cast
  tpg->black_line[plane] = vzalloc(max_w * pixelsz);
 ^
>> drivers/media/platform/vivid/vivid-tpg.c:139:27: warning: assignment makes 
>> pointer from integer without a cast
  tpg->random_line[plane] = vzalloc(max_w * pixelsz);
  ^
   drivers/media/platform/vivid/vivid-tpg.c: In function 'tpg_free':
>> drivers/media/platform/vivid/vivid-tpg.c:153:4: error: implicit declaration 
>> of function 'vfree' [-Werror=implicit-function-declaration]
   vfree(tpg->lines[pat][plane]);
   ^
   cc1: some warnings being treated as errors

vim +/vzalloc +834 drivers/media/platform/vivid/vivid-core.c

c88a96b0 Hans Verkuil 2014-08-25  828
V4L2_CAP_READWRITE;
c88a96b0 Hans Verkuil 2014-08-25  829  
c88a96b0 Hans Verkuil 2014-08-25  830   /* initialize the test pattern 
generator */
c88a96b0 Hans Verkuil 2014-08-25  831   tpg_init(&dev->tpg, 640, 360);
c88a96b0 Hans Verkuil 2014-08-25  832   if (tpg_alloc(&dev->tpg, MAX_ZOOM * 
MAX_WIDTH))
c88a96b0 Hans Verkuil 2014-08-25  833   got

Re: [PATCHv3 1/2] tw68: add support for Techwell tw68xx PCI grabber boards

[Hans Verkuil]

On 09/02/2014 10:23 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 02 Sep 2014 21:54:24 +0200
> Hans Verkuil  escreveu:
> 
>> On 09/02/2014 09:21 PM, Mauro Carvalho Chehab wrote:
>>> Em Tue, 26 Aug 2014 08:33:12 +0200
>>> Hans Verkuil  escreveu:
>>>
 From: Hans Verkuil 

 Add support for the tw68 driver. The driver has been out-of-tree for many
 years on gitorious: https://gitorious.org/tw68/tw68-v2

 I have refactored and ported that driver to the latest V4L2 core 
 frameworks.

 Tested with my Techwell tw6805a and tw6816 grabber boards.

 Signed-off-by: Hans Verkuil 
>>>
>>> I would be expecting here the  William M. Brack's SOB too.
>>
>> Sorry, that's not possible. The only email I have no longer works. I googled
>> to see if I could find another email without success. I met him years
>> ago during an ELC and he was a retired engineer, so he may not even be
>> around anymore. His gitorious.org repo has been inactive for over two years.
>>
>>>
>>> Also, the best is to add his original work on one patch (without Kbuild
>>> stuff) and your changes on a separate patch. That helps us to identify
>>> what are your contributions to his code, and what was his original
>>> copyright wording.
>>
>> Are you sure you want that in the mainline kernel? His code is in gitorious,
>> a link to that is in the commit log. I'm not too keen to add code to the
>> kernel which is promptly being overwritten by another version. An alternative
>> might be to add a link to that repo to tw68-core.c as well so that it is
>> not just in the commit log but also in the source code.
> 
> There's no way to warrant that his gitorious repository will stay there
> forever. We need to have the reference code somewhere, if something ever
> complain about copyrights, especially since you're not able to contact
> the author of the driver.

OK, I'll prepare a new pull request tomorrow.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[linux-devel:devel-lkp-ib04-smatch-201409030510 3/5] undefined reference to `__bad_ndelay'

[kbuild test robot]

Hi Wu,

FYI, this happens on a merge commit, which indicates conflicting changes with 
one of the below merged branches.

cb3e62c Merge 'linuxtv-media/master' into devel-lkp-ib04-smatch-201409030510
62091c7 Merge 'net/master' into devel-lkp-ib04-smatch-201409030510
d26ff66 0day base guard for 'devel-lkp-ib04-smatch-201409030510'
69e273c Linux 3.17-rc3


tree:   git://internal_merge_and_test_tree devel-lkp-ib04-smatch-201409030510
head:   16c48c7d573c0aea12ea7f28fa4e5294d78789a7
commit: cb3e62cdd5fcf6a349f21b6dedf27684a20d2a7d [3/5] Merge 
'linuxtv-media/master' into devel-lkp-ib04-smatch-201409030510
config: make ARCH=i386 allyesconfig

All error/warnings:

   drivers/built-in.o: In function `exynos4_jpeg_sw_reset':
>> (.text+0x26d1b40): undefined reference to `__bad_ndelay'
   drivers/built-in.o: In function `omap1_cam_remove':
>> omap1_camera.c:(.text+0x27184b2): undefined reference to `omap_free_dma'
   drivers/built-in.o: In function `set_dma_dest_params':
>> omap1_camera.c:(.text+0x2718e80): undefined reference to 
>> `omap_set_dma_dest_params'
>> omap1_camera.c:(.text+0x2718efb): undefined reference to 
>> `omap_set_dma_transfer_params'
   drivers/built-in.o: In function `start_capture':
>> omap1_camera.c:(.text+0x2719308): undefined reference to `omap_start_dma'
   drivers/built-in.o: In function `suspend_capture':
>> omap1_camera.c:(.text+0x2719ab3): undefined reference to `omap_stop_dma'
   drivers/built-in.o: In function `omap1_cam_probe':
>> omap1_camera.c:(.text+0x271b058): undefined reference to `omap_request_dma'
>> omap1_camera.c:(.text+0x271b0cd): undefined reference to 
>> `omap_set_dma_src_params'
>> omap1_camera.c:(.text+0x271b0eb): undefined reference to 
>> `omap_set_dma_dest_burst_mode'
>> omap1_camera.c:(.text+0x271b106): undefined reference to `omap_dma_link_lch'
>> omap1_camera.c:(.text+0x271b23f): undefined reference to `omap_free_dma'

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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: [GIT PULL FINAL 16/21] m88ts2022: rename device state (priv => s)

[Antti Palosaari]

On 09/02/2014 09:51 PM, Mauro Carvalho Chehab wrote:

Em Fri, 22 Aug 2014 13:58:08 +0300
Antti Palosaari  escreveu:


I like short names for things which are used everywhere overall the
driver. Due to that rename device state pointer from 'priv' to 's'.


Please, don't do that. "s" is generally used on several places for string.
If you want a shorter name, call it "st" for example.


huoh :/
st is not even much better. 'dev' seems to be the 'official' term. I 
will start using it. There is one caveat when 'dev' is used as kernel 
dev_foo() logging requires pointer to device, which is also called dev.


for USB it is: intf->dev
for PCI it is: pci->dev
for I2C it is: client->dev

And you have to store that also your state in order to use logging (and 
usually needed other things too). So for example I2C driver it goes:


struct driver_dev *dev = i2c_get_clientdata(client);
dev_info(&dev->client->dev, "Hello World\n");

Maybe macro needed to shorten that dev_ logging, which takes as a first 
parameter pointer to your own driver state.


I have used that 's' for many of my drivers already and there is likely 
over 50 patches on my queue which needs to be rebased. And rebasing that 
kind of thing for 50 patches is *really* painful, ugh.


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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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:   Wed Sep  3 04:00:21 CEST 2014
git branch: test
git hash:   6c1c423a54b5b3a6c9c9561c7ef32aee0fda7253
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-20-g7abd8a7
host hardware:  x86_64
host os:3.16-1.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: ERRORS
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.32.27-i686: ERRORS
linux-2.6.33.7-i686: ERRORS
linux-2.6.34.7-i686: ERRORS
linux-2.6.35.9-i686: ERRORS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: OK
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: ERRORS
linux-3.12.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16-i686: WARNINGS
linux-3.17-rc1-i686: WARNINGS
linux-2.6.32.27-x86_64: ERRORS
linux-2.6.33.7-x86_64: ERRORS
linux-2.6.34.7-x86_64: ERRORS
linux-2.6.35.9-x86_64: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16-x86_64: WARNINGS
linux-3.17-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API 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: [PATCH v2 1/2] [media] V4L: Add camera pan/tilt speed controls

[Pawel Osciak]

On Sat, Aug 16, 2014 at 4:08 AM, Vincent Palatin  wrote:
>
> The V4L2_CID_PAN_SPEED and V4L2_CID_TILT_SPEED controls allow to move the
> camera by setting its rotation speed around its axis.
>
> Signed-off-by: Vincent Palatin 

Reviewed-by: Pawel Osciak 

>
> ---
> Changes from v1:
> - update the documentation wording according to Pawel suggestion.
>
>  Documentation/DocBook/media/v4l/compat.xml   | 10 ++
>  Documentation/DocBook/media/v4l/controls.xml | 21 +
>  drivers/media/v4l2-core/v4l2-ctrls.c |  2 ++
>  include/uapi/linux/v4l2-controls.h   |  2 ++
>  4 files changed, 35 insertions(+)
>
> diff --git a/Documentation/DocBook/media/v4l/compat.xml 
> b/Documentation/DocBook/media/v4l/compat.xml
> index eee6f0f..21910e9 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2545,6 +2545,16 @@ fields changed from _s32 to _u32.
>
>  
>
> +
> +  V4L2 in Linux 3.17

This will need a bump.

>
> +  
> +   
> + Added V4L2_CID_PAN_SPEED and
> + V4L2_CID_TILT_SPEED camera controls.
> +   
> +  
> +
> +
>  
>Relation of V4L2 to other Linux multimedia APIs
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml 
> b/Documentation/DocBook/media/v4l/controls.xml
> index 47198ee..be88e64 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -3914,6 +3914,27 @@ by exposure, white balance or focus controls.
>   
>   
>
> + 
> +spanname="id">V4L2_CID_PAN_SPEED 
> +   integer
> + This control turns the
> +camera horizontally at the specific speed. The unit is undefined. A
> +positive value moves the camera to the right (clockwise when viewed
> +from above), a negative value to the left. A value of zero stops the motion
> +if one is in progress and has no effect otherwise.
> + 
> + 
> +
> + 
> +spanname="id">V4L2_CID_TILT_SPEED 
> +   integer
> + This control turns the
> +camera vertically at the specified speed. The unit is undefined. A
> +positive value moves the camera up, a negative value down. A value of zero
> +stops the motion if one is in progress and has no effect otherwise.
> + 
> + 
> +
> 
>
>  
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 55c6832..57ddaf4 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -787,6 +787,8 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_AUTO_FOCUS_STOP:  return "Auto Focus, Stop";
> case V4L2_CID_AUTO_FOCUS_STATUS:return "Auto Focus, Status";
> case V4L2_CID_AUTO_FOCUS_RANGE: return "Auto Focus, Range";
> +   case V4L2_CID_PAN_SPEED:return "Pan, Speed";
> +   case V4L2_CID_TILT_SPEED:   return "Tilt, Speed";
>
> /* FM Radio Modulator control */
> /* Keep the order of the 'case's the same as in videodev2.h! */
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index 2ac5597..5576044 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -745,6 +745,8 @@ enum v4l2_auto_focus_range {
> V4L2_AUTO_FOCUS_RANGE_INFINITY  = 3,
>  };
>
> +#define V4L2_CID_PAN_SPEED 
> (V4L2_CID_CAMERA_CLASS_BASE+32)
> +#define V4L2_CID_TILT_SPEED
> (V4L2_CID_CAMERA_CLASS_BASE+33)
>
>  /* FM Modulator class control IDs */
>
> --
> 2.1.0.rc2.206.gedb03e5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] V4L: uvcvideo: Add support for pan/tilt speed controls

[Pawel Osciak]

On Wed, Jul 9, 2014 at 8:49 AM, Vincent Palatin  wrote:
> Map V4L2_CID_TILT_SPEED and V4L2_CID_PAN_SPEED to the standard UVC
> CT_PANTILT_RELATIVE_CONTROL terminal control request.
>
> Tested by plugging a Logitech ConferenceCam C3000e USB camera
> and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
> Verified that it can pan and tilt at the same time in both directions.
>
> Signed-off-by: Vincent Palatin 

Reviewed-by: Pawel Osciak 

> Change-Id: I7b70b228e5c0126683f5f0be34ffd2807f5783dc
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 58 
> +---
>  1 file changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 0eb82106..d703cb0 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -309,9 +309,8 @@ static struct uvc_control_info uvc_ctrls[] = {
> .selector   = UVC_CT_PANTILT_RELATIVE_CONTROL,
> .index  = 12,
> .size   = 4,
> -   .flags  = UVC_CTRL_FLAG_SET_CUR | 
> UVC_CTRL_FLAG_GET_MIN
> -   | UVC_CTRL_FLAG_GET_MAX | 
> UVC_CTRL_FLAG_GET_RES
> -   | UVC_CTRL_FLAG_GET_DEF
> +   .flags  = UVC_CTRL_FLAG_SET_CUR
> +   | UVC_CTRL_FLAG_GET_RANGE
> | UVC_CTRL_FLAG_AUTO_UPDATE,
> },
> {
> @@ -391,6 +390,35 @@ static void uvc_ctrl_set_zoom(struct uvc_control_mapping 
> *mapping,
> data[2] = min((int)abs(value), 0xff);
>  }
>
> +static __s32 uvc_ctrl_get_rel_speed(struct uvc_control_mapping *mapping,
> +   __u8 query, const __u8 *data)
> +{
> +   int first = mapping->offset / 8;
> +   __s8 rel = (__s8)data[first];
> +
> +   switch (query) {
> +   case UVC_GET_CUR:
> +   return (rel == 0) ? 0 : (rel > 0 ? data[first+1]
> +: -data[first+1]);
> +   case UVC_GET_MIN:
> +   return -data[first+1];
> +   case UVC_GET_MAX:
> +   case UVC_GET_RES:
> +   case UVC_GET_DEF:
> +   default:
> +   return data[first+1];
> +   }
> +}
> +
> +static void uvc_ctrl_set_rel_speed(struct uvc_control_mapping *mapping,
> +   __s32 value, __u8 *data)
> +{
> +   int first = mapping->offset / 8;
> +
> +   data[first] = value == 0 ? 0 : (value > 0) ? 1 : 0xff;
> +   data[first+1] = min_t(int, abs(value), 0xff);
> +}
> +
>  static struct uvc_control_mapping uvc_ctrl_mappings[] = {
> {
> .id = V4L2_CID_BRIGHTNESS,
> @@ -677,6 +705,30 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
> .data_type  = UVC_CTRL_DATA_TYPE_SIGNED,
> },
> {
> +   .id = V4L2_CID_PAN_SPEED,
> +   .name   = "Pan (Speed)",
> +   .entity = UVC_GUID_UVC_CAMERA,
> +   .selector   = UVC_CT_PANTILT_RELATIVE_CONTROL,
> +   .size   = 16,
> +   .offset = 0,
> +   .v4l2_type  = V4L2_CTRL_TYPE_INTEGER,
> +   .data_type  = UVC_CTRL_DATA_TYPE_SIGNED,
> +   .get= uvc_ctrl_get_rel_speed,
> +   .set= uvc_ctrl_set_rel_speed,
> +   },
> +   {
> +   .id = V4L2_CID_TILT_SPEED,
> +   .name   = "Tilt (Speed)",
> +   .entity = UVC_GUID_UVC_CAMERA,
> +   .selector   = UVC_CT_PANTILT_RELATIVE_CONTROL,
> +   .size   = 16,
> +   .offset = 16,
> +   .v4l2_type  = V4L2_CTRL_TYPE_INTEGER,
> +   .data_type  = UVC_CTRL_DATA_TYPE_SIGNED,
> +   .get= uvc_ctrl_get_rel_speed,
> +   .set= uvc_ctrl_set_rel_speed,
> +   },
> +   {
> .id = V4L2_CID_PRIVACY,
> .name   = "Privacy",
> .entity = UVC_GUID_UVC_CAMERA,
> --
> 2.0.0.526.g5318336
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v3.18] Add driver for tw68xx PCI grabber boards

[Hans Verkuil]

Hi Mauro,

As requested, this is the same tw68 driver, but it first adds the original tw68
sources from the gitorious repository.

I still disagree with this, I would think that it would be sufficient if the
commit log would state that you checked the original sources and that they were
all GPL. In my view this pollutes the kernel git repository. But it's your call
whether to take my original tw68 pull request or to take this one.

Regards,

Hans

The following changes since commit 6c1c423a54b5b3a6c9c9561c7ef32aee0fda7253:

  [media] vivid: comment the unused g_edid/s_edid functions (2014-09-02 
18:01:05 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tw68b

for you to fetch changes up to 0d96a1b6e48d0eec6a8880c825c1d6e16396c280:

  MAINTAINERS: add tw68 entry (2014-09-03 08:37:23 +0200)


Hans Verkuil (3):
  tw68: add original tw68 code
  tw68: refactor and cleanup the tw68 driver
  MAINTAINERS: add tw68 entry

 MAINTAINERS |8 +
 drivers/media/pci/Kconfig   |1 +
 drivers/media/pci/Makefile  |1 +
 drivers/media/pci/tw68/Kconfig  |   10 +
 drivers/media/pci/tw68/Makefile |3 +
 drivers/media/pci/tw68/tw68-core.c  |  434 
 drivers/media/pci/tw68/tw68-reg.h   |  195 
 drivers/media/pci/tw68/tw68-risc.c  |  230 +++
 drivers/media/pci/tw68/tw68-video.c | 1060 
+++
 drivers/media/pci/tw68/tw68.h   |  231 +++
 10 files changed, 2173 insertions(+)
 create mode 100644 drivers/media/pci/tw68/Kconfig
 create mode 100644 drivers/media/pci/tw68/Makefile
 create mode 100644 drivers/media/pci/tw68/tw68-core.c
 create mode 100644 drivers/media/pci/tw68/tw68-reg.h
 create mode 100644 drivers/media/pci/tw68/tw68-risc.c
 create mode 100644 drivers/media/pci/tw68/tw68-video.c
 create mode 100644 drivers/media/pci/tw68/tw68.h
--
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