currentTemperature, targetTemperature, and mode properties have "u" type.
But there is a mismatch between the property types declared in the
Q_PROPERTY macro and the org.freedesktop.DBus.Properties.PropertiesChanged
signal.
This change makes the property types consistent and match the types
declared in the xml file.
Amends a136a159f9 which changed the value in the kcfg file that the kcm reads, KWin uses options.kcfg
4f322e24d3 changed the in code default but this will be later overriden when loading the options.
Adds support for BGR888 and RGB888.
Some clients use it and we just fail to render them, making devs
thinking that kwin is broken.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
KWin already supports following org.freedesktop.locale1 for the
keyboard keymap, but only by passing a command-line option. This is
typically used in SDDM when running the greeter in kwin_wayland.
We want to use locale1 mode in livesys environments too, so that
environment-agnostic installers can configure the keyboard and also
immediatly apply the same configuration to the running desktop.
When KWin is started through `startplasma` we cannot easily supply
an extra command-line option, so we need to make this configurable
from the external environment, in the form of a KConfig.
The command-line option will keep precedence over the KConfig.
In case the current state and the pending state have the same buffer for
a particular side or a corner, that buffer can be prematurely released
because the buffer in the current state is unreferenced first.
The ref/unref order should be vice versa to ensure that the GraphicsBuffer
is not released prematurely.
This effects is off by default, which means to instruct someone how to
use it for debugging purposes, you need to both tell them to enable it,
and then also teach them how to assign a shortcut for it.
Since it's off by default, there's no harm in setting a shortcut, which
simplifies the enablement instructions. I've chosen Meta+Ctrl+Alt+P,
which uses so many modifiers that it won't conflict with anything.
This allows us to make the code that computes transition timings more
cleaner, and other time constants are in milliseconds, so it makes sense
to make m_transitionDuration store milliseconds too.
The current code is unreadable:
- it creates a lambda that captures two local variables for latitude and longitude
- then it copies values from the config to those local variables
- calls the lambda
- and finally copies the data from the local variables to the NightLightManager fields
That code can be simplified by simply calling checkLocation() directly
and using an if statement.
Morning and evening timings should be ordered correctly. When computing
the daylight duration, that ternary operator should not be needed and it
hides other bugs.
There are a couple of reasons why it's worth removing it:
- it's error prone. If one forgets to pass correct "force" flag, night
light will break
- it contributes some complexity
- updateTransitionTimings() is not called in any hot path and the code
that calculates the position of the Sun is not resource intensive
Currently, resetSlowUpdateTimers() will start a timer that will pass
m_next.first as the current time to resetSlowUpdateTimers(). This kind
of works, but there are more code paths where updateTransitionTimings()
can be called.
This change hardens updateTransitionTimings() against the current time
being very close to the start of the next transition by introducing a
time fudge factor.
If we are currently 1 second away from the start of the next transition,
then it is assumed that that transition has been reached, and we need
to calculate the timings of a transition after that.
This change simplifies the color temperature interpolation code by doing
the following:
- compute a progress value so 0 corresponds to target1, i.e. the beginning
of the transition, and 1 corresponds to target2, the end of the
transition, instead of vice versa
- and use std::lerp() function
Rounding to a multiple of ten is not needed, it is for nicer digits in
the applet, but if the applet really cares about it, it could perform
such rounding on its own. In the night light manager, it's better to avoid
rounding the interpolated values because that can result in the final
temperature getting outside of the [target1, target2] interval.
