summaryrefslogtreecommitdiff
path: root/src/settings.c
AgeCommit message (Collapse)Author
2018-02-22fb,settings,drm_fb,sd_fb: const settings_t readersVito Caputo
The fb_ops entrypoints and their descendants are purely readers of the settings, so constify their settings_t instances and the operative functions which only read settings.
2018-02-20settings: introduce abstract settingsVito Caputo
Settings will be used to express configurable parameters in the rendering modules and fb backends. The goal is to address both commandline argument setting of parameters, automatic use of defaults, as well as interactive configuration including the outputting of the resulting settings in a form usable as a commandline for future reuse. Since settings can be numerous and highly varied from one module or backend to another, a form similar to the Linux kernel's cmdline or QEMU's approach has been adopted. For example, a complete DRM backend, card selection and config would be: rototiller --video=drm,dev=/dev/dri/card0,connector=LVDS-1,mode=1024x768@60 If any of the above were omitted, then the missing settings would be interactively configured. If you added --defaults, then any omissions would be automatically filled in with the defaults. i.e. rototiller --video=drm,dev=/dev/dri/card4 --defaults would use the preferred connector and mode for that card. rototiller --video=drm --defaults would do the same but also default to the /dev/dri/card0 path. for brevity, I omitted rendering modules from above, but the same approach applies simply to --module=: rototiller --module=sparkler --video=drm --defaults If you ran rototiller without any arguments, then a fully interactive setup would ensue for module and video. If you ran rototiller with just --defaults, then everything is defaulted for you. A default rendering module will be used (the original roto renderer, probably). Note that this commit only adds scaffolding to make this possible, none of this is wired up yet.
© All Rights Reserved