1. 08 4月, 2015 3 次提交
  2. 03 4月, 2015 1 次提交
  3. 03 3月, 2015 1 次提交
  4. 02 12月, 2014 1 次提交
  5. 15 11月, 2014 1 次提交
  6. 17 7月, 2014 1 次提交
    • L
      [media] v4l: Support extending the v4l2_pix_format structure · d52e2381
      Laurent Pinchart 提交于
      The v4l2_pix_format structure has no reserved field. It is embedded in
      the v4l2_framebuffer structure which has no reserved fields either, and
      in the v4l2_format structure which has reserved fields that were not
      previously required to be zeroed out by applications.
      
      To allow extending v4l2_pix_format, inline it in the v4l2_framebuffer
      structure, and use the priv field as a magic value to indicate that the
      application has set all v4l2_pix_format extended fields and zeroed all
      reserved fields following the v4l2_pix_format field in the v4l2_format
      structure.
      
      The availability of this API extension is reported to userspace through
      the new V4L2_CAP_EXT_PIX_FORMAT capability flag. Just checking that the
      priv field is still set to the magic value at [GS]_FMT return wouldn't
      be enough, as older kernels don't zero the priv field on return.
      
      To simplify the internal API towards drivers zero the extended fields
      and set the priv field to the magic value for applications not aware of
      the extensions.
      Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      d52e2381
  7. 25 5月, 2014 1 次提交
  8. 17 6月, 2013 2 次提交
  9. 29 3月, 2013 1 次提交
  10. 24 3月, 2013 4 次提交
  11. 02 10月, 2012 1 次提交
  12. 26 9月, 2012 2 次提交
  13. 16 8月, 2012 1 次提交
  14. 07 7月, 2012 1 次提交
  15. 20 4月, 2012 1 次提交
  16. 15 2月, 2012 1 次提交
    • H
      [media] v4l2: standardize log start/end message · e2ecb257
      Hans Verkuil 提交于
      For drivers that properly use the v4l2 framework (i.e. set v4l2_dev in the
      video_device struct), the start and end messages of VIDIOC_LOG_STATUS are
      now generated automatically. People tended to forget these, but the v4l2-ctl
      tool scans for these messages, and it also makes it easier to read the status
      output in the kernel log.
      
      The cx18, ivtv and bttv drivers were changed since they no longer need to
      log these start/end messages.
      
      In saa7164 two empty log_status functions were removed.
      
      Also added a helper function to v4l2-ctrl.c that can be used as the
      vidioc_log_status callback if all you need to do is to log the current control
      values. This is now used by pwc and vivi.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Cc: Steven Toth <stoth@kernellabs.com>
      Cc: Andy Walls <awalls@md.metrocast.net>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e2ecb257
  17. 18 9月, 2011 1 次提交
    • S
      [media] cx18: Fix videobuf capture · 09fc9802
      Simon Farnsworth 提交于
      When we moved to 3.0, we found that the cx18 driver was oopsing on close with:
      
      NULL pointer deref at:
      
      [ 2290.461009] Call Trace:
      [ 2290.461009]  [<c046007b>] ? pm_qos_add_request+0xc/0x6e
      [ 2290.461009]  [<c082631c>] __mutex_lock_common+0x87/0x125
      [ 2290.461009]  [<f8970e92>] ? cx18_queue_flush+0x31/0x87 [cx18]
      [ 2290.461009]  [<c0436b85>] ? __might_sleep+0x29/0xe4
      [ 2290.461009]  [<c0826515>] __mutex_lock_slowpath+0x25/0x27
      [ 2290.461009]  [<c08264b2>] ? mutex_lock+0x2e/0x3b
      [ 2290.461009]  [<c08264b2>] mutex_lock+0x2e/0x3b
      [ 2290.461009]  [<f88d3137>] videobuf_queue_lock+0x13/0x15 [videobuf_core]
      [ 2290.461009]  [<f88d3f86>] __videobuf_free+0xfc/0x112 [videobuf_core]
      [ 2290.461009]  [<f89741e6>] cx18_v4l2_close+0x158/0x172 [cx18]
      [ 2290.461009]  [<c0507522>] ? cpumask_next+0x1a/0x1d
      [ 2290.461009]  [<f88a319d>] v4l2_release+0x35/0x52 [videodev]
      [ 2290.461009]  [<c04f5717>] fput+0x100/0x1a5
      [ 2290.461009]  [<c04f2e09>] filp_close+0x5c/0x64
      [ 2290.461009]  [<c04f2e70>] sys_close+0x5f/0x93
      [ 2290.461009]  [<c082cd5f>] sysenter_do_call+0x12/0x28
      
      Some digging showed that a merge at some previous point partially
      added broken mmap() support, causing this trace. Remove the broken
      code completely.
      
      On top of that, the calculation in place for "buffer full" depended on
      UYUV instead of HM12, while our GStreamer code was picking HM12 in
      some circumstances.
      
      Finally, the V4L2_CAP_STREAMING capability was never exposed. Patch it
      into the YUV encoder node only.
      Signed-off-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      09fc9802
  18. 28 7月, 2011 1 次提交
  19. 08 7月, 2011 1 次提交
  20. 20 5月, 2011 2 次提交
  21. 31 3月, 2011 1 次提交
  22. 23 3月, 2011 3 次提交
  23. 22 3月, 2011 1 次提交
  24. 21 10月, 2010 1 次提交
  25. 03 8月, 2010 1 次提交
  26. 01 6月, 2010 2 次提交
  27. 19 5月, 2010 2 次提交
  28. 27 2月, 2010 1 次提交