chill wrote: > > I think I favour the second approach, because the first isn't foolproof, > and would need further editing to support other displays.
Hi Chill, The second approach does seem better to me too , as it would be easier to maintain in the future. And thinking of future support, we might want to think about a file describing all options a particular display can have, so supporting software can find the values. When hardware is auto-detectable, Init scripts might fill in these details. With less sophisticated hardware, users can write these files, and support forums can provide examples. Such files should also be expandable to accommodate features we do not know about , like controllable backlight or touch control. I am sure this is not a new concept I come up with, so users at this forum who do know about open software development, can suggest what existing techniques are out there, and how such could fit jivelite and or piCorePlayer . BTW another piece of HW info : https://pinout.xyz/pinout/pirate_audio_3w_amp It does not list how backlight is managed ( 0, pwm, 1 ) , how the amp is enabled ( 0 or 1 ) and how this relates to the versions without an amp, but is is a start for open documentation. And the github info has not been explored jet. Regards M-H Pi based multi-room audio system powered by PiCorePlayer(s): Pi3B with Phat-dac in a Rasptouch, 2 pi B+ with Cirrus Logic Audio Card, Pi Zero with Phat-beat , and a few other tests... ------------------------------------------------------------------------ M-H's Profile: http://forums.slimdevices.com/member.php?userid=66156 View this thread: http://forums.slimdevices.com/showthread.php?t=111502 _______________________________________________ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
