05-01-2013, 05:32 PM
(This post was last modified: 08-20-2014, 08:16 AM by Dean Roddey.)
General Description
This thread is for discussion of the Switcher device class. Drivers that implement this device class provide the means to switch some number of inputs into an output. This is one of those that would probably usually be a 'fractional' device class. I.e. at the simplest, a device might only implement this one device class, but it would commonly implement other device classes, such as Audio, Power, etc...
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 the forms:
SWTCH#fieldname
SWTCH#sub~fieldname
where SWTCH# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. If there are more than one switchable output, then the sub~ part will be used to distinguish them, see Multi-Unit Considerations below.
The fields provided by this class are (leaving out prefix parts):
Because of the fact that devices may often have asymmetric lists of settable vs. current input values, there are two separate fields. Source is used to set the current source and OpSource is the current operating input. Source is read/write, though the value in it is not that important, it's just the last input type set. OpSource is readable and shows the current input. The reason this is important is that some devices have settings where you are indicating how to choose an input, not the actual input, such as auto-selection modes, or priority selection modes. In these cases, the values you can set will usually not be directly reflected as the current source input. It could be as extreme as having only Off and Auto modes settable, but with many possible sources selectable (when in auto mode.)
The Source field provides a limit that indicates the available values that can be set. DO NOT add any un-settable values to the limit, such as Unknown, because these values are presented to the user to select from. If you cannot determine the currently set mode upon startup, default it to something reasonable from among the possible options (possibly based on the current operating input.) After that, just let it store the values written to it. If the device provides separate set/get values itself, then of course update both fields from the device.
[/INDENT]
Multi-Unit Considerations
[INDENT]Drivers that implement this class may often be of the sort that provides multiple, independently switchable sources. Examples are multi-zone audio controllers and multi-zone A/V processors. In such cases, they would use the sub~ part of the name to indicate the zone. They would use the same sub-unit naming convention that is being used for the other per-zone classes in that driver. Sometimes these are nameable by the user, and sometimes they are just fixed at Z1, Z2, etc... A dedicated video processor or TV, on the other hand, would only have one output to which the available sources can be switched, and would not use the sub-unit scheme.[/INDENT]
Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
This thread is for discussion of the Switcher device class. Drivers that implement this device class provide the means to switch some number of inputs into an output. This is one of those that would probably usually be a 'fractional' device class. I.e. at the simplest, a device might only implement this one device class, but it would commonly implement other device classes, such as Audio, Power, etc...
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 the forms:
SWTCH#fieldname
SWTCH#sub~fieldname
where SWTCH# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. If there are more than one switchable output, then the sub~ part will be used to distinguish them, see Multi-Unit Considerations below.
The fields provided by this class are (leaving out prefix parts):
- Source. This field sets the input source, which may be both actual inputs or various input selection modes, such as an auto-input selection mode. This field MUST be String or Card with an Enum or Range (respectively) limit that indicates the available modes and sources that can be set. It MUST be read and write.
- OpSource. This field's value is the input that this output is currently attached to. It must be marked with the SourceInp semantic field type and conform to the definition of that type, with the added limitation that it should only be readable, not writeable.
Because of the fact that devices may often have asymmetric lists of settable vs. current input values, there are two separate fields. Source is used to set the current source and OpSource is the current operating input. Source is read/write, though the value in it is not that important, it's just the last input type set. OpSource is readable and shows the current input. The reason this is important is that some devices have settings where you are indicating how to choose an input, not the actual input, such as auto-selection modes, or priority selection modes. In these cases, the values you can set will usually not be directly reflected as the current source input. It could be as extreme as having only Off and Auto modes settable, but with many possible sources selectable (when in auto mode.)
The Source field provides a limit that indicates the available values that can be set. DO NOT add any un-settable values to the limit, such as Unknown, because these values are presented to the user to select from. If you cannot determine the currently set mode upon startup, default it to something reasonable from among the possible options (possibly based on the current operating input.) After that, just let it store the values written to it. If the device provides separate set/get values itself, then of course update both fields from the device.
[/INDENT]
Multi-Unit Considerations
[INDENT]Drivers that implement this class may often be of the sort that provides multiple, independently switchable sources. Examples are multi-zone audio controllers and multi-zone A/V processors. In such cases, they would use the sub~ part of the name to indicate the zone. They would use the same sub-unit naming convention that is being used for the other per-zone classes in that driver. Sometimes these are nameable by the user, and sometimes they are just fixed at Z1, Z2, etc... A dedicated video processor or TV, on the other hand, would only have one output to which the available sources can be switched, and would not use the sub-unit scheme.[/INDENT]
Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
Dean Roddey
Explorans limites defectum
Explorans limites defectum
