Matrix width and height have to be matched by hand to the model in Layout. Get them wrong and
the channel data does not line up.
xLights already sends the right numbers. FPP::UploadVirtualMatrixOutputs derives the size from the
MatrixModel — NodesPerString x GetNumStrings, swapped when the model is vertical — and POSTs
width, height, startChannel, channelCount and layout to
/api/channel/output/co-other.
We serve GET on that path and ignore POST, so those numbers arrive and vanish.
To do: accept the POST and feed width, height and startChannel through the same config
merge every other route uses. The model still has to be assigned to the controller's virtual matrix
port; the capability entry allows one, which is all this device has.
That would remove the hand-matching entirely.
Matrix width and height have to be matched by hand to the model in Layout. Get them wrong and
the channel data does not line up.
xLights already sends the right numbers.
FPP::UploadVirtualMatrixOutputsderives the size from theMatrixModel —
NodesPerStringxGetNumStrings, swapped when the model is vertical — and POSTswidth,height,startChannel,channelCountandlayoutto/api/channel/output/co-other.We serve GET on that path and ignore POST, so those numbers arrive and vanish.
To do: accept the POST and feed
width,heightandstartChannelthrough the same configmerge every other route uses. The model still has to be assigned to the controller's virtual matrix
port; the capability entry allows one, which is all this device has.
That would remove the hand-matching entirely.