The obtained strings are passed to another function, e,g, handled as a
path and opened, printed to the terminal, written to a file, saved to
udev database as udev property, exposed through DBus, passed to logger,
and so on. Hence, these should not contain any malicious characters.
Place VERB() declarations directly above each dispatch function and use
verbs_get_help_table() in help() so the command listing stays in sync.
run() switches to dispatch_verb_with_args(); the argv_looks_like_help()
shortcut is preserved since this is an internal tool with no proper
option parsing.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
We often have a pattern where the same verb function is used for
multiple actions. This leads to an antipattern where we figure out what
action needs to be taken from argv[0] multiple times: often once in
parse_argv() to figure out what options are allowed, then once again
implicitly in dispatch_verb(), and then again in the action verb itself.
Let's allow passing a parameter into the verb to simplify this.
This matches a pattern we have in conf-parser.h, where we have both
void *userdata (more global) and void *data (per-config item). Here,
I opted for uintptr_t userdata. It seems that most of the time we'll
want to just pass an enum value. This works OK with no casts. I also
tried a void* and union. In both cases, much more boilerplate is needed:
either a cast or a macro to help avoid compiler warnings. uintptr_t
seems generic enough to cover foreseeable usecases with no fuss.
This is a noop refactoring. See next commit for an example.
Actually GNOME sets a clamp of 1% and divides in 20 steps the brightness
control. Using 5% clamp makes things like in a device with max value 640
to always be in the first brightness step in GNOME and we can't leave in
the minimum.
GNOME set steps of 640/20 = 32 with the zero step 640 * 1% = 6. When we
restart the device with the lowest bright systemd sees 6 but sets
640 * 5% = 32, so we get the brightness in the first step.
Tests in IPS and OLED panels have been done and 1% still seems a
comprensive minimun usable value so use that to allow all environments
to be able to set lower brightness values that won't be raised by
systemd at boot.
If your user enviroment allow to set excesive lower unusable values you
should blame it or yourself if you directle changes it through sysfs but
not systemd.
This commit cleans up the includes for all the small tools across
the tree.
A few cases of returning EXIT_SUCCESS are replaced with returning
0 to avoid including <stdlib.h>.
Split out of #37344.
Let's move some logic from _DEFINE_MAIN_FUNCTION() and other places
in main-func.h into functions that we implement in main-func.c to
allow moving some included headers from the header to the .c file.
Some AMD systems have support for features like custom brightness
curve or adaptive backlight management. These features allow the
display driver to adjust the brightness based upon other factors
than just the user brightness request.
The user's brightness request is indicated in the 'brightness' file
but the effective result of the logic in the display driver is stored
in the 'actual_brightness' file.
This leads to problems when shutting the system down because the value
of 'actual_brightness' may be lower than 'brightness' and the wrong value
gets stored for the next boot.
For example if the brightness a user requested was 150, the actual_brightness
might be 130. So the next boot the brightness will be "set" to 130, but the
actual brightness might be 115. If the user reboots again it will be set to 115
for the next boot but the actual brightness might be 100. That is this gets worse
and worse each reboot cycle until the system eventually boots up at minimum
brightness.
Furthermore the kernel documentation indicates that the brightness and
actual_brightness files are not guaranteed to be the same values.
Due to this; drop the use of 'actual_brightness' when saving/restoring brightness
and instead rely only upon 'brightness'.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Follow-up for e0504dd011.
Hopefully, devices in PCI subsystem have some properties, thus have
their udev database file. But, that may not be true. Here, we only read
sysattrs of enumerated devices, hence it is not necessary to check if
the device is initialized or not.
That's not gramatically correct.
In backlight, change "assocation" to "deduplication". Without the context,
it's probably not clear at all that we "associate" them to ignore them.
If a system has multiple graphics cards, then we cannot associate
platform backlight devices to backlight devices under PCI bus.
Previously, in such case, vaidate_device() for a raw backlight device
might erroneously detect a platform device and return false. So, users
could not save/load backlight level.
This makes validate_device() give up to associate platform devices on
non-PCI bus with raw backlight devices. That may cause unwanted
backlight level save or restore by systemd-backlight@.service, but users
can workaround that by masking specific instances of the service.
Closes#24223.
Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
The old code was just fine, but gcc doesn't understand that max_brightness is
initialized. Let's rework it a bit to move some logic to the main function. Now
get_max_brightness() just retrieves and parses the attribute, and the main
function decides what to do with it.
I think this formatting was originally used because it simplified
adding new options to the help messages. However, these days, most
tools their help message end with "\nSee the %s for details.\n" so
the final line almost never has to be edited which eliminates the
benefit of the custom formatting used for printf() help messages.
Let's make things more consistent and use the same formatting for
printf() help messages that we use everywhere else.
Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Mike Yuan
David Santamaría Rogado
jouyouyun
Daan De Meyer
Mario Limonciello
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Lennart Poettering