Charmed Quark Systems, Ltd. - Support Forums and Community
Class: Switcher - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (
+-- Forum: General Discussion (
+--- Forum: Device Classification (
+--- Thread: Class: Switcher (/showthread.php?tid=8306)

Class: Switcher - Dean Roddey - 05-01-2013

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:


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.

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]

Class: Switcher - Dean Roddey - 05-01-2013

(reserved for expansion)

Class: Switcher - Dean Roddey - 05-01-2013

(reserved for expansion 2)

Class: Switcher - Dean Roddey - 06-19-2014

Got this one documented. As with Matrix Switcher, it's quite simple.

Class: Switcher - Dean Roddey - 06-20-2014

The Matrix Switcher class is going to go away and this will be the only switcher type device class. Sorry for this last minute change, but it's an important one, because it will allow us to do all source switching generically. That will be a very powerful tool.

This change will be implemented in 4.4.929, and all shipped drivers will be updated to conform.

Class: Switcher - Mark Stega - 06-20-2014

I think it is very confusing to label the field "Output". If you don't like "Input" (which seems more logical to me), then how about "Source"?

Then at least you'd have SWTCH#Z1~Source or SWTCH#Source.

Saying that SWTCH#Z1~Output is the input makes no sense (to me).

Before implementing you might let a few others comment...


Even worse:


Class: Switcher - Dean Roddey - 06-20-2014

OK, yeh, Source is probably better. I'll change it to that. It has to be used for matrix switchers as well, so Input isn't really good, because it's really an output. Source is probably a reasonable compromise.

Class: Switcher - Dean Roddey - 07-29-2014

So, tightening this one up a bit, by adding the extra requirement above and beyond the semantic type that it must be read/write. That should not be a breaking change wrt to any done so far.

Class: Switcher - Dean Roddey - 08-07-2014

This one hurts, but it looks like we really should have gone with separate SetSource and CurSource fields, since they may be asymmetrical. If the device has any sort of 'auto' mode, then what is written to the field to set the current mode is not what would end up the field, that would be whatever the device selected automatically.

Also, if the device cannot provide the current source value, and the driver needs to fake it, it would want to store an Unknown value as the current source, which is not a valid value to set, so there again it would be nice to have separate settable vs. gettable values.

In this case, this would be ugly since we have a good number of V2 drivers now that use this class, and they would all have to be changed. We could do as we did with the thermo field and leave Source as read/write and what you use to set the current source, and just add a new read only field CurSource which shows the actual current source.

In devices where they are symmetrical, then both would show the same thing. If not, then the Source would stay at what you wrote to it, since that's the currently 'set' source mode, and the CurSource would show the actual currently set source.

This wouldn't break existing V2 users of this device class, all of which are symmetrical anyway, but allow for future flexibility. THey could switch over to the CurSource field as they have the opportunity.

Class: Switcher - Dean Roddey - 08-20-2014

OK, updated to reflect the final analysis, with separate settable/current operating source modes. This reflects the latest versions and what the V2 validation stuff enforces. All shipped drivers have been updated to reflect this.