1. 13 Apr, 2012 1 commit
  2. 12 Apr, 2012 2 commits
  3. 11 Apr, 2012 7 commits
  4. 10 Apr, 2012 1 commit
  5. 07 Apr, 2012 1 commit
  6. 06 Apr, 2012 1 commit
  7. 05 Apr, 2012 1 commit
    • Rémi Denis-Courmont's avatar
      v4l2: rewrite frame rate and resolution negotiation · 590f52e6
      Rémi Denis-Courmont authored
       * Enumerate frame sizes once rather than twice.
       * Do not enumerate frame rates if not supported.
       * Get actual frame rate from the device driverr.
       * Get exact fractional frame rate rather than round to single precision
         floating point.
       * --v4l2-fps becomes totally redumdant. It should probably be redefined
         to select a maximum capture frame rate.
       * --v4l2-width and --v4l2-height are ignored. This is a regression.
         Maybe they should be redefined as maxima as well as --v4l2-fps.
  8. 04 Apr, 2012 3 commits
    • Rémi Denis-Courmont's avatar
      v4l2: remove stray structure · 57ec6a0c
      Rémi Denis-Courmont authored
    • Rémi Denis-Courmont's avatar
      v4l2: remove dead userptr code · 644e9c55
      Rémi Denis-Courmont authored
    • Rémi Denis-Courmont's avatar
      v4l2: use device node capabilities rather than whole device's · b80cbc8a
      Rémi Denis-Courmont authored
      "capabilities" counter-intuitively specifies the overall capabilities of
      all device nodes provided by the given instance of the device driver.
      "device_caps" specifies the capabilities of the opened device node,
      if the V4L2_CAP_DEVICE_CAPS bit is set in "capabilities" (phew!).
      Those two sets of capabilities are different if the hardware has
      multiple functions, e.g. both video and VBI capture.
      VLC cares about the fact that the specific device node supports video
      capture or not, so lets use "device_caps" when available. Unfortatunely,
      this requires kernel version 3.4. In practice, this would only cause an
      actual failure if V4L2_CAP_STREAMING is set even though the current node
      does not support streaming I/O, I think.
  9. 23 Mar, 2012 2 commits
  10. 22 Mar, 2012 2 commits
  11. 20 Mar, 2012 1 commit
  12. 15 Mar, 2012 2 commits
  13. 07 Mar, 2012 1 commit
  14. 31 Oct, 2011 1 commit
    • Rémi Denis-Courmont's avatar
      v4l2: fix step-wise and continuous frame sizes enumeration · 8853c752
      Rémi Denis-Courmont authored
      Width and height are independent for step-wise frame sizes (yes,
      enumerating is slow). Continuous frame sizes are step-size with one
      pixel steps for both dimensions (yes, enumerationg is very slow).
      A few device drivers use either of those two types, though the discrete
      type is much more common.
  15. 01 Oct, 2011 1 commit
    • Rémi Denis-Courmont's avatar
      Rewrite V4L2 controls to keep a list of them (fix #5269) · dfe2b31c
      Rémi Denis-Courmont authored
      The V4L2 plug-in is a bit peculiar with dynamically generated object
      variables. We need to keep track of which controls/variables we have,
      so that we can remove the variables callbacks later. The only other
      way to solve this bug, that I could think of, consisted of extending
      the VLC variables subsystem (which would be worse in code freeze).
      This rewrite also fixes a few other bugs:
       * Support menu with non-zero based minumum choice
       * Support menu with discontinuous choices range
       * Redumdant use the extended controls API as fallback
         (This only makes sense to set more than one control at a time,
          or to set 64-bits and string controls. VLC does none of that.)
       * Unused "controls-update" and "allcontrols" variables.
       * Skipping disabled, read-only and volatile controls.
      Support for the legacy control enumeration API (pre-2.6.18 kernel) is
      removed; and the code is now independent of the VLC object type (it
      could easily be reused for say, a V4L2 video output).
  16. 07 Sep, 2011 1 commit
  17. 06 Sep, 2011 5 commits