diff options
author | Mike Isely <isely@pobox.com> | 2007-09-08 22:28:51 -0300 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@infradead.org> | 2007-10-09 22:14:34 -0300 |
commit | 9f66d4eac6be2428901ab6e0cbb6747d5b6794ef (patch) | |
tree | ff790fe0c5c650dfdd4e202c87397f8497990561 /arch/arm/plat-omap | |
parent | 1d643a372259749ce2029e386ed5760d5d7f8b89 (diff) | |
download | op-kernel-dev-9f66d4eac6be2428901ab6e0cbb6747d5b6794ef.zip op-kernel-dev-9f66d4eac6be2428901ab6e0cbb6747d5b6794ef.tar.gz |
V4L/DVB (6210): pvrusb2: Do a far better job at setting the default initial video standard
The v4l tveeprom logic tells us what video standards are supported by
the hardware, however it doesn't directly tell us what should be the
preferred initial standard. For example "NTSC/NTSC-J" devices are
reported by tveeprom as support NTSC-M and PAL-M, and while that might
be true, in the vast majority of cases NTSC-M is really what the user
is going to want. However the driver previously just arbitrarily
picked the "lowest numbered" standard as the initial default, which in
that case would have been PAL-M. (And making matters more confusing -
this only caused real problems on 24xxx devices because the saa7115 on
29xxx seems to autodetect the right answer anyway.) This change
implements an algorithm that uses the set of "supported" standards as
a hint to decide on the initial standard. This algorithm ONLY comes
into play if the driver isn't specifically told what to do; said
another way - the user can always still change the standard via the
sysfs interface, via the usual V4L methods, or even specified as a
module parameter. The idea here is only to pick a better starting
point if the user (or app) doesn't otherwise do something to set the
standard; otherwise this change has no real impact.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Diffstat (limited to 'arch/arm/plat-omap')
0 files changed, 0 insertions, 0 deletions