03 Mar, 2016

1 commit

  • Add support for Intel R200 depth camera in uvc driver.
    This includes adding new uvc GUIDs for the new pixel formats,
    adding new V4L pixel format definition to user api headers,
    and updating the uvc driver GUID-to-4cc tables with the new formats.

    Tested-by: Greenberg, Aviv D
    Signed-off-by: Aviv Greenberg
    Signed-off-by: Sakari Ailus
    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: Mauro Carvalho Chehab

    Aviv Greenberg
     

12 Dec, 2015

1 commit


03 Dec, 2015

1 commit

  • Add support for Intel DS4 depth camera in uvc driver.
    This includes adding new uvc GUIDs for the new pixel formats,
    adding new V4L pixel format definition to user api headers,
    and updating the uvc driver GUID-to-4cc tables with the new formats.

    Change-Id: If240d95a7d4edc8dcc3e02d58cd8267a6bbf6fcb

    Tested-by: Greenberg, Aviv D
    Signed-off-by: Aviv Greenberg
    Signed-off-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Aviv Greenberg
     

01 Oct, 2015

2 commits

  • Remove v4l2 stuff - v4l2_buf, v4l2_plane - from struct vb2_buffer.

    Add new member variables - bytesused, length, offset, userptr, fd,
    data_offset - to struct vb2_plane in order to cover all information
    of v4l2_plane.
    struct vb2_plane {

    unsigned int bytesused;
    unsigned int length;
    union {
    unsigned int offset;
    unsigned long userptr;
    int fd;
    } m;
    unsigned int data_offset;
    }

    Replace v4l2_buf with new member variables - index, type, memory - which
    are common fields for buffer management.
    struct vb2_buffer {

    unsigned int index;
    unsigned int type;
    unsigned int memory;
    unsigned int num_planes;
    struct vb2_plane planes[VIDEO_MAX_PLANES];

    };

    v4l2 specific fields - flags, field, timestamp, timecode,
    sequence - are moved to vb2_v4l2_buffer in videobuf2-v4l2.c
    struct vb2_v4l2_buffer {
    struct vb2_buffer vb2_buf;

    __u32 flags;
    __u32 field;
    struct timeval timestamp;
    struct v4l2_timecode timecode;
    __u32 sequence;
    };

    Signed-off-by: Junghak Sung
    Signed-off-by: Geunyoung Kim
    Acked-by: Seung-Woo Kim
    Acked-by: Inki Dae
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Junghak Sung
     
  • Make videobuf2-v4l2 as a wrapper of videobuf2-core for v4l2-use.
    And replace videobuf2-core.h with videobuf2-v4l2.h.
    This renaming change should be accompanied by the modifications
    of all device drivers that include videobuf2-core.h.
    It can be done with just running this shell script.

    replace()
    {
    str1=$1
    str2=$2
    dir=$3
    for file in $(find $dir -name *.h -o -name *.c -o -name Makefile)
    do
    echo $file
    sed "s/$str1/$str2/g" $file > $file.out
    mv $file.out $file
    done
    }

    replace "videobuf2-core" "videobuf2-v4l2" "include/media/"
    replace "videobuf2-core" "videobuf2-v4l2" "drivers/media/"
    replace "videobuf2-core" "videobuf2-v4l2" "drivers/usb/gadget/"
    replace "videobuf2-core" "videobuf2-v4l2" "drivers/staging/media/"

    Signed-off-by: Junghak Sung
    Signed-off-by: Geunyoung Kim
    Acked-by: Seung-Woo Kim
    Acked-by: Inki Dae
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Junghak Sung
     

26 Sep, 2015

1 commit


30 May, 2015

2 commits

  • The UVC_DEV_DISCONNECTED flag is set when the USB device is
    disconnected, and checked in the open() handler to refuse opening a
    device that has been disconnected.

    This is inherently racy, but the race condition is taken care of in the
    V4L2 core, which also fails open() calls when the V4L2 device node has
    been unregistered. As the uvcvideo USB disconnect handler unregisters
    all its video device nodes, the UVC_DEV_DISCONNECTED flag doesn't serve
    any purpose anymore and can be removed.

    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart
     
  • Now that videobuf2-vmalloc supports exporting buffers, add support for
    the DMABUF exporter role by plugging in the videobuf2 ioctl helper.

    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart
     

08 Apr, 2015

1 commit

  • Embed the video_device struct to simplify the error handling and in
    order to (eventually) get rid of video_device_alloc/release.

    Signed-off-by: Hans Verkuil
    Cc: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     

23 Dec, 2014

1 commit

  • The Magewell XI100DUSB-HDMI[1] video capture device reports the pixel
    format "e436eb7d-524f-11ce-9f53-0020af0ba770". This is its GUID for
    BGR 8:8:8.

    The UVC 1.5 spec[2] only defines GUIDs for YUY2, NV12, M420 and I420.
    This seems to be an extension documented in the Microsoft Windows Media
    Format SDK[3] - or at least the Media Format SDK was the only hit that
    Google gave when searching for the GUID. This Media Format SDK defines
    this GUID as corresponding to `MEDIASUBTYPE_RGB24`. Note though, the
    XI100DUSB outputs BGR e.g. byte-reversed. I don't know if its the
    capture device in error or Microsoft mean BGR when they say RGB.

    [1]: http://www.magewell.com/hardware/dongles/xi100dusb-hdmi/xi100dusb-hdmi_features.html?lang=en
    [2]: http://www.usb.org/developers/docs/devclass_docs/USB_Video_Class_1_5.zip
    [3]: http://msdn.microsoft.com/en-gb/library/windows/desktop/dd757532(v=vs.85).aspx

    Signed-off-by: William Manley
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    William Manley
     

25 Nov, 2014

5 commits


21 Oct, 2014

1 commit

  • Commit e93e7fd9f5a3fffec7792dbcc4c3574653effda7 ("v4l2: uvcvideo: Allow
    using larger buffers") reworked the buffer size sanity check at buffer
    completion time to use the frame size instead of the allocated buffer
    size. However, it introduced two bugs in doing so:

    - it assigned the allocated buffer size to the frame_size field, instead
    of assigning the correct frame size

    - it performed the assignment in the S_FMT handler, resulting in the
    frame_size field being uninitialized if the userspace application
    doesn't call S_FMT.

    Fix both issues by removing the frame_size field and validating the
    buffer size against the UVC video control dwMaxFrameSize.

    Fixes: e93e7fd9f5a3 ("v4l2: uvcvideo: Allow using larger buffers")

    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart
     

22 Sep, 2014

2 commits

  • A test in uvc_video_decode_isoc() checks whether an image has been
    received from the camera completely. For this the data amount is compared
    to the buffer length, which, however, doesn't have to be equal to the
    image size. Switch to using formats .sizeimage field for an exact
    expected image size.

    [Renamed image_size to frame_size]

    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Guennadi Liakhovetski
     
  • The uvcvideo webcam driver exposes the v4l2 control "Exposure (Absolute)"
    which allows the user to control the exposure time of the webcam,
    essentially controlling the brightness of the received image. By default
    the webcam automatically adjusts the exposure time automatically but the
    if you set the control "Exposure, Auto"="Manual Mode" the user can fix
    the exposure time.

    Unfortunately it seems that the Logitech C920 has a firmware bug where
    it will forget that it's in manual mode temporarily during initialisation.
    This means that the camera doesn't respect the exposure time that the user
    requested if they request it before starting to stream video. They end up
    with a video stream which is either too bright or too dark and must reset
    the controls after video starts streaming.

    This patch introduces the quirk UVC_QUIRK_RESTORE_CTRLS_ON_INIT which
    causes the cached controls to be re-uploaded to the camera immediately
    after initialising the camera. This quirk is applied to the C920 to work
    around this camera bug.

    Signed-off-by: William Manley
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    William Manley
     

06 Mar, 2014

1 commit


01 Mar, 2014

2 commits


09 Jun, 2013

1 commit

  • Maintaining the users count using an atomic variable makes sure that
    access to the counter won't be racy, but doesn't serialize access to the
    operations protected by the counter. This creates a race condition that
    could result in the status URB being submitted multiple times.
    Use a mutex to protect the users count and serialize access to the
    status start and stop operations.

    Reported-by: Shawn Nematbakhsh
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart
     

28 Nov, 2012

4 commits


06 Oct, 2012

1 commit


16 Aug, 2012

1 commit