1. 16 1月, 2012 1 次提交
  2. 28 7月, 2011 3 次提交
    • H
      [media] v4l2-event/ctrls/fh: allocate events per fh and per type instead of just per-fh · f1e393de
      Hans Verkuil 提交于
      The driver had to decide how many events to allocate when the v4l2_fh struct
      was created. It was possible to add more events afterwards, but there was no
      way to ensure that you wouldn't miss important events if the event queue
      would fill up for that filehandle.
      
      In addition, once there were no more free events, any new events were simply
      dropped on the floor.
      
      For the control event in particular this made life very difficult since
      control status/value changes could just be missed if the number of allocated
      events and the speed at which the application read events was too low to keep
      up with the number of generated events. The application would have no idea
      what the latest state was for a control since it could have missed the latest
      control change.
      
      So this patch makes some major changes in how events are allocated. Instead
      of allocating events per-filehandle they are now allocated when subscribing an
      event. So for that particular event type N events (determined by the driver)
      are allocated. Those events are reserved for that particular event type.
      This ensures that you will not miss events for a particular type altogether.
      
      In addition, if there are N events in use and a new event is raised, then
      the oldest event is dropped and the new one is added. So the latest event
      is always available.
      
      This can be further improved by adding the ability to merge the state of
      two events together, ensuring that no data is lost at all. This will be
      added in the next patch.
      
      This also makes it possible to allow the user to determine the number of
      events that will be allocated. This is not implemented at the moment, but
      would be trivial.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      f1e393de
    • H
      [media] v4l2-events/fh: merge v4l2_events into v4l2_fh · 523f46d6
      Hans Verkuil 提交于
      Drivers that supported events used to be rare, but now that controls can also
      raise events this will become much more common since almost all drivers have
      controls.
      
      This means that keeping struct v4l2_events as a separate struct make no more
      sense. Merging it into struct v4l2_fh simplifies things substantially as it
      is now an integral part of the filehandle struct.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      523f46d6
    • H
      5138870d
  3. 23 3月, 2011 2 次提交
  4. 29 12月, 2010 2 次提交
  5. 09 8月, 2010 1 次提交
  6. 03 8月, 2010 2 次提交
    • I
      V4L/DVB: ivtv: Automatic firmware reload · 215659d1
      Ian Armstrong 提交于
      If the firmware has failed, this patch will automatically reload &
      restart the card. The previous card state will be restored on a
      successful restart.  Firmware reload will only happen if neither the
      encoder or decoder is active.  If the card is busy then behaviour is as
      before, returning -EIO on device access until the reload can occur. On
      cards that support video output, coloured bars will be displayed during
      the reload.
      
      Andy Walls (ivtv maintainer and patch committer) made minor tweaks to
      comments and the logged messages, but nothing substantial otherwise.
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      215659d1
    • I
      V4L/DVB: ivtv: Add firmare monitoring and debug mode to ignore firmware problems · 914610e8
      Ian Armstrong 提交于
      >From Ian's e-mail:
      When a device is opened the firmware state will be checked. If it isn't
      responding then the open will fail with -EIO.  Due to the nature of the
      hardware, a single failed check will block everything since we don't know
      exactly what has failed. A side effect of this is the blocking of debug
      access, so an additional debug level has been created which allows the block
      to be bypassed.
      
      Andy Walls' modifications:
      I modified Ian's patch to add a separate fw_debug module parameter to change
      the driver's behavior, as opposed to using the normal debug module parameter.
      The fw_debug module parameter is only available when CONFIG_VIDEO_ADV_DEBUG
      is set.
      I also made some minor whitespace adjustments and changed some warning
      messages to be a bit more specific.  s/happy/glad/g
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      914610e8
  7. 01 6月, 2010 1 次提交
  8. 19 5月, 2010 2 次提交
  9. 16 12月, 2009 1 次提交
  10. 07 4月, 2009 2 次提交
  11. 30 3月, 2009 2 次提交
  12. 03 1月, 2009 1 次提交
  13. 30 12月, 2008 1 次提交
  14. 18 10月, 2008 1 次提交
  15. 13 10月, 2008 1 次提交
  16. 12 10月, 2008 1 次提交
  17. 20 7月, 2008 1 次提交
  18. 05 6月, 2008 1 次提交
  19. 14 5月, 2008 1 次提交
  20. 30 4月, 2008 1 次提交
  21. 25 4月, 2008 2 次提交
  22. 26 1月, 2008 2 次提交
    • I
      V4L/DVB (6717): ivtv: Initial merge of video48 yuv handling into the IVTV_IOC_DMA_FRAME framework · 77aded6b
      Ian Armstrong 提交于
      Previously, all yuv data written to /dev/video48 had only basic support with
      no double buffering to avoid display tearing.
      
      With this patch, yuv frames written to video48 are now handled by the existing
      IVTV_IOC_DMA_FRAME framework. As such, the frames are hardware buffered to
      avoid tearing, and honour scaling mode & field order options. Unlike the
      proprietary IVTV_IOC_DMA_FRAME ioctl, all parameters are controlled by the
      V4L2 API.
      
      Due to mpeg & yuv output restrictions being different, their V4L2 output
      controls have been separated. To control the yuv output, the V4L2 calls must
      be done via video48.
      
      If the ivtvfb module is loaded, there will be one side effect to this merge.
      The yuv output window will be constrained to the visible framebuffer area. In
      the event that a virtual framebuffer size is being used, the limit to the
      output size will be the virtual dimensions, but only the portion that falls
      within the currently visible area of the framebuffer will be shown.
      
      Like the IVTV_IOC_DMA_FRAME ioctl, the supplied frames must be padded to 720
      pixels wide. However the height must only be padded up the nearest multiple
      of 32. This would mean an image of 102 lines must be padded to 128. As long
      as the true source image size is given, the padding will not be visible in
      the final output.
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      77aded6b
    • I
      V4L/DVB (6712): ivtv: ivtv yuv stream handling change · c240ad00
      Ian Armstrong 提交于
      Currently the yuv output stream buffer is divided into blocks whose size
      depend on the broadcast standard selected during the driver init phase.
      However, the standard can be changed after the init phase. This effectively
      breaks the yuv output stream handler, since it relies on the different yuv
      planes being block aligned.
      
      This patch changes the setup, so that the block size is always the same. The
      decoder dma function has been modified to cope with the fact that the second
      yuv plane may no longer be block aligned. The start of the yuv frame must
      still be at the beginning of a block, so the stream write function has also
      been modified to ensure this is always true.
      
      Also, the stream write function will now initiate a yuv dma transfer as soon
      as a full frame is ready. It will not wait until the current write request
      has completed, or the stream buffer becomes full.
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      c240ad00
  23. 22 10月, 2007 3 次提交
  24. 10 10月, 2007 5 次提交