05-01-2013, 05:29 PM
(This post was last modified: 08-03-2014, 08:48 AM by Dean Roddey.)
General Description
This thread is for discussion of the device class for TV devices. It is like that any driver that implements this device class would also implement Audio, Power, Switcher, and possibly others though it would be less common.
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 the form:
TV#fieldname
where TV# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. It is assumed that there will never be multi-unit naming concerns for TVs, i.e. that all TVs are separate entities.
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]All TVs are assumed to be standalone devices, never containing multiple units in the same enclosure.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
This thread is for discussion of the device class for TV devices. It is like that any driver that implements this device class would also implement Audio, Power, Switcher, and possibly others though it would be less common.
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 the form:
TV#fieldname
where TV# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. It is assumed that there will never be multi-unit naming concerns for TVs, i.e. that all TVs are separate entities.
The fields provided by this class are:
- AspectRatio. This field should be a read/write, enumerated string field, the limits of which list the available aspect ratios. Ratios SHOULD always be expressed in the colon based form, unless there is some strong reason why some cannot be, i.e. 16:9, 4:3. Some TVs may have special names for some ratios, so those MAY be listed if so.
- CurChannel. This field indicates the currently selected channel. It should be marked with the CurChannel semantic field type and conform to that type definition. It is purely for display, i.e. read-only, so it can be a meta-data description, a channel number, a 'dotted' channel.subchannel indicator, etc...
- SetChannel. This is a write-only field that is used to set the current channel. The format of the value written MUST be in the numeric, dotted 'channel.sub-channel' format. If sub-channels aren't supported, the driver MUST just accept any value for the sub-channel and select the main channel. If, for some reason, the TV does not have such a concept, it must provide a mapping mechanism by which the user can map arbitrary channel/subchannel values to actual channels.
Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.[/INDENT]
Multi-Unit Considerations
[INDENT]All TVs are assumed to be standalone devices, never containing multiple units in the same enclosure.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
Dean Roddey
Explorans limites defectum
Explorans limites defectum