cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Nov 11 05:00:11 CET 2018 media-tree git hash:fbe57dde7126d1b2712ab5ea93fb9d15f89de708 media_build git hash: 3fcf9bbc6ed17fc0986ed8b1296362e75c3e5e3c v4l-utils git hash: dd3ff81f58c4e1e6f33765dc61ad33c48ae6bb07 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-arm-stm32: WARNINGS linux-git-arm64: OK linux-git-i686: WARNINGS linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-sh: OK linux-git-x86_64: WARNINGS Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
RE,
I have a deal for you, in your region.
Re: [RFP] Which V4L2 ioctls could be replaced by better versions?
On Sat, Nov 10, 2018 at 6:06 AM Nicolas Dufresne wrote: > > Le jeudi 08 novembre 2018 à 16:45 +0900, Tomasz Figa a écrit : > > > In this patch we should consider a way to tell userspace that this has > > > been opt in, otherwise existing userspace will have to remain using > > > sub-optimal copy based reclaiming in order to ensure that renegotiation > > > can work on older kernel tool. At worst someone could probably do trial > > > and error (reqbufs(1)/mmap/reqbufs(0)) but on CMA with large buffers > > > this introduces extra startup time. > > > > Would such REQBUFS dance be really needed? Couldn't one simply try > > reqbufs(0) when it's really needed and if it fails then do the copy, > > otherwise just proceed normally? > > In simple program, maybe, in modularized code, where the consumer of > these buffer (the one that is forced to make a copy) does not know the > origin of the DMABuf, it's a bit complicated. > > In GStreamer as an example, the producer is a plugin called > libgstvideo4linux2.so, while the common consumer would be libgstkms.so. > They don't know each other. The pipeline would be described as: > > v4l2src ! kmssink > > GStreamer does not have an explicit reclaiming mechanism. No one knew > about V4L2 restrictions when this was designed, DMABuf didn't exist and > GStreamer didn't have OMX support. > > What we ended up crafting, as a plaster, is that when upstream element > (v4l2src) query a new allocation from downstream (kmssink), we always > copy and return any ancient buffers by copying. kmssink holds on a > buffer because we can't remove the scannout buffer on the display. This > is slow and inefficient, and also totally unneeded if the dmabuf > originate from other kernel subsystems (like DRM). > > So what I'd like to be able to do, to support this in a more optimal > and generic way, is to mark the buffers that needs reclaiming before > letting them go. But for that, I would need a flag somewhere to tell me > this kernel allow this. Okay, got it. Thanks for explaining it. > > You got the context, maybe the conclusion is that I should simply do > kernel version check, though I'm sure a lot of people will backport > this, which means that check won't work so well. > > Let me know, I understand adding more API is not fun, but as nothing is > ever versionned in the linux-media world, it's really hard to detect > and use new behaviour while supporting what everyone currently run on > their systems. > > I would probably try and find a way to implement your suggestion, and > then introduce a flag in the query itself, but I would need to think > about it a little more. It's not as simple as it look like > unfortunately. It sounds like a good fit for a new capability in v4l2_requestbuffers and v4l2_create_buffers structs [1]. Perhaps something like V4L2_BUF_CAP_SUPPORTS_FREE_AFTER_EXPORT? Hans, what do you think? [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/uapi/linux/videodev2.h?h=next-20181109#n866 Best regards, Tomasz
Re: [PATCH v6 08/10] media: uvcvideo: Split uvc_video_enable into two
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 wrote:
> 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-off-by: Kieran Bingham
> ---
> drivers/media/usb/uvc/uvc_queue.c | 4 +-
> drivers/media/usb/uvc/uvc_video.c | 56 +++-
> drivers/media/usb/uvc/uvcvideo.h | 3 +-
> 3 files changed, 31 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_queue.c
> b/drivers/media/usb/uvc/uvc_queue.c
> index 2752e386f1e8..d09b0c882938 100644
> --- a/drivers/media/usb/uvc/uvc_queue.c
> +++ b/drivers/media/usb/uvc/uvc_queue.c
> @@ -176,7 +176,7 @@ static int uvc_start_streaming(struct vb2_queue *vq,
> unsigned int count)
>
> queue->buf_used = 0;
>
> - ret = uvc_video_enable(stream, 1);
> + ret = uvc_video_start_streaming(stream);
> if (ret == 0)
> return 0;
>
> @@ -194,7 +194,7 @@ static void uvc_stop_streaming(struct vb2_queue *vq)
> lockdep_assert_irqs_enabled();
>
> if (vq->type != V4L2_BUF_TYPE_META_CAPTURE)
> - uvc_video_enable(uvc_queue_to_stream(queue), 0);
> + uvc_video_stop_streaming(uvc_queue_to_stream(queue));
>
> spin_lock_irq(>irqlock);
> uvc_queue_return_buffers(queue, UVC_BUF_STATE_ERROR);
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c
> index e19bdf089cc4..cd67506dc696 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -2076,38 +2076,10 @@ int uvc_video_init(struct uvc_streaming *stream)
> return 0;
> }
>
> -/*
> - * Enable or disable the video stream.
> - */
> -int uvc_video_enable(struct uvc_streaming *stream, int enable)
> +int uvc_video_start_streaming(struct uvc_streaming *stream)
> {
> int ret;
>
> - if (!enable) {
> - uvc_uninit_video(stream, 1);
> - if (stream->intf->num_altsetting > 1) {
> - usb_set_interface(stream->dev->udev,
> - stream->intfnum, 0);
> - } else {
> - /* UVC doesn't specify how to inform a bulk-based device
> - * when the video stream is stopped. Windows sends a
> - * CLEAR_FEATURE(HALT) request to the video streaming
> - * bulk endpoint, mimic the same behaviour.
> - */
> - unsigned int epnum = stream->header.bEndpointAddress
> -& USB_ENDPOINT_NUMBER_MASK;
> - unsigned int dir = stream->header.bEndpointAddress
> - & USB_ENDPOINT_DIR_MASK;
> - unsigned int pipe;
> -
> - pipe = usb_sndbulkpipe(stream->dev->udev, epnum) | dir;
> - usb_clear_halt(stream->dev->udev, pipe);
> - }
> -
> - uvc_video_clock_cleanup(stream);
> - return 0;
> - }
> -
> ret = uvc_video_clock_init(stream);
> if (ret < 0)
> return ret;
> @@ -2130,3 +2102,29 @@ int uvc_video_enable(struct uvc_streaming *stream, int
> enable)
>
> return ret;
> }
> +
> +int uvc_video_stop_streaming(struct uvc_streaming *stream)
> +{
> + uvc_uninit_video(stream, 1);
> + if (stream->intf->num_altsetting > 1) {
> + usb_set_interface(stream->dev->udev,
> + stream->intfnum, 0);
> + } else {
> + /* UVC doesn't specify how to inform a bulk-based device
> + * when the video stream is stopped. Windows sends a
> + * CLEAR_FEATURE(HALT) request to the video streaming
> + * bulk endpoint, mimic the same behaviour.
> + */
> + unsigned int epnum = stream->header.bEndpointAddress
> +& USB_ENDPOINT_NUMBER_MASK;
> + unsigned int dir = stream->header.bEndpointAddress
> + & USB_ENDPOINT_DIR_MASK;
> + unsigned int pipe;
> +
> + pipe = usb_sndbulkpipe(stream->dev->udev, epnum) | dir;
> + usb_clear_halt(stream->dev->udev, pipe);
> + }
> +
> + uvc_video_clock_cleanup(stream);
> + return 0;
> +}
> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> b/drivers/media/usb/uvc/uvcvideo.h
> index 94accfa3c009..b1b895c67122 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@
TechnoTrend CT2-4500 remote not working
Hi all, the remote on my TechnoTrend CT2-4500 is not working with kernel 4.18. The TV-card itself works fine: cx25840 6-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) cx23885: cx23885_dvb_register() allocating 1 frontend(s) cx23885: cx23885[0]: cx23885 based dvb card i2c i2c-5: Added multiplexed i2c bus 12 si2168 5-0064: Silicon Labs Si2168-B40 successfully identified si2168 5-0064: firmware version: B 4.0.2 si2157 12-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached dvbdev: DVB: registering new adapter (cx23885[0]) cx23885 :17:00.0: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... sp2 4-0040: CIMaX SP2 successfully attached cx23885: Technotrend TT-budget CT2-4500 CI MAC address: bc:ea:2b:45:05:68 cx23885: cx23885_dev_checkrevision() Hardware revision = 0xa5 cx23885: cx23885[0]/0: found at :17:00.0, rev: 4, irq: 31, latency: 0, mmio: 0xfe00 The remote is registered: Registered IR keymap rc-fusionhdtv-mce rc rc0: FusionHDTV as /devices/pci:00/:00:01.2/:15:00.2/:16:00.0/:17:00.0/i2c-4/4-006b/rc/rc0 input: FusionHDTV as /devices/pci:00/:00:01.2/:15:00.2/:16:00.0/:17:00.0/i2c-4/4-006b/rc/rc0/input18 rc rc0: lirc_dev: driver ir_kbd_i2c registered at minor = 0, scancode receiver, no transmitter ir-keytable reports: Found /sys/class/rc/rc0/ (/dev/input/event15) with: Name: FusionHDTV Driver: ir_kbd_i2c, table: rc-fusionhdtv-mce lirc device: /dev/lirc0 Supported protocols: unknown Enabled protocols: unknown bus: 24, vendor/product: :, version: 0x Repeat delay = 500 ms, repeat period = 125 ms Apparently, no protocols are reported. evtest on /dev/input/event15 reports no events. The error was reported before: http://lirc.10951.n7.nabble.com/Problems-with-cx23885-IR-receiver-td10884.html The remote is working, I verified it with a camera. Regards, Martin
TechnoTrend CT2-4500 remote not working
Hi all, the remote on my TechnoTrend CT2-4500 is not working with kernel 4.18. The TV-card itself works fine: cx25840 6-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) cx23885: cx23885_dvb_register() allocating 1 frontend(s) cx23885: cx23885[0]: cx23885 based dvb card i2c i2c-5: Added multiplexed i2c bus 12 si2168 5-0064: Silicon Labs Si2168-B40 successfully identified si2168 5-0064: firmware version: B 4.0.2 si2157 12-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached dvbdev: DVB: registering new adapter (cx23885[0]) cx23885 :17:00.0: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... sp2 4-0040: CIMaX SP2 successfully attached cx23885: Technotrend TT-budget CT2-4500 CI MAC address: bc:ea:2b:45:05:68 cx23885: cx23885_dev_checkrevision() Hardware revision = 0xa5 cx23885: cx23885[0]/0: found at :17:00.0, rev: 4, irq: 31, latency: 0, mmio: 0xfe00 The remote is registered: Registered IR keymap rc-fusionhdtv-mce rc rc0: FusionHDTV as /devices/pci:00/:00:01.2/:15:00.2/:16:00.0/:17:00.0/i2c-4/4-006b/rc/rc0 input: FusionHDTV as /devices/pci:00/:00:01.2/:15:00.2/:16:00.0/:17:00.0/i2c-4/4-006b/rc/rc0/input18 rc rc0: lirc_dev: driver ir_kbd_i2c registered at minor = 0, scancode receiver, no transmitter ir-keytable reports: Found /sys/class/rc/rc0/ (/dev/input/event15) with: Name: FusionHDTV Driver: ir_kbd_i2c, table: rc-fusionhdtv-mce lirc device: /dev/lirc0 Supported protocols: unknown Enabled protocols: unknown bus: 24, vendor/product: :, version: 0x Repeat delay = 500 ms, repeat period = 125 ms Apparently, no protocols are reported. evtest on /dev/input/event15 reports no events. The error was reported before: http://lirc.10951.n7.nabble.com/Problems-with-cx23885-IR-receiver-td10884.html The remote is working, I verified it with a camera. Regards, Martin
Re: VIVID/VIMC and media fuzzing
On Sat, Nov 10, 2018 at 2:01 AM, Hans Verkuil wrote:
> On 11/09/2018 10:34 PM, Dmitry Vyukov wrote:
What would be a good improvement is if you add this to the kernel command
options:
"vivid.n_devs=2 vivid.multiplanar=1,2"
This will create two vivid instances, one using the single planar API and
one using
the multiplanar API. That will improve the test coverage.
>>>
>>> Re this and collisions between multiple test processes. We actually
>>> would like to have moar devices and partition them between test
>>> processes. Say if we need need devices for 8 test processes, will it
>>> work to specify something like "vivid.n_devs=16
>>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>>
>>> Without giving any flags, I see 8 /dev/video* devices, does
>>> vivid.n_devs defaults to 8?
>>
>> I am a bit lost.
>>
>> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
>> creates 32 /dev/video* devices.
>
> I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
> vivid devices (2 video nodes for each instance), then a vim2m device and
> finally two vicodec devices.
>
> So you should always see 6 + n_devs * 2 video devices.
>
>>
>> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
>> /dev/video* devices.
>>
>> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
>>
>> Also, by default there is /dev/radio0 and /dev/radio1, are these
>> different types of devices, e.g. "source" and "sink"? Or they are
>> identical? And the same question for other types of devices?
>
> vivid creates two radio devices per instance: one emulates a radio tuner,
> one emulates a radio modulator (so yes, source and sink). Same for vbi
> (one source, one sink) and one swradio device. It also creates two cec
> devices (source and sink).
>
>>
>> How can I create 8 independent partitions of devices? What devices
>> will belong to each partition?
>
> Exactly as you did above. Instance X (starting at 0) uses video nodes
> 3+2*X and 4+2*X.
Thanks! Now I got it.
I've extended syzkaller to create more devices, use planar/non-planar,
radio, swradio, cec, vbi:
https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-a6fc2c4d3df5a6bcb42a628db614175f
https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-c60ec5d4add9b876f5d28fdeeaf3b7b8
I also noticed that you appear to test only video devices. But vivid also
creates
vbi, radio and swradio devices. It would be nice to have those tested as
well.
>>>
>>> Will do.
>>> FTR, this is these devices:
>>>
>>> # ls -l /dev/{vbi,radio,swradio}*
>>> crw-rw 1 root video 81, 14 Nov 9 21:07 /dev/radio0
>>> crw-rw 1 root video 81, 15 Nov 9 21:07 /dev/radio1
>>> crw-rw 1 root video 81, 13 Nov 9 21:07 /dev/swradio0
>>> crw-rw 1 root video 81, 11 Nov 9 21:07 /dev/vbi0
>>> crw-rw 1 root video 81, 12 Nov 9 21:07 /dev/vbi1
>>>
>>> Why are there 2 radio and vbi? Are they different? Is it possible to
>>> also create more of them? Are there any other useful command line args
>>> for them?
>
> As mentioned: the first is capture, the second output. It's per vivid
> instance.
>
>
>
> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
> live with it for now.
Sorry, I'm not sure what you mean.
>>>
>>> You said:
>>>
> But after calling REQBUFS or CREATE_BUFS the filehandle that
> called those ioctls becomes owner of the device until the buffers are
> released. So other filehandles cannot do any streaming operations (EBUSY
> will be returned).
>>>
>>> This semantics are somewhat unfortunate for syzkaller because one test
>>> process will affect/block other test processes, and we try to make
>>> them as independent as possible. E.g. If this can affect syzkaller
>>> ability to create reproducers, because in one run of a test if was
>>> affected by an unrelated test and crashed, but if we try to reproduce
>>> the crash on the same test it won't crash again because now it's not
>>> affected by the unrelated test.
>>>
>>> But if we create more devices and partition them across test
>>> processes, it will resolve this problem?
>
> I think it will help, yes.
>
>>>
>>>
> I assume that when the process dies it will release everything at
> least, because fuzzer will sure not pair create with release all the
> time.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
SPENDE
Sehr geehrter Herr/Frau, Wir freuen uns, Ihnen mitzuteilen, dass Sie ausgewählt wurden, um die Summe zu erhalten €2,000,000.00 Euro aus Mitteln der Mavis Wanczyk Hilfe. Mein Name ist Mavis Wanczyk der Gewinner des 758,7 Millionen US-Dollar in der Power Ball Lotterie Jackpot als der größte Preis aus einem einzigen Lottoschein in USA. Meine Wohltätigkeitsstiftung hat dich ausgewählt, als unsere glücklichen Empfänger erhalten die Summe von € 2,000,000.00 EURO. Nehmen Sie dieses Angebot an und kontaktieren Sie mich für Weitere Details.
Re: [PATCH v6 05/10] media: uvcvideo: queue: Support asynchronous buffer handling
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 will need to support buffers being processed on multiple CPUs.
>
> Adapt the uvc_queue_next_buffer() such that a reference count tracks the
> active use of the buffer, returning the buffer to the VB2 stack at
> completion.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> v5:
> - uvc_queue_requeue() -> uvc_queue_buffer_requeue()
> - Fix comment
> ---
> drivers/media/usb/uvc/uvc_queue.c | 61 ++--
> drivers/media/usb/uvc/uvcvideo.h | 4 ++-
> 2 files changed, 54 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_queue.c
> b/drivers/media/usb/uvc/uvc_queue.c index fa7059aab49a..2752e386f1e8 100644
> --- a/drivers/media/usb/uvc/uvc_queue.c
> +++ b/drivers/media/usb/uvc/uvc_queue.c
> @@ -142,6 +142,7 @@ static void uvc_buffer_queue(struct vb2_buffer *vb)
>
> spin_lock_irqsave(>irqlock, flags);
> if (likely(!(queue->flags & UVC_QUEUE_DISCONNECTED))) {
> + kref_init(>ref);
> list_add_tail(>queue, >irqqueue);
> } else {
> /* If the device is disconnected return the buffer to userspace
> @@ -458,28 +459,66 @@ struct uvc_buffer *uvc_queue_get_current_buffer(struct
> uvc_video_queue *queue) return nextbuf;
> }
>
> -struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
> +/*
> + * uvc_queue_buffer_requeue: Requeue a buffer on our internal irqqueue
> + *
> + * Reuse a buffer through our internal queue without the need to 'prepare'.
> + * The buffer will be returned to userspace through the uvc_buffer_queue
> call if + * the device has been disconnected.
> + */
> +static void uvc_queue_buffer_requeue(struct uvc_video_queue *queue,
> struct uvc_buffer *buf)
> {
> - struct uvc_buffer *nextbuf;
> - unsigned long flags;
> + buf->error = 0;
> + buf->state = UVC_BUF_STATE_QUEUED;
> + buf->bytesused = 0;
> + vb2_set_plane_payload(>buf.vb2_buf, 0, 0);
> +
> + uvc_buffer_queue(>buf.vb2_buf);
> +}
> +
> +static void uvc_queue_buffer_complete(struct kref *ref)
> +{
> + struct uvc_buffer *buf = container_of(ref, struct uvc_buffer, ref);
> + struct vb2_buffer *vb = >buf.vb2_buf;
> + struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
>
> if ((queue->flags & UVC_QUEUE_DROP_CORRUPTED) && buf->error) {
> - buf->error = 0;
> - buf->state = UVC_BUF_STATE_QUEUED;
> - buf->bytesused = 0;
> - vb2_set_plane_payload(>buf.vb2_buf, 0, 0);
> - return buf;
> + uvc_queue_buffer_requeue(queue, buf);
> + return;
> }
>
> + buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
> + vb2_set_plane_payload(>buf.vb2_buf, 0, buf->bytesused);
> + vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
> +}
> +
> +/*
> + * Release a reference on the buffer. Complete the buffer when the last
> + * reference is released.
> + */
> +void uvc_queue_buffer_release(struct uvc_buffer *buf)
> +{
> + kref_put(>ref, uvc_queue_buffer_complete);
> +}
> +
> +/*
> + * Remove this buffer from the queue. Lifetime will persist while async
> actions + * are still running (if any), and uvc_queue_buffer_release will
> give the buffer + * back to VB2 when all users have completed.
> + */
> +struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
> + struct uvc_buffer *buf)
> +{
> + struct uvc_buffer *nextbuf;
> + unsigned long flags;
> +
> spin_lock_irqsave(>irqlock, flags);
> list_del(>queue);
> nextbuf = __uvc_queue_get_current_buffer(queue);
> spin_unlock_irqrestore(>irqlock, flags);
>
> - buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
> - vb2_set_plane_payload(>buf.vb2_buf, 0, buf->bytesused);
> - vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
> + uvc_queue_buffer_release(buf);
>
> return nextbuf;
> }
> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> b/drivers/media/usb/uvc/uvcvideo.h index 16b8348f7ff0..7f884c60ae59 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -413,6 +413,9 @@ struct uvc_buffer {
> unsigned int bytesused;
>
> u32 pts;
> +
> + /* Asynchronous buffer handling. */
> + struct kref ref;
> };
>
> #define UVC_QUEUE_DISCONNECTED (1 << 0)
> @@ -728,6 +731,7 @@ void uvc_queue_cancel(struct uvc_video_queue *queue, int
> disconnect);
> struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
> struct uvc_buffer *buf);
> struct uvc_buffer *uvc_queue_get_current_buffer(struct uvc_video_queue
> *queue);
> +void
My Greetings
Beloved, I am writing this mail to you with heavy tears in my eyes and great sorrow in my heart. As I informed you earlier, I am (Mrs.)Marianne Jeanne, suffering from long time Cancer. From all indications my condition is really deteriorating and it's quite obvious that I won't live more than 2 months according to my doctors. I have some funds I inherited from my late loving husband Mr. Jeanne Smith, the sum of ($8.5000.000) which he deposited in a Bank. I need a very honest and God fearing person that can use these funds for Charity work, helping the Less Privileges, and 20% of this money will be for your time and expenses, while 80% goes to charities. Please let me know if I can TRUST YOU ON THIS to carry out this favour for me. I look forward to your prompt reply for more details. Yours sincerely Marianne Jeanne
Re: [RFC v2 1/4] media: Introduce helpers to fill pixel format structs
On Fri, 2018-11-02 at 12:52 -0300, Ezequiel Garcia wrote:
> Add two new API helpers, v4l2_fill_pixfmt and v4l2_fill_pixfmt_mp,
> to be used by drivers to calculate plane sizes and bytes per lines.
>
> Note that driver-specific paddig and alignment are not yet
> taken into account.
>
> Signed-off-by: Ezequiel Garcia
> ---
Heads-up: I plan to submit a new version of this patch, as part of
the VPU JPEG patchset.
Thanks,
Ezequiel
> drivers/media/v4l2-core/Makefile | 2 +-
> drivers/media/v4l2-core/v4l2-common.c | 66 +++
> drivers/media/v4l2-core/v4l2-fourcc.c | 93 +++
> include/media/v4l2-common.h | 5 ++
> include/media/v4l2-fourcc.h | 53 +++
> 5 files changed, 218 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/v4l2-core/v4l2-fourcc.c
> create mode 100644 include/media/v4l2-fourcc.h
>
> diff --git a/drivers/media/v4l2-core/Makefile
> b/drivers/media/v4l2-core/Makefile
> index 9ee57e1efefe..bc23c3407c17 100644
> --- a/drivers/media/v4l2-core/Makefile
> +++ b/drivers/media/v4l2-core/Makefile
> @@ -7,7 +7,7 @@ tuner-objs:= tuner-core.o
>
> videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
> \
> v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
> - v4l2-async.o
> + v4l2-async.o v4l2-fourcc.o
> ifeq ($(CONFIG_COMPAT),y)
>videodev-objs += v4l2-compat-ioctl32.o
> endif
> diff --git a/drivers/media/v4l2-core/v4l2-common.c
> b/drivers/media/v4l2-core/v4l2-common.c
> index 50763fb42a1b..97bb51d15188 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -455,3 +456,68 @@ int v4l2_s_parm_cap(struct video_device *vdev,
> return ret;
> }
> EXPORT_SYMBOL_GPL(v4l2_s_parm_cap);
> +
> +void v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, int
> pixelformat, int width, int height)
> +{
> + const struct v4l2_format_info *info;
> + struct v4l2_plane_pix_format *plane;
> + int i;
> +
> + info = v4l2_format_info(pixelformat);
> + if (!info)
> + return;
> +
> + pixfmt->width = width;
> + pixfmt->height = height;
> + pixfmt->pixelformat = pixelformat;
> +
> + if (info->has_contiguous_planes) {
> + pixfmt->num_planes = 1;
> + plane = >plane_fmt[0];
> + plane->bytesperline = info->is_compressed ?
> + 0 : width * info->cpp[0];
> + plane->sizeimage = info->header_size;
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int hsub = (i == 0) ? 1 : info->hsub;
> + unsigned int vsub = (i == 0) ? 1 : info->vsub;
> +
> + plane->sizeimage += width * height * info->cpp[i] /
> (hsub * vsub);
> + }
> + } else {
> + pixfmt->num_planes = info->num_planes;
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int hsub = (i == 0) ? 1 : info->hsub;
> + unsigned int vsub = (i == 0) ? 1 : info->vsub;
> +
> + plane = >plane_fmt[i];
> + plane->bytesperline = width * info->cpp[i] / hsub;
> + plane->sizeimage = width * height * info->cpp[i] /
> (hsub * vsub);
> + }
> + }
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt_mp);
> +
> +void v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, int pixelformat, int
> width, int height)
> +{
> + const struct v4l2_format_info *info;
> + char name[32];
> + int i;
> +
> + pixfmt->width = width;
> + pixfmt->height = height;
> + pixfmt->pixelformat = pixelformat;
> +
> + info = v4l2_format_info(pixelformat);
> + if (!info)
> + return;
> + pixfmt->bytesperline = info->is_compressed ? 0 : width * info->cpp[0];
> +
> + pixfmt->sizeimage = info->header_size;
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int hsub = (i == 0) ? 1 : info->hsub;
> + unsigned int vsub = (i == 0) ? 1 : info->vsub;
> +
> + pixfmt->sizeimage += width * height * info->cpp[i] / (hsub *
> vsub);
> + }
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt);
> diff --git a/drivers/media/v4l2-core/v4l2-fourcc.c
> b/drivers/media/v4l2-core/v4l2-fourcc.c
> new file mode 100644
> index ..4e8a15525b58
> --- /dev/null
> +++ b/drivers/media/v4l2-core/v4l2-fourcc.c
> @@ -0,0 +1,93 @@
> +/*
> + * Copyright (c) 2018 Collabora, Ltd.
> + *
> + * Based on drm-fourcc:
> + * Copyright (c) 2016 Laurent Pinchart
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all
Re: [PATCH v4l-utils] Introduce v4l2-get-device tool
On Sat, 2018-11-10 at 12:09 +0100, Hans Verkuil wrote: > On 11/10/2018 12:01 PM, Ezequiel Garcia wrote: > > On Sat, 2018-11-10 at 11:29 +0100, Hans Verkuil wrote: > > > On 11/09/2018 10:52 PM, Ezequiel Garcia wrote: > > > > This tool allows to find a device by driver name, > > > > this is useful for scripts to be written in a generic way. > > > > > > Why not add support for this to v4l2-sysfs-path? And improve it at the > > > same > > > time (swradio devices do not show up when I run v4l2-sysfs-path, I also > > > suspect > > > v4l-touch devices aren't recognized. Ditto for media devices. > > > > > > > I can add the functionality to v4l2-sysfs-path, and we can document > > the rest in some TODO list, as I don't think we need to get everything > > solved right now :-) > > I agree with that. > Great! About adding it to v4l2-sysfs-path, is there any scenario where we'll want to use udev-based scanning instead of sysfs-based? Maybe we can rename the tool, and still install a v4l2-sysfs-path alias? > > > > Usage: > > > > > > > > v4l2-get-device -d uvcvideo -c V4L2_CAP_VIDEO_CAPTURE > > > > /dev/video0 > > > > /dev/video2 > > > > > > > > Signed-off-by: Ezequiel Garcia > > > > --- > > > > configure.ac| 1 + > > > > utils/Makefile.am | 1 + > > > > utils/v4l2-get-device/.gitignore| 1 + > > > > utils/v4l2-get-device/Makefile.am | 4 + > > > > utils/v4l2-get-device/v4l2-get-device.c | 147 > > > > v4l-utils.spec.in | 1 + > > > > 6 files changed, 155 insertions(+) > > > > create mode 100644 utils/v4l2-get-device/.gitignore > > > > create mode 100644 utils/v4l2-get-device/Makefile.am > > > > create mode 100644 utils/v4l2-get-device/v4l2-get-device.c > > > > > > > > diff --git a/configure.ac b/configure.ac > > > > index 5cc34c248fbf..918cb59704b9 100644 > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -31,6 +31,7 @@ AC_CONFIG_FILES([Makefile > > > > utils/v4l2-compliance/Makefile > > > > utils/v4l2-ctl/Makefile > > > > utils/v4l2-dbg/Makefile > > > > + utils/v4l2-get-device/Makefile > > > > utils/v4l2-sysfs-path/Makefile > > > > utils/qv4l2/Makefile > > > > utils/cec-ctl/Makefile > > > > diff --git a/utils/Makefile.am b/utils/Makefile.am > > > > index 2d5070288c13..2b2b27107d13 100644 > > > > --- a/utils/Makefile.am > > > > +++ b/utils/Makefile.am > > > > @@ -9,6 +9,7 @@ SUBDIRS = \ > > > > v4l2-compliance \ > > > > v4l2-ctl \ > > > > v4l2-dbg \ > > > > + v4l2-get-device \ > > > > v4l2-sysfs-path \ > > > > cec-ctl \ > > > > cec-compliance \ > > > > diff --git a/utils/v4l2-get-device/.gitignore > > > > b/utils/v4l2-get-device/.gitignore > > > > new file mode 100644 > > > > index ..b222144c9f4e > > > > --- /dev/null > > > > +++ b/utils/v4l2-get-device/.gitignore > > > > @@ -0,0 +1 @@ > > > > +v4l2-get-device > > > > diff --git a/utils/v4l2-get-device/Makefile.am > > > > b/utils/v4l2-get-device/Makefile.am > > > > new file mode 100644 > > > > index ..2e5a6e0ba32f > > > > --- /dev/null > > > > +++ b/utils/v4l2-get-device/Makefile.am > > > > @@ -0,0 +1,4 @@ > > > > +bin_PROGRAMS = v4l2-get-device > > > > +v4l2_get_device_SOURCES = v4l2-get-device.c > > > > +v4l2_get_device_LDADD = ../libmedia_dev/libmedia_dev.la > > > > +v4l2_get_device_LDFLAGS = $(ARGP_LIBS) > > > > diff --git a/utils/v4l2-get-device/v4l2-get-device.c > > > > b/utils/v4l2-get-device/v4l2-get-device.c > > > > new file mode 100644 > > > > index ..f9cc323b7057 > > > > --- /dev/null > > > > +++ b/utils/v4l2-get-device/v4l2-get-device.c > > > > @@ -0,0 +1,147 @@ > > > > +/* > > > > + * Copyright © 2018 Collabora, Ltd. > > > > + * > > > > + * Based on v4l2-sysfs-path by Mauro Carvalho Chehab: > > > > + * > > > > + * Copyright © 2011 Red Hat, Inc. > > > > + * > > > > + * Permission to use, copy, modify, distribute, and sell this software > > > > + * and its documentation for any purpose is hereby granted without > > > > + * fee, provided that the above copyright notice appear in all copies > > > > + * and that both that copyright notice and this permission notice > > > > + * appear in supporting documentation, and that the name of Red Hat > > > > + * not be used in advertising or publicity pertaining to distribution > > > > + * of the software without specific, written prior permission. Red > > > > + * Hat makes no representations about the suitability of this software > > > > + * for any purpose. It is provided "as is" without express or implied > > > > + * warranty. > > > > + * > > > > + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, > > > > + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN > > > > + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR > > > > + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES
Re: [PATCH v4l-utils] Introduce v4l2-get-device tool
On 11/10/2018 12:01 PM, Ezequiel Garcia wrote:
> On Sat, 2018-11-10 at 11:29 +0100, Hans Verkuil wrote:
>> On 11/09/2018 10:52 PM, Ezequiel Garcia wrote:
>>> This tool allows to find a device by driver name,
>>> this is useful for scripts to be written in a generic way.
>>
>> Why not add support for this to v4l2-sysfs-path? And improve it at the same
>> time (swradio devices do not show up when I run v4l2-sysfs-path, I also
>> suspect
>> v4l-touch devices aren't recognized. Ditto for media devices.
>>
>
> I can add the functionality to v4l2-sysfs-path, and we can document
> the rest in some TODO list, as I don't think we need to get everything
> solved right now :-)
I agree with that.
>
>>> Usage:
>>>
>>> v4l2-get-device -d uvcvideo -c V4L2_CAP_VIDEO_CAPTURE
>>> /dev/video0
>>> /dev/video2
>>>
>>> Signed-off-by: Ezequiel Garcia
>>> ---
>>> configure.ac| 1 +
>>> utils/Makefile.am | 1 +
>>> utils/v4l2-get-device/.gitignore| 1 +
>>> utils/v4l2-get-device/Makefile.am | 4 +
>>> utils/v4l2-get-device/v4l2-get-device.c | 147
>>> v4l-utils.spec.in | 1 +
>>> 6 files changed, 155 insertions(+)
>>> create mode 100644 utils/v4l2-get-device/.gitignore
>>> create mode 100644 utils/v4l2-get-device/Makefile.am
>>> create mode 100644 utils/v4l2-get-device/v4l2-get-device.c
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 5cc34c248fbf..918cb59704b9 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -31,6 +31,7 @@ AC_CONFIG_FILES([Makefile
>>> utils/v4l2-compliance/Makefile
>>> utils/v4l2-ctl/Makefile
>>> utils/v4l2-dbg/Makefile
>>> + utils/v4l2-get-device/Makefile
>>> utils/v4l2-sysfs-path/Makefile
>>> utils/qv4l2/Makefile
>>> utils/cec-ctl/Makefile
>>> diff --git a/utils/Makefile.am b/utils/Makefile.am
>>> index 2d5070288c13..2b2b27107d13 100644
>>> --- a/utils/Makefile.am
>>> +++ b/utils/Makefile.am
>>> @@ -9,6 +9,7 @@ SUBDIRS = \
>>> v4l2-compliance \
>>> v4l2-ctl \
>>> v4l2-dbg \
>>> + v4l2-get-device \
>>> v4l2-sysfs-path \
>>> cec-ctl \
>>> cec-compliance \
>>> diff --git a/utils/v4l2-get-device/.gitignore
>>> b/utils/v4l2-get-device/.gitignore
>>> new file mode 100644
>>> index ..b222144c9f4e
>>> --- /dev/null
>>> +++ b/utils/v4l2-get-device/.gitignore
>>> @@ -0,0 +1 @@
>>> +v4l2-get-device
>>> diff --git a/utils/v4l2-get-device/Makefile.am
>>> b/utils/v4l2-get-device/Makefile.am
>>> new file mode 100644
>>> index ..2e5a6e0ba32f
>>> --- /dev/null
>>> +++ b/utils/v4l2-get-device/Makefile.am
>>> @@ -0,0 +1,4 @@
>>> +bin_PROGRAMS = v4l2-get-device
>>> +v4l2_get_device_SOURCES = v4l2-get-device.c
>>> +v4l2_get_device_LDADD = ../libmedia_dev/libmedia_dev.la
>>> +v4l2_get_device_LDFLAGS = $(ARGP_LIBS)
>>> diff --git a/utils/v4l2-get-device/v4l2-get-device.c
>>> b/utils/v4l2-get-device/v4l2-get-device.c
>>> new file mode 100644
>>> index ..f9cc323b7057
>>> --- /dev/null
>>> +++ b/utils/v4l2-get-device/v4l2-get-device.c
>>> @@ -0,0 +1,147 @@
>>> +/*
>>> + * Copyright © 2018 Collabora, Ltd.
>>> + *
>>> + * Based on v4l2-sysfs-path by Mauro Carvalho Chehab:
>>> + *
>>> + * Copyright © 2011 Red Hat, Inc.
>>> + *
>>> + * Permission to use, copy, modify, distribute, and sell this software
>>> + * and its documentation for any purpose is hereby granted without
>>> + * fee, provided that the above copyright notice appear in all copies
>>> + * and that both that copyright notice and this permission notice
>>> + * appear in supporting documentation, and that the name of Red Hat
>>> + * not be used in advertising or publicity pertaining to distribution
>>> + * of the software without specific, written prior permission. Red
>>> + * Hat makes no representations about the suitability of this software
>>> + * for any purpose. It is provided "as is" without express or implied
>>> + * warranty.
>>> + *
>>> + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
>>> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
>>> + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
>>> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
>>> + * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
>>> + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
>>> + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>>> + *
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#include
>>> +
>>> +#include "../libmedia_dev/get_media_devices.h"
>>> +
>>> +const char *argp_program_version = "v4l2-get-device " V4L_UTILS_VERSION;
>>> +const char *argp_program_bug_address = "Ezequiel Garcia
>>> ";
>>> +
>>> +struct args {
>>> + const char *driver;
>>> + unsigned int device_caps;
>>> +};
>>> +
>>>
Re: [PATCH v4l-utils] Introduce v4l2-get-device tool
On Sat, 2018-11-10 at 11:29 +0100, Hans Verkuil wrote:
> On 11/09/2018 10:52 PM, Ezequiel Garcia wrote:
> > This tool allows to find a device by driver name,
> > this is useful for scripts to be written in a generic way.
>
> Why not add support for this to v4l2-sysfs-path? And improve it at the same
> time (swradio devices do not show up when I run v4l2-sysfs-path, I also
> suspect
> v4l-touch devices aren't recognized. Ditto for media devices.
>
I can add the functionality to v4l2-sysfs-path, and we can document
the rest in some TODO list, as I don't think we need to get everything
solved right now :-)
> > Usage:
> >
> > v4l2-get-device -d uvcvideo -c V4L2_CAP_VIDEO_CAPTURE
> > /dev/video0
> > /dev/video2
> >
> > Signed-off-by: Ezequiel Garcia
> > ---
> > configure.ac| 1 +
> > utils/Makefile.am | 1 +
> > utils/v4l2-get-device/.gitignore| 1 +
> > utils/v4l2-get-device/Makefile.am | 4 +
> > utils/v4l2-get-device/v4l2-get-device.c | 147
> > v4l-utils.spec.in | 1 +
> > 6 files changed, 155 insertions(+)
> > create mode 100644 utils/v4l2-get-device/.gitignore
> > create mode 100644 utils/v4l2-get-device/Makefile.am
> > create mode 100644 utils/v4l2-get-device/v4l2-get-device.c
> >
> > diff --git a/configure.ac b/configure.ac
> > index 5cc34c248fbf..918cb59704b9 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -31,6 +31,7 @@ AC_CONFIG_FILES([Makefile
> > utils/v4l2-compliance/Makefile
> > utils/v4l2-ctl/Makefile
> > utils/v4l2-dbg/Makefile
> > + utils/v4l2-get-device/Makefile
> > utils/v4l2-sysfs-path/Makefile
> > utils/qv4l2/Makefile
> > utils/cec-ctl/Makefile
> > diff --git a/utils/Makefile.am b/utils/Makefile.am
> > index 2d5070288c13..2b2b27107d13 100644
> > --- a/utils/Makefile.am
> > +++ b/utils/Makefile.am
> > @@ -9,6 +9,7 @@ SUBDIRS = \
> > v4l2-compliance \
> > v4l2-ctl \
> > v4l2-dbg \
> > + v4l2-get-device \
> > v4l2-sysfs-path \
> > cec-ctl \
> > cec-compliance \
> > diff --git a/utils/v4l2-get-device/.gitignore
> > b/utils/v4l2-get-device/.gitignore
> > new file mode 100644
> > index ..b222144c9f4e
> > --- /dev/null
> > +++ b/utils/v4l2-get-device/.gitignore
> > @@ -0,0 +1 @@
> > +v4l2-get-device
> > diff --git a/utils/v4l2-get-device/Makefile.am
> > b/utils/v4l2-get-device/Makefile.am
> > new file mode 100644
> > index ..2e5a6e0ba32f
> > --- /dev/null
> > +++ b/utils/v4l2-get-device/Makefile.am
> > @@ -0,0 +1,4 @@
> > +bin_PROGRAMS = v4l2-get-device
> > +v4l2_get_device_SOURCES = v4l2-get-device.c
> > +v4l2_get_device_LDADD = ../libmedia_dev/libmedia_dev.la
> > +v4l2_get_device_LDFLAGS = $(ARGP_LIBS)
> > diff --git a/utils/v4l2-get-device/v4l2-get-device.c
> > b/utils/v4l2-get-device/v4l2-get-device.c
> > new file mode 100644
> > index ..f9cc323b7057
> > --- /dev/null
> > +++ b/utils/v4l2-get-device/v4l2-get-device.c
> > @@ -0,0 +1,147 @@
> > +/*
> > + * Copyright © 2018 Collabora, Ltd.
> > + *
> > + * Based on v4l2-sysfs-path by Mauro Carvalho Chehab:
> > + *
> > + * Copyright © 2011 Red Hat, Inc.
> > + *
> > + * Permission to use, copy, modify, distribute, and sell this software
> > + * and its documentation for any purpose is hereby granted without
> > + * fee, provided that the above copyright notice appear in all copies
> > + * and that both that copyright notice and this permission notice
> > + * appear in supporting documentation, and that the name of Red Hat
> > + * not be used in advertising or publicity pertaining to distribution
> > + * of the software without specific, written prior permission. Red
> > + * Hat makes no representations about the suitability of this software
> > + * for any purpose. It is provided "as is" without express or implied
> > + * warranty.
> > + *
> > + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
> > + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
> > + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> > + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
> > + * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
> > + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
> > + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "../libmedia_dev/get_media_devices.h"
> > +
> > +const char *argp_program_version = "v4l2-get-device " V4L_UTILS_VERSION;
> > +const char *argp_program_bug_address = "Ezequiel Garcia
> > ";
> > +
> > +struct args {
> > + const char *driver;
> > + unsigned int device_caps;
> > +};
> > +
> > +static const struct argp_option options[] = {
> > + {"driver", 'd', "DRIVER", 0,
Re: [PATCH v4l-utils] Introduce v4l2-get-device tool
On 11/09/2018 10:52 PM, Ezequiel Garcia wrote:
> This tool allows to find a device by driver name,
> this is useful for scripts to be written in a generic way.
Why not add support for this to v4l2-sysfs-path? And improve it at the same
time (swradio devices do not show up when I run v4l2-sysfs-path, I also suspect
v4l-touch devices aren't recognized. Ditto for media devices.
>
> Usage:
>
> v4l2-get-device -d uvcvideo -c V4L2_CAP_VIDEO_CAPTURE
> /dev/video0
> /dev/video2
>
> Signed-off-by: Ezequiel Garcia
> ---
> configure.ac| 1 +
> utils/Makefile.am | 1 +
> utils/v4l2-get-device/.gitignore| 1 +
> utils/v4l2-get-device/Makefile.am | 4 +
> utils/v4l2-get-device/v4l2-get-device.c | 147
> v4l-utils.spec.in | 1 +
> 6 files changed, 155 insertions(+)
> create mode 100644 utils/v4l2-get-device/.gitignore
> create mode 100644 utils/v4l2-get-device/Makefile.am
> create mode 100644 utils/v4l2-get-device/v4l2-get-device.c
>
> diff --git a/configure.ac b/configure.ac
> index 5cc34c248fbf..918cb59704b9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -31,6 +31,7 @@ AC_CONFIG_FILES([Makefile
> utils/v4l2-compliance/Makefile
> utils/v4l2-ctl/Makefile
> utils/v4l2-dbg/Makefile
> + utils/v4l2-get-device/Makefile
> utils/v4l2-sysfs-path/Makefile
> utils/qv4l2/Makefile
> utils/cec-ctl/Makefile
> diff --git a/utils/Makefile.am b/utils/Makefile.am
> index 2d5070288c13..2b2b27107d13 100644
> --- a/utils/Makefile.am
> +++ b/utils/Makefile.am
> @@ -9,6 +9,7 @@ SUBDIRS = \
> v4l2-compliance \
> v4l2-ctl \
> v4l2-dbg \
> + v4l2-get-device \
> v4l2-sysfs-path \
> cec-ctl \
> cec-compliance \
> diff --git a/utils/v4l2-get-device/.gitignore
> b/utils/v4l2-get-device/.gitignore
> new file mode 100644
> index ..b222144c9f4e
> --- /dev/null
> +++ b/utils/v4l2-get-device/.gitignore
> @@ -0,0 +1 @@
> +v4l2-get-device
> diff --git a/utils/v4l2-get-device/Makefile.am
> b/utils/v4l2-get-device/Makefile.am
> new file mode 100644
> index ..2e5a6e0ba32f
> --- /dev/null
> +++ b/utils/v4l2-get-device/Makefile.am
> @@ -0,0 +1,4 @@
> +bin_PROGRAMS = v4l2-get-device
> +v4l2_get_device_SOURCES = v4l2-get-device.c
> +v4l2_get_device_LDADD = ../libmedia_dev/libmedia_dev.la
> +v4l2_get_device_LDFLAGS = $(ARGP_LIBS)
> diff --git a/utils/v4l2-get-device/v4l2-get-device.c
> b/utils/v4l2-get-device/v4l2-get-device.c
> new file mode 100644
> index ..f9cc323b7057
> --- /dev/null
> +++ b/utils/v4l2-get-device/v4l2-get-device.c
> @@ -0,0 +1,147 @@
> +/*
> + * Copyright © 2018 Collabora, Ltd.
> + *
> + * Based on v4l2-sysfs-path by Mauro Carvalho Chehab:
> + *
> + * Copyright © 2011 Red Hat, Inc.
> + *
> + * Permission to use, copy, modify, distribute, and sell this software
> + * and its documentation for any purpose is hereby granted without
> + * fee, provided that the above copyright notice appear in all copies
> + * and that both that copyright notice and this permission notice
> + * appear in supporting documentation, and that the name of Red Hat
> + * not be used in advertising or publicity pertaining to distribution
> + * of the software without specific, written prior permission. Red
> + * Hat makes no representations about the suitability of this software
> + * for any purpose. It is provided "as is" without express or implied
> + * warranty.
> + *
> + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
> + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
> + * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
> + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
> + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "../libmedia_dev/get_media_devices.h"
> +
> +const char *argp_program_version = "v4l2-get-device " V4L_UTILS_VERSION;
> +const char *argp_program_bug_address = "Ezequiel Garcia
> ";
> +
> +struct args {
> + const char *driver;
> + unsigned int device_caps;
> +};
> +
> +static const struct argp_option options[] = {
> + {"driver", 'd', "DRIVER", 0, "device driver name", 0},
> + {"v4l2-device-caps", 'c', "CAPS", 0, "v4l2 device capabilities", 0},
I'd like a bus-info option as well, if possible.
> + { 0 }
> +};
> +
> +static unsigned int parse_capabilities(const char *arg)
> +{
> + char *s, *str = strdup(arg);
> + unsigned int caps = 0;
> +
> + s = strtok (str,",");
> + while (s != NULL) {
> + if (!strcmp(s, "V4L2_CAP_VIDEO_CAPTURE"))
> +
Re: VIVID/VIMC and media fuzzing
On 11/09/2018 10:34 PM, Dmitry Vyukov wrote:
>>> What would be a good improvement is if you add this to the kernel command
>>> options:
>>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>>
>>> This will create two vivid instances, one using the single planar API and
>>> one using
>>> the multiplanar API. That will improve the test coverage.
>>
>> Re this and collisions between multiple test processes. We actually
>> would like to have moar devices and partition them between test
>> processes. Say if we need need devices for 8 test processes, will it
>> work to specify something like "vivid.n_devs=16
>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>
>> Without giving any flags, I see 8 /dev/video* devices, does
>> vivid.n_devs defaults to 8?
>
> I am a bit lost.
>
> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
> creates 32 /dev/video* devices.
I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
vivid devices (2 video nodes for each instance), then a vim2m device and
finally two vicodec devices.
So you should always see 6 + n_devs * 2 video devices.
>
> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
> /dev/video* devices.
>
> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
>
> Also, by default there is /dev/radio0 and /dev/radio1, are these
> different types of devices, e.g. "source" and "sink"? Or they are
> identical? And the same question for other types of devices?
vivid creates two radio devices per instance: one emulates a radio tuner,
one emulates a radio modulator (so yes, source and sink). Same for vbi
(one source, one sink) and one swradio device. It also creates two cec
devices (source and sink).
>
> How can I create 8 independent partitions of devices? What devices
> will belong to each partition?
Exactly as you did above. Instance X (starting at 0) uses video nodes
3+2*X and 4+2*X.
>
>
>>> I also noticed that you appear to test only video devices. But vivid also
>>> creates
>>> vbi, radio and swradio devices. It would be nice to have those tested as
>>> well.
>>
>> Will do.
>> FTR, this is these devices:
>>
>> # ls -l /dev/{vbi,radio,swradio}*
>> crw-rw 1 root video 81, 14 Nov 9 21:07 /dev/radio0
>> crw-rw 1 root video 81, 15 Nov 9 21:07 /dev/radio1
>> crw-rw 1 root video 81, 13 Nov 9 21:07 /dev/swradio0
>> crw-rw 1 root video 81, 11 Nov 9 21:07 /dev/vbi0
>> crw-rw 1 root video 81, 12 Nov 9 21:07 /dev/vbi1
>>
>> Why are there 2 radio and vbi? Are they different? Is it possible to
>> also create more of them? Are there any other useful command line args
>> for them?
As mentioned: the first is capture, the second output. It's per vivid
instance.
CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
live with it for now.
>>>
>>> Sorry, I'm not sure what you mean.
>>
>> You said:
>>
But after calling REQBUFS or CREATE_BUFS the filehandle that
called those ioctls becomes owner of the device until the buffers are
released. So other filehandles cannot do any streaming operations (EBUSY
will be returned).
>>
>> This semantics are somewhat unfortunate for syzkaller because one test
>> process will affect/block other test processes, and we try to make
>> them as independent as possible. E.g. If this can affect syzkaller
>> ability to create reproducers, because in one run of a test if was
>> affected by an unrelated test and crashed, but if we try to reproduce
>> the crash on the same test it won't crash again because now it's not
>> affected by the unrelated test.
>>
>> But if we create more devices and partition them across test
>> processes, it will resolve this problem?
I think it will help, yes.
>>
>>
I assume that when the process dies it will release everything at
least, because fuzzer will sure not pair create with release all the
time.
