From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59497/
Build log: https://builder.linuxtv.org/job/patchwork/20659/
Build time: 00:03:57
Link:
https://lore.kernel.org/linux-media/20191016095738.gb5...@pendragon.ideasonboard.com
gpg: Signature made Wed 16 Oct 2019 09:56
for you to fetch changes up to 3852c5c20448eb08142a9eee6fc6caa12a7d55d8:
staging: media: Make use of devm_platform_ioremap_resource (2019-10-16
12:54:08 +0300)
----
- uvcvideo miscellaneous fixes
- omap4iss miscellaneous
This device does not function correctly in raw mode in kernel
versions validating buffer sizes in bulk mode. It erroneously
announces 16 bits per pixel instead of 12 for NV12 format, so it
needs this quirk to fix computed frame size and avoid legitimate
frames getting discarded.
Signed-off-by: Ser
Laurent,
> Would it make sense to split the calculation from v4l2_fill_pixfmt() to
> a helper function that the UVC driver could call ?
It would of course be possible, and would benefit v4l2-common.c as it
would be common between v4l2_fill_pixfmt() and v4l2_fill_pixfmt_mp(),
but as I noted before
Hi Sergey,
On Wed, Oct 02, 2019 at 09:15:45PM +0400, Sergey Zakharchenko wrote:
> Sergey Zakharchenko :
> > Laurent Pinchart :
> > > Do you think it would make sense to do this by default, without
> > > requiring a quirk ? Or are there cases where this calculation would lead
> > > to incorrect res
Sergey Zakharchenko :
> Laurent Pinchart :
> > Do you think it would make sense to do this by default, without
> > requiring a quirk ? Or are there cases where this calculation would lead
> > to incorrect results while the bpp reported by the camera would be right
> > ?
>
> The loop is a simplified
Hi Laurent,
Laurent Pinchart :
> Do you think it would make sense to do this by default, without
> requiring a quirk ? Or are there cases where this calculation would lead
> to incorrect results while the bpp reported by the camera would be right
> ?
I don't nearly have the experience with a broa
Hi Sergey,
Thank you for the patch.
On Wed, Oct 02, 2019 at 01:01:02PM +, Sergey Zakharchenko wrote:
> This device does not function correctly in raw mode in kernel
> versions validating buffer sizes in bulk mode. It erroneously
> announces 16 bits per pixel instead of 12 for NV12 format, so
This device does not function correctly in raw mode in kernel
versions validating buffer sizes in bulk mode. It erroneously
announces 16 bits per pixel instead of 12 for NV12 format, so it
needs this quirk to fix computed frame size and avoid legitimate
frames getting discarded.
Signed-off-by: Ser
-base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sergey-Zakharchenko/media-uvcvideo-Add-a-quirk-to-force-GEO-GC6500-Camera-bits-per-pixel-value/20191002-185359
base: git://l
This device does not function correctly in raw mode in kernel
versions validating buffer sizes in bulk mode. It erroneously
announces 16 bits per pixel instead of 12 for NV12 format, so it
needs this quirk to fix computed frame size and avoid legitimate
frames getting discarded.
Signed-off-by: Ser
media/master v4l2-compliance on uvcvideo: 52 tests, 0 regressions
(v5.2-rc2-133-g64b42d8eee9b)
Test results summary
V4L2 Compliance on the uvcvideo driver.
This test ran "v4l2-compliance -s" from v4l-utils:
https://www.linuxtv.org/wiki/index.php/V4l2-utils
media/master v4l2-compliance on uvcvideo: 52 tests, 0 regressions
(v5.2-rc2-123-g578a3ab12705)
Test results summary
V4L2 Compliance on the uvcvideo driver.
This test ran "v4l2-compliance -s" from v4l-utils:
https://www.linuxtv.org/wiki/index.php/V4l2-utils
media/master v4l2-compliance on uvcvideo: 52 tests, 0 regressions
(v5.2-rc2-121-g878344de61d0)
Test results summary
V4L2 Compliance on the uvcvideo driver.
This test ran "v4l2-compliance -s" from v4l-utils:
https://www.linuxtv.org/wiki/index.php/V4l2-utils
media/master v4l2-compliance on uvcvideo: 52 tests, 0 regressions
(v5.2-rc2-82-g9bec226d8c79)
Test results summary
V4L2 Compliance on the uvcvideo driver.
This test ran "v4l2-compliance -s" from v4l-utils:
https://www.linuxtv.org/wiki/index.php/V4l2-utils
media/master v4l2-compliance on uvcvideo: 104 tests, 0 regressions
(v5.2-rc2-98-g39cb46751e2f)
Test results summary
V4L2 Compliance on the uvcvideo driver.
This test ran "v4l2-compliance -s" from v4l-utils:
https://www.linuxtv.org/wiki/index.php/V4l2-utils
media/master v4l2-compliance on uvcvideo: 52 tests, 0 regressions
(v5.2-rc2-56-g1e0566fd4a81)
Test results summary
V4L2 Compliance on the uvcvideo driver.
This test ran "v4l2-compliance -s" from v4l-utils:
https://www.linuxtv.org/wiki/index.php/V4l2-utils
media/master v4l2-compliance on uvcvideo: 104 tests, 0 regressions
(media_v5.1-2-16-gfc8670d1f72b)
Test results summary
V4L2 Compliance on the uvcvideo driver.
This test ran "v4l2-compliance -s" from v4l-utils:
https://www.linuxtv.org/wiki/index.php/V4l2-
Hi Edgar,
Thank you for the patch.
On Thu, Jan 10, 2019 at 08:55:31AM +0100, Edgar Thier wrote:
>
> These formats are compressed 12-bit raw bayer formats with four different
> pixel orders. They are similar to 10-bit bayer formats 'IPU3'.
If you want to compare them to other formats, I think th
Copyright texts are deprecated in favour of SPDX headers, replace it.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_ctrl.c | 7 +--
drivers/media/usb/uvc/uvc_debugfs.c | 7 +--
drivers/media/usb/uvc/uvc_driver.c | 7 +--
drivers/media/usb/uvc/uvc_entity.c | 7
Hello,
Any feedback on the patch?
Thank you,
Sergey
On Sun, Mar 17, 2019 at 9:51 AM wrote:
>
> From: Sergey Dorodnicov
>
> Based on section 4.2.2.3.6 of the USB Device Class Definition for Video
> Devices
> and inline with v4l2-ctrls.c, this patch is adding "Auto" to the list of valid
> values
From: Sergey Dorodnicov
Based on section 4.2.2.3.6 of the USB Device Class Definition for Video Devices
and inline with v4l2-ctrls.c, this patch is adding "Auto" to the list of valid
values of the power line frequency control.
Tested on 5.0.0-rc7 using Intel D415 and D435 USB cameras.
Sergey D
> > >> much
> > >> benefit in this case,
> > >
> > > I think it does have a significant benefit. CLOCK_MONOTONIC stops when
> > > the device is sleeping, but the sensors can still capture various
> > > actions. We would lose the time keeping of those actions if we use
> > > CLOCK_MONOTONIC.
> > >
> > >> but it's important than all timestamps use the same
> > >> clock. The question is thus which clock we should select. Mainline
> > >> mostly uses
> > >> CLOCK_MONOTONIC, and Android CLOCK_BOOTTIME. Would you like to submit
> > >> patches
> > >> to switch Android to CLOCK_MONOTONIC ? :-)
> > >
> > > Is it Android using CLOCK_BOOTTIME or the sensors (IIO?). I have
> > > almost zero familiarity with the IIO subsystem and was hoping someone
> > > from there could comment on what time domain is used for those
> > > sensors.
> >
> > IIO has the option to choose between BOOTTIME or MONOTONIC (and a few
> > others) for the timestamp on a per device basis.
> >
> > There was a bit of a discussion about this a while back. See
> > https://lkml.org/lkml/2018/7/10/432 and the following thread.
>
> Given that IIO supports BOOTTIME in upstream already and also the
> important advantage of using it over MONOTONIC for systems which keep
> capturing events during sleep, do you think we could move on with some
> way to support it in uvcvideo or preferably V4L2 in general?
Gentle ping.
Best regards,
Tomasz
gt;> interface - but full frames don't seem appropriate. (not impossible of
> >> course, just is it reasonable?)
> >>
> >> If this is to be enabled, should it be enabled for compressed formats
> >> only? or would that complicate matters?
> >
> >
able?)
>>
>> If this is to be enabled, should it be enabled for compressed formats
>> only? or would that complicate matters?
>
> I've repeatedly refused read() support in uvcvideo for this reason, and
> also because read() doesn't carry framing information very we
usecase for reading compressed data through this
> interface - but full frames don't seem appropriate. (not impossible of
> course, just is it reasonable?)
>
> If this is to be enabled, should it be enabled for compressed formats
> only? or would that complicate matters?
I'v
eue, struct vm_area_struct *vma)
> {
> return vb2_mmap(&queue->queue, vma);
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 84be596..3866832 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uv
drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 84be596..3866832 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -594,7 +594,8 @@ static int uvc_ioctl_querycap(struct file *file, void *fh,
>
e, struct vm_area_struct *vma)
> {
> return vb2_mmap(&queue->queue, vma);
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 84be596..3866832 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/
c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -594,7 +594,8 @@ static int uvc_ioctl_querycap(struct file *file, void *fh,
strscpy(cap->driver, "uvcvideo", sizeof(cap->driver));
strscpy(cap->card, vdev->name, sizeof(cap->card));
usb_make_path(s
Hi dear developers.
I am a happy owner of a laptop HP EliteBook x360 1030 G3 13,3.
Unfortunately the webcam included in the laptop was not recognized in
debian stretch.Being a generic driver the uvc I thought maybe adding
the vendorid and the productid to the driver my webcam would be
supported. S
These formats are compressed 12-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit bayer formats 'IPU3'.
Signed-off-by: Edgar Thier
---
drivers/media/usb/uvc/uvcvideo.h | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/medi
From: Daniel Axtens
[ Upstream commit 10e1fdb95809ed21406f53b5b4f064673a1b9ceb ]
Currently, disconnecting a USB webcam while it is in use prints out a
number of warnings, such as:
WARNING: CPU: 2 PID: 3118 at
/build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237
sysfs_remove_group+0x8b/0x90
sy
From: Daniel Axtens
[ Upstream commit 10e1fdb95809ed21406f53b5b4f064673a1b9ceb ]
Currently, disconnecting a USB webcam while it is in use prints out a
number of warnings, such as:
WARNING: CPU: 2 PID: 3118 at
/build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237
sysfs_remove_group+0x8b/0x90
sy
On Wed, Dec 19, 2018 at 12:16 AM Laurent Pinchart
wrote:
>
> Hi Alistair,
>
> Thank you for the patch.
>
> On Wednesday, 19 December 2018 03:32:48 EET Alistair Strachan wrote:
> > From: Laurent Pinchart
>
> Are you sure you don't want to keep authorship ? I've merely reviewed v1 and
> proposed an
Hi Alistair,
Thank you for the patch.
On Wednesday, 19 December 2018 03:32:48 EET Alistair Strachan wrote:
> From: Laurent Pinchart
Are you sure you don't want to keep authorship ? I've merely reviewed v1 and
proposed an alternative implementation :-) Let me know what you would prefer
and I'l
From: Laurent Pinchart
When initially testing the Camera Terminal Descriptor wTerminalType
field (buffer[4]), no mask is used. Later in the function, the MSB is
overloaded to store the descriptor subtype, and so a mask of 0x7fff
is used to check the type.
If a descriptor is specially crafted to
Hi Laurent,
On Tue, Dec 18, 2018 at 1:42 AM Laurent Pinchart
wrote:
>
> Hi Alistair,
>
> Thank you for the patch.
>
> On Monday, 17 December 2018 23:02:22 EET Alistair Strachan wrote:
> > When initially testing the Camera Terminal Descriptor wTerminalType
> > field (buffer[4]), no mask is used. L
Hi Alistair,
Thank you for the patch.
On Monday, 17 December 2018 23:02:22 EET Alistair Strachan wrote:
> When initially testing the Camera Terminal Descriptor wTerminalType
> field (buffer[4]), no mask is used. Later in the function, the MSB is
> overloaded to store the descriptor subtype, and s
When initially testing the Camera Terminal Descriptor wTerminalType
field (buffer[4]), no mask is used. Later in the function, the MSB is
overloaded to store the descriptor subtype, and so a mask of 0x7fff
is used to check the type.
If a descriptor is specially crafted to set this overloaded bit i
e1b1c84504a76ea48ac0f459c5efb64935dc3dde:
media: uvcvideo: Utilise for_each_uvc_urb iterator (2018-12-04 15:11:15
+0200)
Kieran Bingham (10):
media: uvcvideo: Refactor URB descriptors
media: uvcvideo: Convert decode
Hi Kieran,
Thank you for the patch.
On Friday, 9 November 2018 19:15:42 EET Kieran Bingham wrote:
> Hi Laurent,
>
> I'm sorry - I didn't update the commit message on this one.
>
> On 09/11/2018 17:05, Kieran Bingham wrote:
> > We have both uvc_init_video() and uvc_video_init() calls which can b
Hi Kieran,
On Sunday, 11 November 2018 00:02:39 EET Kieran Bingham wrote:
> Hi Laurent,
>
> I see that you made changes to this patch before accepting it last time.
>
> I'm afraid I haven't made those changes here, so please just cherry-pick
> your previous incarnation. There are no changes here
tream->intf);
> @@ -425,6 +428,14 @@ static struct uvc_streaming *uvc_stream_new(struct
> uvc_device *dev, stream->intf = usb_get_intf(intf);
> stream->intfnum = intf->cur_altsetting->desc.bInterfaceNumber;
>
> + /* Allocate a stream specific work queue
Hi Kieran,
Thank you for the patch.
On Friday, 9 November 2018 19:05:29 EET Kieran Bingham wrote:
> The streaming object is a key part of handling the UVC device. Although
> not critical, we are currently missing a call to destroy the mutex on
> clean up paths, and we are due to extend the object
up to dd3bd1ac29aa9a0f83a55f100e69091c0567a27c:
media: uvcvideo: Refactor teardown of uvc on USB disconnect (2018-11-30
04:12:08 +0200)
Daniel Axtens (1):
media: uvcvideo: Refactor teardown of uvc on USB disconnect
Sergey Dorod
eeping, but the sensors can still capture various
> > actions. We would lose the time keeping of those actions if we use
> > CLOCK_MONOTONIC.
> >
> >> but it's important than all timestamps use the same
> >> clock. The question is thus which clock we should select. Mainline mostly
> >> uses
> >> CLOCK_MONOTONIC, and Android CLOCK_BOOTTIME. Would you like to submit
> >> patches
> >> to switch Android to CLOCK_MONOTONIC ? :-)
> >
> > Is it Android using CLOCK_BOOTTIME or the sensors (IIO?). I have
> > almost zero familiarity with the IIO subsystem and was hoping someone
> > from there could comment on what time domain is used for those
> > sensors.
>
> IIO has the option to choose between BOOTTIME or MONOTONIC (and a few
> others) for the timestamp on a per device basis.
>
> There was a bit of a discussion about this a while back. See
> https://lkml.org/lkml/2018/7/10/432 and the following thread.
Given that IIO supports BOOTTIME in upstream already and also the
important advantage of using it over MONOTONIC for systems which keep
capturing events during sleep, do you think we could move on with some
way to support it in uvcvideo or preferably V4L2 in general?
Best regards,
Tomasz
Hi Laurent,
I see that you made changes to this patch before accepting it last time.
I'm afraid I haven't made those changes here, so please just cherry-pick
your previous incarnation. There are no changes here from me between v5,
and v6.
Regards
--
Kieran
On 09/11/2018 17:05, Kieran Bingham w
Hi Kieran,
Thank you for the patch.
On Friday, 9 November 2018 19:05:28 EET Kieran Bingham wrote:
> The buffer queue interface currently operates sequentially, processing
> buffers after they have fully completed.
>
> In preparation for supporting parallel tasks operating on the buffers,
> we wi
Hi Laurent,
I'm sorry - I didn't update the commit message on this one.
On 09/11/2018 17:05, Kieran Bingham wrote:
> We have both uvc_init_video() and uvc_video_init() calls which can be
> quite confusing to determine the process for each. Now that video
> uvc_video_enable() has been renamed to u
We have both uvc_init_video() and uvc_video_init() calls which can be
quite confusing to determine the process for each. Now that video
uvc_video_enable() has been renamed to uvc_video_start_streaming(),
adapt these calls to suit the new flow.
Rename uvc_init_video() to uvc_video_start() and uvc_u
A new iterator is available for processing UVC URB structures. This
simplifies the processing of the internal stream data.
Convert the manual loop iterators to the new helper, adding an index
helper to keep the existing debug print.
Signed-off-by: Kieran Bingham
---
v6:
- rename lone 'j' iter
The streaming object is a key part of handling the UVC device. Although
not critical, we are currently missing a call to destroy the mutex on
clean up paths, and we are due to extend the objects complexity in the
near future.
Facilitate easy management of a stream object by creating a pair of
func
stream->intfnum = intf->cur_altsetting->desc.bInterfaceNumber;
+ /* Allocate a stream specific work queue for asynchronous tasks. */
+ stream->async_wq = alloc_workqueue("uvcvideo", WQ_UNBOUND | WQ_HIGHPRI,
+ 0);
+ if
uvc_video_enable() is used both to start and stop the video stream
object, however the single function entry point shares no code between
the two operations.
Split the function into two distinct calls, and rename to
uvc_video_start_streaming() and uvc_video_stop_streaming() as
appropriate.
Signed
The URB completion operation obtains the current buffer by reading
directly into the queue internal interface.
Protect this queue abstraction by providing a helper
uvc_queue_get_current_buffer() which can be used by both the decode
task, and the uvc_queue_next_buffer() functions.
Signed-off-by: K
The URB completion handlers currently reference the stream context.
Now that each URB has its own context structure, convert the decode (and
one encode) functions to utilise this context for URB management.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- fix checkpatch w
The buffer queue interface currently operates sequentially, processing
buffers after they have fully completed.
In preparation for supporting parallel tasks operating on the buffers,
we will need to support buffers being processed on multiple CPUs.
Adapt the uvc_queue_next_buffer() such that a re
Both uvc_start_streaming(), and uvc_stop_streaming() are called from
userspace context, with interrupts enabled. As such, they do not need to
save the IRQ state, and can use spin_lock_irq() and spin_unlock_irq()
respectively.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v4:
We currently store three separate arrays for each URB reference we hold.
Objectify the data needed to track URBs into a single uvc_urb structure,
allowing better object management and tracking of the URB.
All accesses to the data pointers through stream, are converted to use a
uvc_urb pointer for
On 09/11/2018 15:41, Philipp Zabel wrote:
> On Wed, 2018-11-07 at 22:25 +0200, Laurent Pinchart wrote:
>> Hi Kieran,
>>
>> On Wednesday, 7 November 2018 16:30:46 EET Kieran Bingham wrote:
>>> On 06/11/2018 23:13, Laurent Pinchart wrote:
On Tuesday, 6 November 2018 23:27:19 EET Kieran Bingham w
On Wed, 2018-11-07 at 22:25 +0200, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Wednesday, 7 November 2018 16:30:46 EET Kieran Bingham wrote:
> > On 06/11/2018 23:13, Laurent Pinchart wrote:
> > > On Tuesday, 6 November 2018 23:27:19 EET Kieran Bingham wrote:
> > > > From: Kieran Bingham
> > > >
Hi Daniel,
Thank you for the patch.
On Sunday, 23 April 2017 07:53:49 EET Daniel Axtens wrote:
> Currently, disconnecting a USB webcam while it is in use prints out a
> number of warnings, such as:
>
> WARNING: CPU: 2 PID: 3118 at
> /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237
> sysfs_re
Hi Kieran,
On Wednesday, 7 November 2018 16:30:46 EET Kieran Bingham wrote:
> On 06/11/2018 23:13, Laurent Pinchart wrote:
> > On Tuesday, 6 November 2018 23:27:19 EET Kieran Bingham wrote:
> >> From: Kieran Bingham
> >>
> >> We have both uvc_init_video() and uvc_video_init() calls which can be
Hi Laurent,
On 06/11/2018 23:13, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 23:27:19 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> We have both uvc_init_video() and uvc_video_init() calls which can be
>> quite confusing to determi
Hi Laurent,
On 06/11/2018 23:21, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 23:27:20 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> A new iterator is available for processing UVC URB structures. This
>> simplifies the processing of
return;
>> }
>> +
>> +queue_work(stream->async_wq, &uvc_urb->work);
>> }
>>
>> /*
>> @@ -1594,20 +1643,22 @@ static int uvc_alloc_urb_buffers(struct
>> uvc_streaming *stream, */
>> static void uvc_uninit
Hi Laurent,
On 06/11/2018 23:08, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 23:27:18 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> uvc_video_enable() is used both to start and stop the video stream
>> object, however the single fu
Hi Kieran,
On Wed, Nov 7, 2018 at 12:13 AM Kieran Bingham
wrote:
>
> Hi Tomasz,
>
> On 07/08/2018 10:54, Tomasz Figa wrote:
> > Hi Kieran,
> >
> > On Wed, Mar 28, 2018 at 1:47 AM Kieran Bingham
> > wrote:
> > [snip]
> >> @@ -1544,25 +1594,29 @@ static int uvc_alloc_urb_buffers(struct
> >> uvc_s
Hi Kieran,
Thank you for the patch.
On Tuesday, 6 November 2018 23:27:20 EET Kieran Bingham wrote:
> From: Kieran Bingham
>
> A new iterator is available for processing UVC URB structures. This
> simplifies the processing of the internal stream data.
>
> Convert the manual loop iterators to th
Hi Kieran,
Thank you for the patch.
On Tuesday, 6 November 2018 23:27:19 EET Kieran Bingham wrote:
> From: Kieran Bingham
>
> We have both uvc_init_video() and uvc_video_init() calls which can be
> quite confusing to determine the process for each. Now that video
> uvc_video_enable() has been r
Hi Kieran,
Thank you for the patch.
On Tuesday, 6 November 2018 23:27:18 EET Kieran Bingham wrote:
> From: Kieran Bingham
>
> uvc_video_enable() is used both to start and stop the video stream
> object, however the single function entry point shares no code between
> the two operations.
>
> Sp
rather than kill them to ensure that even
> + * after the completion handler returns, any asynchronous workqueues
> + * will be prevented from resubmitting the URBs.
> + */
> + for_each_uvc_urb(uvc_urb, stream)
> + us
Hi Kieran,
Thank you for the patch.
On Tuesday, 6 November 2018 23:27:16 EET Kieran Bingham wrote:
> From: Kieran Bingham
>
> The buffer queue interface currently operates sequentially, processing
> buffers after they have fully completed.
>
> In preparation for supporting parallel tasks opera
From: Kieran Bingham
uvc_video_enable() is used both to start and stop the video stream
object, however the single function entry point shares no code between
the two operations.
Split the function into two distinct calls, and rename to
uvc_video_start_streaming() and uvc_video_stop_streaming()
From: Kieran Bingham
A new iterator is available for processing UVC URB structures. This
simplifies the processing of the internal stream data.
Convert the manual loop iterators to the new helper, adding an index
helper to keep the existing debug print.
Signed-off-by: Kieran Bingham
---
This
From: Kieran Bingham
We have both uvc_init_video() and uvc_video_init() calls which can be
quite confusing to determine the process for each. Now that video
uvc_video_enable() has been renamed to uvc_video_start_streaming(),
adapt these calls to suit the new flow.
Rename uvc_init_video() to uvc_
From: Kieran Bingham
The URB completion handlers currently reference the stream context.
Now that each URB has its own context structure, convert the decode (and
one encode) functions to utilise this context for URB management.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
From: Kieran Bingham
We currently store three separate arrays for each URB reference we hold.
Objectify the data needed to track URBs into a single uvc_urb structure,
allowing better object management and tracking of the URB.
All accesses to the data pointers through stream, are converted to us
From: Kieran Bingham
Both uvc_start_streaming(), and uvc_stop_streaming() are called from
userspace context, with interrupts enabled. As such, they do not need to
save the IRQ state, and can use spin_lock_irq() and spin_unlock_irq()
respectively.
Signed-off-by: Kieran Bingham
Reviewed-by: Laure
From: Kieran Bingham
The URB completion operation obtains the current buffer by reading
directly into the queue internal interface.
Protect this queue abstraction by providing a helper
uvc_queue_get_current_buffer() which can be used by both the decode
task, and the uvc_queue_next_buffer() funct
ream->ctrl;
struct uvc_format *format = NULL;
struct uvc_frame *frame = NULL;
+ struct uvc_urb *uvc_urb;
unsigned int i;
int ret;
@@ -2017,6 +2069,16 @@ int uvc_video_init(struct uvc_streaming *stream)
}
}
+
From: Kieran Bingham
The buffer queue interface currently operates sequentially, processing
buffers after they have fully completed.
In preparation for supporting parallel tasks operating on the buffers,
we will need to support buffers being processed on multiple CPUs.
Adapt the uvc_queue_next_
atic void uvc_uninit_video(struct
> uvc_streaming *stream, int free_buffers)
>uvc_urb->urb = NULL;
>}
>
> - if (free_buffers)
> + if (free_buffers) {
>uvc_free_urb_buffers(stream);
> -
> - destroy_workqueu
Hi Laurent,
On 30/07/2018 20:57, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 27 March 2018 19:46:01 EEST Kieran Bingham wrote:
>> Both uvc_start_streaming(), and uvc_stop_streaming() are called from
>> userspace context, with interrupts enabled. As such, the
Hi Laurent,
On 30/07/2018 21:39, Laurent Pinchart wrote:
> Hi Kieran
>
> I think your v4 doesn't take the review comments below into account.
I'm sorry for missing them.
Lets not miss it for v5 :)
>
> On Wednesday, 17 January 2018 01:45:33 EEST Laurent Pinchart wrote:
>> On Friday, 12 January
On 11/01/2018 03:30 PM, Tomasz Figa wrote:
> On Thu, Nov 1, 2018 at 11:03 PM Laurent Pinchart
> wrote:
>>
>> Hi Alexandru,
>>
>> On Thursday, 18 October 2018 20:28:06 EET Alexandru M Stan wrote:
>>> On Wed, Oct 17, 2018 at 9:31 PM, Tomasz Figa wrote:
On Thu, Oct 18, 2018 at 5:50 AM Laurent Pi
On Thu, Nov 1, 2018 at 11:03 PM Laurent Pinchart
wrote:
>
> Hi Alexandru,
>
> On Thursday, 18 October 2018 20:28:06 EET Alexandru M Stan wrote:
> > On Wed, Oct 17, 2018 at 9:31 PM, Tomasz Figa wrote:
> > > On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart wrote:
> > >> On Wednesday, 17 October 2018
Hi Alexandru,
On Thursday, 18 October 2018 20:28:06 EET Alexandru M Stan wrote:
> On Wed, Oct 17, 2018 at 9:31 PM, Tomasz Figa wrote:
> > On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart wrote:
> >> On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote:
> >>> On Wed, Oct 17, 2018 at 5:02 P
gt; I'm fairly sure we don't control the 'IR flash' from the UVC.
>
> I wonder if there is a control parameter for the IR led in the
> extension-units?
>
> --
> Regards
>
> Kieran
>
>
>
> > $ v4l2-ctl --all -d /dev/video2
> > Drive
Hello,
On Tuesday, 30 October 2018 17:48:12 EET Kieran Bingham wrote:
> On 30/10/2018 14:36, Jiri Slaby wrote:
> > Hi,
> >
> > I have a Dell Lattitude 7280 with two webcams. The standard one works
> > fine (/dev/video0). The other one is an IR camera (/dev/video1). The
> > camera proper works fin
m fairly sure we don't control the 'IR flash' from the UVC.
I wonder if there is a control parameter for the IR led in the
extension-units?
--
Regards
Kieran
> $ v4l2-ctl --all -d /dev/video2
> Driver Info (not using libv4l2):
> Driver name : uvcvide
-ctl --all -d /dev/video2
Driver Info (not using libv4l2):
Driver name : uvcvideo
Card type : Integrated_Webcam_HD: Integrate
Bus info : usb-:00:14.0-5
Driver version: 4.18.15
Capabilities : 0x84A1
Video Capture
On Wed, Oct 17, 2018 at 9:31 PM, Tomasz Figa wrote:
> On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart
> wrote:
>>
>> Hi Tomasz,
>>
>> On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote:
>> > On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart wrote:
>> > > On Wednesday, 17 October 2018 1
On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart
wrote:
>
> Hi Tomasz,
>
> On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote:
> > On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart wrote:
> > > On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote:
> > >> Android requires camer
Hi Tomasz,
On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote:
> On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart wrote:
> > On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote:
> >> Android requires camera timestamps to be reported with
> >> CLOCK_BOOTTIME to sync timestamp
Hi Laurent,
On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart
wrote:
>
> Hi Heng-Ruey,
>
> Thank you for the patch.
>
> On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote:
> > Android requires camera timestamps to be reported with
> > CLOCK_BOOTTIME to sync timestamp with other sensor
Hi Heng-Ruey,
Thank you for the patch.
On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote:
> Android requires camera timestamps to be reported with
> CLOCK_BOOTTIME to sync timestamp with other sensor sources.
What's the rationale behind this, why can't CLOCK_MONOTONIC work ? If the
Android requires camera timestamps to be reported with
CLOCK_BOOTTIME to sync timestamp with other sensor sources.
Signed-off-by: Heng-Ruey Hsu
---
drivers/media/usb/uvc/uvc_driver.c | 4
drivers/media/usb/uvc/uvc_video.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/media
On Sun, Sep 30, 2018 at 01:38:16PM +0300, Laurent Pinchart wrote:
> From: ming_qian
>
> commit f620d1d7afc7db57ab59f35000752840c91f67e7 upstream.
>
> The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1.
> Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be
> recogni
1 - 100 of 1487 matches
Mail list logo
