so memset_s still doesn't get detected (add a check anyway), but there
are other alternatives, so detect and use them if found
(explicit_bzero, explicit_memset) in addition to the generally
"practically works" memset ptr method we had and.. just to be extra
safe add an asm memory barrier to this fallback. also.. mlock the
passwd memory in lokker (if it doesn't work - don't worry - there is
nothing we can do, so we did our best) to avoid this memory gettign
swapped etc.
beating on ddc support to make it solid. dealing with some bad screens
that don't respond, a libddcutil that was doing a printf messing up
the message stream from e_system to e .... and more.
this ensures things like on login e setsup backlights fine - also on
monitor add/plug-in as when e's backlight init happens it may not see
all screens or devices yet.
so if monitor is buys waking up from dpms, it may not be bothering to
do what we asked... but the sets of the propety say they succeed, so
use the get at the end of a fade in run to see if we get the target
brightness within some delta and it's one of our standard brightnesses
(1.0, normal or dim) and retry a few times until we succeed or give
up. this ensures on wakupe your monitors end up at their target
brightness even with some hiccups as opposed to stay dim. not much we
can do about iffy hardware or libddcutil (not sure which is to blame)
other than do workarounds like this.
also add logging so you can see what is being asked and if it succeeds
or fails according to libddcutil.
just by luck the queue "play catchup" happens to have a classic
scheduling issue. one screen always wins, the other always loses as we
play catch-up in the request queue so one is starved of "scheduling
slots" while the othe rgets them all. this fixes that by moving the
entire request queue into the thread work queue in one go so they all
get an equal chance. now botjh my desktop monitors dim smoothly on
idle like my laptop... smooooooooood
This adds ddc monitor control and glues it into the backlight system.
A result of this is now backlgiht control gadgets work screen by
screen and even on desktop monitors as well as on a laptop panel. If
you now put a backlight gadget on a shelf on each screen... it will
control THAT screen's backlight.
This requires libddcutil to be installed. That will require i2c
modules (i2c-dev specifically). This means that this is likely not
going to do anything useful on bsd's... unless libddcutil happens to
work there by chance.
so install ddcutil/libddcutil. ensure it's in ld.so.conf so setuid
root processes find it (as LD_LIBRARY_PATH won't help) and enjoy your
new funcky per-screen backlight controls... :)
@feature
Summary:
What i have done:
- Open slider will update using mouse wheel over light bulb
- Open slider will update using keybindings
- Slider shows now a value between 1 and 100 (no double value is displayed anymore)
- Removed unnecessary code for shelf module
- removed code for buggy popup using keybindings (may add later an option for showing popup on backlight change)
I am still learning. please consider :)
Greetings Simon
Reviewers: bu5hm4n, morlenxus, devilhorns, raster
Subscribers: cedric, zmike
Tags: #enlightenment-git
Differential Revision: https://phab.enlightenment.org/D11065
now it really does look for the right way to control per screen and
only use the new e_system back-end to query/list devices etc. ...
this now opens the door to adding ddc support to e_system then using
it from e_backlight.
i can't test this... yet - but this means in theory the backlight
gadget will control the backlight of the screen it is on...
Mike Blumenkrantz
Alastair Poole