Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 17 6月, 2013 1 次提交
  3. 27 5月, 2013 1 次提交
  5. 21 5月, 2013 5 次提交
  7. 24 3月, 2013 4 次提交
  9. 02 10月, 2012 1 次提交
  11. 16 8月, 2012 1 次提交
  13. 08 3月, 2012 1 次提交
  15. 13 1月, 2012 1 次提交
  17. 08 10月, 2011 2 次提交
    • M
      [media] saa7115: Trust that V4L2 core will fill the mask · e41567a6
      由 Mauro Carvalho Chehab 提交于 
      Instead of using V4L2_STD_ALL when no standard is detected,
trust that the maximum allowed standards are already filled by
the V4L2 core. It is better this way, as the bridge and/or the audio
decoder may have some extra restrictions to some video standards.

This also allow other devices like audio and tuners to contribute to
standards detection, when they support such feature.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e41567a6
    • M
      [media] saa7115: Fix standards detection · b728666b
      由 Mauro Carvalho Chehab 提交于 
      There are several bugs at saa7115 standards detection:

After the fix, the driver is returning the proper standards,
as tested with 3 different broadcast sources:

On an invalid channel (without any TV signal):
[ 4394.931630] saa7115 15-0021: Status byte 2 (0x1f)=0xe0
[ 4394.931635] saa7115 15-0021: detected std mask = 00ffffff

With a PAL/M signal:
[ 4410.836855] saa7115 15-0021: Status byte 2 (0x1f)=0xb1
[ 4410.837727] saa7115 15-0021: Status byte 1 (0x1e)=0x82
[ 4410.837731] saa7115 15-0021: detected std mask = 00000900

With a NTSC/M signal:
[ 4422.383893] saa7115 15-0021: Status byte 2 (0x1f)=0xb1
[ 4422.384768] saa7115 15-0021: Status byte 1 (0x1e)=0x81
[ 4422.384772] saa7115 15-0021: detected std mask = 0000b000

Tests were done with a WinTV PVR USB2 Model 29xx card.
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b728666b
  19. 21 9月, 2011 2 次提交
  21. 28 7月, 2011 1 次提交
    • H
      [media] v4l2-ctrls: fix and improve volatile control handling · ddac5c10
      由 Hans Verkuil 提交于 
      If you have a cluster of controls that is a mix of volatile and non-volatile
controls, then requesting the value of the volatile control would fail if the
master control of that cluster was non-volatile. The code assumed that the
volatile state of the master control was the same for all other controls in
the cluster.

This is now fixed.

In addition, it was clear from bugs in some drivers that it was confusing that
the ctrl->cur union had to be used in g_volatile_ctrl. Several drivers used the
'new' values instead. The framework was changed so that drivers now set the new
value instead of the current value.

This has an additional benefit as well: the volatile values are now only stored
in the 'new' value, leaving the current value alone. This is useful for
autofoo/foo control clusters where you want to have a 'foo' control act like a
volatile control if 'autofoo' is on, but as a normal control when it is off.

Since with this change the cur value is no longer overwritten when g_volatile_ctrl
is called, you can use it to remember the original 'foo' value. For example:

autofoo = 0, foo = 10 and foo is non-volatile.

Now autofoo is set to 1 and foo is marked volatile. Retrieving the foo value
will get the volatile value. Set autofoo back to 0, which marks foo as non-
volatile again, and retrieving foo will get the old current value of 10.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ddac5c10
  23. 01 2月, 2011 1 次提交
  25. 29 12月, 2010 1 次提交
  27. 21 10月, 2010 1 次提交
  29. 09 8月, 2010 1 次提交
  31. 01 6月, 2010 2 次提交
  33. 19 5月, 2010 3 次提交
  35. 18 5月, 2010 3 次提交
  37. 27 2月, 2010 1 次提交
  39. 07 4月, 2009 5 次提交
  41. 30 3月, 2009 2 次提交