summaryrefslogtreecommitdiff
path: root/src/settings.c
AgeCommit message (Collapse)Author
2019-11-15settings: check value in settings_apply_desc_generators()Vito Caputo
Use setting_desc_check() before storing a value.
2019-11-15settings: add setting_desc_check() helperVito Caputo
Rudimentary setting value checking against the description. For now it just enforces the multiple-choice stuff, I'm undecided on the regex support for now. It'd just be nice to throw some more informative errors when cli arguments are incorrect for things like fullscreen=yes when it only knows fullscreen=on/off.
2019-11-10settings: s/setting_desc_new/setting_desc_clone/Vito Caputo
Slight refactor to make call sites less annoying. Now takes a (setting_desc_t *) instead of the members as discrete parameters, and returns an errno on error so callers can simply propagate error codes out rather than having to get access to errno defines, check for NULL and return -ENOMEM etc. It also makes the call sites self documenting by employing designated initializers in compound literals for the supplied setting_desc_t. This is in prep for runtime-configurable module settings.
2018-02-27*: make buildable for windows w/mingw32Vito Caputo
strndup is missing, add trivial implementation signals are missing so fps counter is disabled for now
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