| Age | Commit message (Collapse) | Author |
|---|
|
To facilitate random setting of these flexible string-oriented
settings, support a random helper supplied with the description.
This helper would return a valid random string to be used with the
respective setting being described.
Immediate use case is the rtv module, which also gets fixed up to
use it in this commit.
|
|
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.
|
|
Just a convenience thing as settings are all string-centric and
callers like modules will probably have stuff like literal numbers
defined for defaults which need to be stringified for setting_desc_t.
|
|
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.
|
|
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.
|
|
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.
|
