Closed dbu closed 10 years ago
I totally understand. LEDscape's feature set has largely been driven by the requirements of the art that I work on, and for that project, demo mode is quite useful. I actually thought I had added a command line option, but apparently I forgot, so I'm more than open to having it, and having other demo options would be awesome.
My rationale for demo mode is that, in my experience, the connection between the visualization software and BBB driver is the most common failure point, and I like to know that the BBB and LEDscape are working without relying on the rest of the stack.
As Yona alludes, work on this continues to be focused on our needs. I think we are both open to contribution and input from users on other options. I personally find demo mode very helpful when testing out hardware for a new installation. The beauty of this OS code is that it is easily modified. I think we would both be open to contributions in this regard.
I personally may add an option to spec variable "all white" options to aid in the determination of current draw DC (after the power supply) and AC (from the input source).
i am not too happy that opc-server goes into demo mode. i would prefer to disable that and and have the opc-server just leave the pixels alone until external data arrives.
i see that demo gets active when there is no data received for 5 seconds. https://github.com/Yona-Appletree/LEDscape/blob/master/opc-server.c#L798
would it make sense to have a build option to not even compile the demo thread in at all? i could also make a cli option to disable demo, and in that case not even start the demo thread.
an advanced option could be to also allow an external program as demo source. like adding opc support to rgb-test and start up that program when no data is received, but allowing to start a different configurable program.