05-01-2013, 05:42 PM
(This post was last modified: 08-03-2014, 08:54 AM by Dean Roddey.)
General Description
This thread is for discussion of the device class for radio tuners, over the air or virtual and so forth. The functionality here is fairly limited. Dedicated tuner devices, many A/V processors, and some other media type devices are likely to implement this class.
Fields Provided
[INDENT]The fields provided by this device class have pre-determined names, and these MUST be implemented as indicated here. They are all prefixed by the device class prefix in one of these forms:
TUNR#fieldname
TUNR#sub~fieldname
where TUNR# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. It will not be uncommon that there will be multi-unit concerns, since many devices that support multiple internal powered units. See below for multi-unit concerns.
The fields provided by this class are:
Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.[/INDENT]
Multi-Unit Considerations
[INDENT]It is not unlikely that this device class will be used within a device that supports multiple, independent sub-units. Where that is the case, apply the same per-sub-unit prefix to these fields that are otherwise being used in that driver, or user provided sub-unit names.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
This thread is for discussion of the device class for radio tuners, over the air or virtual and so forth. The functionality here is fairly limited. Dedicated tuner devices, many A/V processors, and some other media type devices are likely to implement this class.
Fields Provided
[INDENT]The fields provided by this device class have pre-determined names, and these MUST be implemented as indicated here. They are all prefixed by the device class prefix in one of these forms:
TUNR#fieldname
TUNR#sub~fieldname
where TUNR# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. It will not be uncommon that there will be multi-unit concerns, since many devices that support multiple internal powered units. See below for multi-unit concerns.
The fields provided by this class are:
- CurPreset. This field supports the common functionality of tuners to support presets. This field MUST be a string type. It MUST be readable, so that the current preset can be displayed. If the device doesn't make this information available, then leave it blank. If the device supports direct setting of presets, then it MAY be writeable and have an enumerated limit that indicates the available presets.
- CurFrequency. This field MUST be read only, and be a text field into which the current selected frequency is placed. If the device doesn't make this information available, the driver MUST leave the field blank.
- NextPrevPreset. This field MUST be Boolean, and write only. Writing False to it will move to the previous preset, and writing True will move to the next preset. If toggling in one or both directions is unavailable, then do nothing. If this sort of toggling isn't directly supported, the driver should where possible fake it via reading, incrementing/decrementing, and writing back out the current preset.
Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.[/INDENT]
Multi-Unit Considerations
[INDENT]It is not unlikely that this device class will be used within a device that supports multiple, independent sub-units. Where that is the case, apply the same per-sub-unit prefix to these fields that are otherwise being used in that driver, or user provided sub-unit names.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
Dean Roddey
Explorans limites defectum
Explorans limites defectum