1. 14 5月, 2012 3 次提交
  2. 08 5月, 2012 2 次提交
  3. 20 4月, 2012 1 次提交
  4. 18 4月, 2012 2 次提交
  5. 11 4月, 2012 1 次提交
  6. 20 3月, 2012 1 次提交
  7. 08 3月, 2012 1 次提交
    • H
      [media] v4l2-ctrls: v4l2_ctrl_add_handler should add all refs · 072e6602
      Hans Verkuil 提交于
      Currently v4l2_ctrl_add_handler adds only the controls that are owned
      by the handler. This is wrong. Instead all controls, whether owned or
      not, should be added.
      
      This is also implied by the v4l2-controls.txt documentation and it is
      clearly the right thing to do. The only reason this was never noticed
      before is because we never did this. Only recent changes in ivtv made
      this error visible because there a third handler layer was added (handler
      A inherits from handler B which inherits from C, D and E). Without this
      change handler A only sees the controls owned by handler B and the controls
      from C, D and E are missing.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      072e6602
  8. 29 2月, 2012 1 次提交
    • S
      [media] V4L: Add JPEG compression control class · c7361ae1
      Sylwester Nawrocki 提交于
      The V4L2_CID_JPEG_CLASS control class is intended to expose various
      adjustable parameters of JPEG encoders and decoders. Following controls
      are defined:
      
       - V4L2_CID_JPEG_CHROMA_SUBSAMPLING,
       - V4L2_CID_JPEG_RESTART_INTERVAL,
       - V4L2_CID_JPEG_COMPRESSION_QUALITY,
       - V4L2_CID_JPEG_ACTIVE_MARKER.
      
      This covers only a part of relevant standard specifications. More
      controls should be added in future if required.
      
      The purpose of V4L2_CID_JPEG_CLASS class is also to replace some
      functionality covered by VIDIOC_S/G_JPEGCOMP ioctls, i.e. the JPEG
      markers presence and compression quality control. The applications
      and drivers should switch from the ioctl to control based API, as
      described in the subsequent patches for the Media API DocBook.
      Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c7361ae1
  9. 15 2月, 2012 2 次提交
  10. 14 2月, 2012 1 次提交
  11. 18 1月, 2012 1 次提交
  12. 31 12月, 2011 2 次提交
  13. 08 11月, 2011 2 次提交
    • H
      [media] v4l2-ctrl: Send change events to all fh for auto cluster slave controls · 1249a3a8
      Hans de Goede 提交于
      Otherwise the fh changing the master control won't get the inactive state
      change event for the slave controls.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      1249a3a8
    • H
      [media] v4l2-event: Don't set sev->fh to NULL on unsubscribe · e3e72f39
      Hans de Goede 提交于
      Setting sev->fh to NULL causes problems for the del op added in the next
      patch of this series, since this op needs a way to get to its own data
      structures, and typically this will be done by using container_of on an
      embedded v4l2_fh struct.
      
      The reason the original code is setting sev->fh to NULL is to signal
      to users of the event framework that the unsubscription has happened,
      but since their is no shared lock between the event framework and users
      of it, this is inherently racy, and it also turns out to be unnecessary
      as long as both the event framework and the user of the framework do their
      own locking properly and the user guarantees that it holds no references
      to the subcribed_event structure after its del operation has been called.
      
      This is best explained by looking at the only code currently checking for
      sev->fh being set to NULL on unsubscribe, which is the v4l2-ctrls.c send_event
      function. Here is the relevant code from v4l2-ctrls: send_event():
      
      	if (sev->fh && (sev->fh != fh ||
      			(sev->flags & V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK)))
      		v4l2_event_queue_fh(sev->fh, &ev);
      
      Now lets say that v4l2_event_unsubscribe and v4l2-ctrls: send_event() race
      on the same sev, then the following could happens:
      
      1) send_event checks sev->fh, finds it is not NULL
      <thread switch>
      2) v4l2_event_unsubscribe sets sev->fh NULL
      3) v4l2_event_unsubscribe calls v4l2_ctrls del_event function, this blocks
         as the thread calling send_event holds the ctrl_lock
      <thread switch>
      4) send_event calls v4l2_event_queue_fh(sev->fh, &ev) which not is equivalent
         to calling: v4l2_event_queue_fh(NULL, &ev)
      5) oops, NULL pointer deref.
      
      Now again without setting sev->fh to NULL in v4l2_event_unsubscribe and
      without the (now senseless since always true) sev->fh != NULL check in
      
      1) send_event is about to call v4l2_event_queue_fh(sev->fh, &ev)
      <thread switch>
      2) v4l2_event_unsubscribe removes sev->list from the fh->subscribed list
      <thread switch>
      3) send_event calls v4l2_event_queue_fh(sev->fh, &ev)
      4) v4l2_event_queue_fh blocks on the fh_lock spinlock
      <thread switch>
      5) v4l2_event_unsubscribe unlocks the fh_lock spinlock
      6) v4l2_event_unsubscribe calls v4l2_ctrls del_event function, this blocks
         as the thread calling send_event holds the ctrl_lock
      <thread switch>
      8) v4l2_event_queue_fh takes the fh_lock
      7) v4l2_event_queue_fh calls v4l2_event_subscribed, does not find it since
         sev->list has been removed from fh->subscribed already -> does nothing
      9) v4l2_event_queue_fh releases the fh_lock
      10) the caller of send_event releases the ctrl lock (mutex)
      <thread switch>
      11) v4l2_ctrls del_event takes the ctrl lock
      12) v4l2_ctrls del_event removes sev->node from the ev_subs list
      13) v4l2_ctrls del_event releases the ctrl lock
      14) v4l2_event_unsubscribe frees the sev, to which no references are being
          held anymore
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e3e72f39
  14. 04 11月, 2011 1 次提交
  15. 01 11月, 2011 1 次提交
  16. 21 9月, 2011 2 次提交
    • H
      [media] v4l2-ctrls: implement new volatile autocluster scheme · 5626b8c7
      Hans Verkuil 提交于
      The problem tackled in this patch is how to handle volatile autoclusters
      correctly. A volatile autocluster is a cluster of related controls where one
      control is the control that toggles between manual and auto mode and the other
      controls are the values for the manual mode. For example autogain and gain,
      autoexposure and exposure, etc.
      
      If the hardware lets you read out the automatically calculated manual values
      while in automode, then those manual controls should be marked volatile.
      
      gain value as calculated by the autogain circuitry, then you would mark the
      gain control as volatile (i.e. continuously changing).
      
      The question in such use cases is what to do when switching from the auto
      mode to the manual mode. Should we switch to the last set manual values or
      should the volatile values be copied and used as the initial manual values.
      
      For example: suppose the mode is manual gain and gain is set to 5. Then
      autogain is turned on and the gain is set by the hardware to 2. Finally
      the user switches back to manual gain. What should the gain be? 2 or 5?
      
      After a long discussion the decisions was made to keep the last value as
      calculated by the auto mode (so 2 in the example above).
      
      The reason is that webcams that do such things will adapt themselves to
      the current light conditions and when you switch back to manual mode you
      expect that you keep the same picture. If you would switch back to old
      manual values, then that would give you a suddenly different picture,
      which is jarring for the user.
      
      Additionally, this would be difficult to implement in applications that
      store and restore the control values at application exit and start.
      
      If you want to keep the old manual values when you switch from auto to
      manual, then there would have to be a way for applications to get hold
      of those old values while in auto mode, but there isn't.
      
      So this patch will do all the heavy lifting in v4l2-ctrls.c: if you go
      from auto mode to manual mode and the manual controls are volatile, then
      g_volatile_ctrl will be called to get the current values for the manual
      controls before switching to manual mode.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5626b8c7
    • H
      [media] v4l2-ctrls: replace is_volatile with V4L2_CTRL_FLAG_VOLATILE · 88365105
      Hans Verkuil 提交于
      With the new flag there is no need anymore to have a separate is_volatile
      field. Modify all users to use the new flag.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      88365105
  17. 28 7月, 2011 16 次提交