xdg-output was used to extract the output name, which can be obtained
from wl_output as of interface version 4, release in Wayland 1.20 almost
two years ago.
display_dispatch tried to flush the display in a loop until it no longer
returns an error that is EAGAIN or EPIPE. This becomes an infinite loop
if the socket is closed.
Stop flushing if we hit EPIPE, as the connection is dead. We still try
to read what we were sent to the protocol error shows up in debug
output.
When entering manual time, the timezone was adjusted in the time input
instead of storing the time offset. The time offset is necessary to
calculate the correct day boundaries.
Remove the timezone correction of time input and instead adjust the time
offset accordingly.
When configured to perform a very quick transition, the step time for 25
kelvin may end up being less than 1 second, rounding to zero. A zero
step time does not make any sense.
Useful for laptops with external displays connected. External displays
usually have an ability to adjust color temperature via built-in menu,
so you can run `wlsunset` exclusively for laptop's internal display.
Also different screens happen to look differently after setting the same
color temperature. Possibly has to do with the technology which
display is based on (TN or IPS).
FreeBSD has BSD extension timezone, which conflicts with XSI extension
with the same name, according to time.h:
char *timezone(int, int); /* XXX XSI conflict */
...
FreeBSD also has long tm_gmtoff member of struct tm, which is offset
from UTC in seconds, according to time.h:
struct tm {
...
long tm_gmtoff; /* offset from UTC in seconds */
char *tm_zone; /* timezone abbreviation */
}
which is the same as XSI extension timezone.
Co-authored-by: Jan Beich <jbeich@FreeBSD.org> (downstream patch)
Reviewed by: Kenny Levinsen <kl@kl.wtf>
The new -S/-s/-d flags allow for manually specifying the time of sunset,
ssunrise in the format of HH:MM, and the transitional animation duration
in seconds, respectively.
This is implemented by sidestepping the calc_sun call in manual mode.
The rest of wlsunset operates as usual.
D65, the natural whitepoint that wlsunset assumes, is defined on
illuminant D, which simulates daylight with atmospheric effects.
However, we used planckian locus for all values under 6500 K, which
meant that there was a significant jump in color - specifically, a
sudden reduction in green and blue - as we started reducing the color
temperature.
Instead, we purely use illuminant D down to 4000 K where it is well
defined. Below 4000 K, illuminant D starts unintentionally approaching
the planckian locus, before finally breaking completely at 2000 K. We
extend the boundary of illuminant D to 2500 K and perform a
sine-smoothed transition to planckian locus from 4000 K to 2500 K to
extend the range of wlsunset down to 1667 K, where planckian locus ends
and we finally give up.
The end-result is a smooth transition along all valid temperature
values, with no sudden jumps as we had before. However, we do end up
with slightly greener/bluer colors than earlier. We'll have to see how
that holds up.
Clang cannot decide how it wishes to handle implicit-fallthrough, with
different solutions across different versions, which presents a problem
on FreeBSD where several majors of clang remain relevant.
Disable implicit-fallthrough until clang has figured out what it wants
to do in life.
calc_sun reported sun trajectory in seconds since the start of a UTC
day, as they would occur for the specified UTC day. The caller would
then add the UTC timestamp for the start of a UTC day to these numbers.
This lead to complications, as e.g. a sunrise in China would be a
negative value, as it occurred in the last UTC day.
Futhermore, the start of a UTC day was used to signal the need for new
sun calculations. This would lead to recalculations to possibly occur
after its results were needed, such as after sunrise when the target
longitude deviated significantly from the prime meridian.
To fix this, we apply longitude time correction to the start of day
calculation. This way recalculation will occur on the start of the
longitude local day, close midnight for the observer.
We also remove the longitude time correction from calc_sun, so that it
simply returning the number of seconds since the start of the local day
of the observer. The caller then adds the start of the longitude local
day to get the final numbers.
The sun trajectory calculation previously emitted garbage if midnight
sun or polar night phenomena was in effect. To fix this, the calculation
is overhauled to report if the computation failed, and if so, which
specific phenomena was the cause.
Timing recalulation uses this information to change out of the normal
state that uses the four sun position timings, into a static state where
wlsunset simply waits a day at a time for a normal sun trajectory
pattern to be restored. In this state, a fixedc high/low temperature is
set as appropriate for the phenomena.
A transition phase replicating the previous day's sunrise is used to
smooth out entry into a midnight sun, which would otherwise cause a
jarring instant-daylight setting.