To my understanding of how "HybridSleep" works, this makes no sense: I cannot imagine a situation where "Suspend" is not available where "HybridSleep" is. Therefore, I suggest falling back onto "Hibernate" directly instead.
Furthermore, I think a note of warning should be added, that "Suspend" continues to draw power. Maybe we should suggest users to increase the PercentageAction
value when using "Suspend" to counter that.
Is "PowerOff" not being available actually a thing? I doubt so. Also, your fallback description does not really work once there is a "Suspend" action (implemented !11 (closed)). Furthermore, I think adding a few words that strongly discourage the usage of None
under normal circumstances would be appropriate. How about this instead:
# Possible values are:
# HybridSleep: Hibernate the computer but also keep the RAM alive for as long as possible, to make wake-up faster. Falls back to regular "Hibernate" if not available.
# Hibernate: Persist the RAM to disk before shutting down, so that the current session can be resumed on the next boot. Falls back to "PowerOff" if not available.
# PowerOff: Regular shutdown of the system
# None: Do nothing. This will keep the computer running until it crashes once the battery drains empty. Using this is strongly discouraged under normal circumstances, and may cause harm to your hardware!
GNOME has some system wide setting for light/dark preferences, this should be used by default.
Shouldn't this already be the case though? Since the application would make a lookup for rules/whatever.rule
and then stop at ~/.config/foobar/rules/whatever.rule
so that /etc/xdg/foobar/rules/whatever.rule
never gets read
The entire concept of drop-ins is based on the premise that configuration can be split into parts which can be merged together somehow. This is not the case for all applications and thus we should not enforce it.
Furthermore, I dislike dictating any configuration handling mechanisms: the XDG basedir spec has always been about where to place files and how to look them up. This means that libraries implementing it can be really simple, and applications remain a lot of freedom. Your proposal would deviate from that.
When I have a PopplerDocument and render it to a Cairo context (glib API) and that document contains images: Does the PopplerDocument object decompress the pixels upon initial load or will it re-load the image for every render call? (Or something in between, like decompressing the image only on first render and then keeping it cached in memory)
Thanks for the input. Could you please give some more details about the things you proposed to get me started? Or so that I can at least roughly gauge the effort and compare it to writing my own compositor.
About performance, this shouldn't be an issue. For a start, 15 FPS would suffice, and if I managed to get 30 I'd already be happy. Since the resolution won't be 4k either, I hope this should be manageable.
Hello, is there any good way to do some screen shots or capturing the entire output of Weston programatically? I've seen that there is weston-screenshooter
, but it feels more like a tech demo to me and also I don't think it can take video recordings.
What is the easiest way to capture the output of Weston? FWIW, I am fine with controlling my own Weston session for this purpose (I plan on running a headless nested session in the end).
While we're at it, I'd also like to have the option of doing nothing, i.e. disabling the CriticalPowerAction completely. Yes, 99% of the time this is a horribly bad idea, but sometimes the battery calibration is so hopelessly broken that "continue running until power goes out" is the least bad option.
I second this. Hibernating is a notoriously broken and brittle concept, not even just on Linux. Relying on it working by default is not a good idea.
Yes, there is $XDG_STATE_HOME
now, which can be used to store logs.