summaryrefslogtreecommitdiff
path: root/include/linux/dvb/version.h
AgeCommit message (Collapse)Author
2012-05-20[media] increment DVB API to version 5.6 for ATSC-MH frontend controlMichael Krufky
increment the DVB API version to 5.6 to signify support for controlling an ATSC-MH frontend. Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-12-12[media] DVB: Query DVB frontend delivery capabilitiesManu Abraham
Currently, for any multi-standard frontend it is assumed that it just has a single standard capability. This is fine in some cases, but makes things hard when there are incompatible standards in conjuction. Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold the same for DSS. This is not specific to any driver as it is, but a generic issue. This was handled correctly in the multiproto tree, while such functionality is missing from the v5 API update. http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this issue in the v5 API, but that hack is incapable of addressing the issue, as it can be used to simply distinguish between DVB-S and DVB-S2 alone, or another X vs X2 modulation. If there are more systems, then you have a potential issue. An application needs to query the device capabilities before requesting any operation from the device. Signed-off-by: Manu Abraham <abraham.manu@gmail.com> Acked-by: Andreas Oberritter <obi@linuxtv.org> Acked-by: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-09-03[media] DVB: increment minor version after addition of SYS_TURBOAndreas Oberritter
Signed-off-by: Andreas Oberritter <obi@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-20[media] DVB: Add basic API support for DVB-T2 and bump minor versionAndreas Oberritter
[steve@stevekerrison.com: Remove private definitions from cxd2820r that existed before API was defined] Signed-off-by: Andreas Oberritter <obi@linuxtv.org> Signed-off-by: Steve Kerrison <steve@stevekerrison.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-08-02V4L/DVB: Increment DVB API versionMauro Carvalho Chehab
A new flag were added at the Frontend capabilities. Increment API minor revision. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-09-19V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1)Patrick Boettcher
This patch increments the DVB-API to version 5.1 in order to reflect the addition of ISDB-T and ISDB-Tsb on Linux' DVB-API. Changes in detail: - added a small document to describe how to use the API to tune to an ISDB-T or ISDB-Tsb channel - added necessary fields to dtv_frontend_cache - added a smarter clear-cache function which resets all fields of the dtv_frontend_cache - added a TRANSMISSION_MODE_4K to fe_transmit_mode_t Signed-off-by: Olivier Grenie <olgrenie@dibcom.fr> Signed-off-by: Patrick Boettcher <pboettcher@dibcom.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-10-12V4L/DVB (9072): S2API: Add DTV_API_VERSION commandSteven Toth
This allows application developers to query the dvb-core API version dynamically, helping developers understand whether certain features will be available. Signed-off-by: Steven Toth <stoth@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2007-04-27V4L/DVB (5307): Add support for the cx23415 MPEG decoding features.Hans Verkuil
The cx23415 adds some extra features that this DVB decoding API did not support. This API has been expanded to support the required features. Both source and binary backwards compatibility is kept intact by these changes. So existing applications are not affected. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Ralph Metzler <rjkm@metzlerbros.de> Signed-off-by: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!