This reverts commit ee71ea63ec.
Revert "reduce include deps for enlightenment_thumb binary"
This reverts commit cce14fa839.
both of these i reverted.... because they both CHANGE the define of
E_API like:
and this is wrong. e.h defines this so that these symbols are exposed.
E_API, EAPI and friends are desighned to explicitly expose symbols.
because if you try and make STRICTER binaries that only have symbols
for what was EXPLICTLY exposed like the CFLAG -fvisibility=hidden ...
then any api not explicitly marked with the attribute of visible which
that E_API macro is intended for... will be invisible. it will not
exist. this means a whole MOUNTAIN of modules stop loading as they
can't find these symbols. E_API isn't just source sugar tagging. it's
actually functional. i'd suggest using -fvisibility=hidden in your
CFLAGS by default. it's also not always portable between all compilers
so beware... (it was introduced years ago in gcc... i think clang
offers it. i don't know about icc or any others).
so since E_API is defined in e.h ... we may as well keep the e.h
include there instead of hand re-writing a list of includes. does
reducing the include deps really have an impact worth talking about on
compile time? the commit logs didn't say. but it does break module
loading and does it by adding lots of lines of code that are far mroe
easily broken now (this is an examplt). :)
in the case where the desklock timer was longer than the blank timer,
this would permanently break input
input is still broken for the duration of the screen blank animation and
any time the screen is blanked
we have some visual glitches i'm on a mission to fix... and the above
is one of those. timeout for lock should begin after screen has gone
black first.
This reverts commit 7bc179da5a.
this now totally broke the glitch fix and it now animates in reverse
on suspend and does nothng on resume... testing might be a good idea
beforehand...
this requires we have to force dpms on to reduce power. to avoid
glitches with the pointer staying around in x we need to support
suspending it too so it hides cleanly like the screen dims or undims.
also use the new powersave freeze mode to do this.
note that i've tested this on s3 supporting laptops and non-s3 and it
"works for me". it may require more testing and work. there is more to
power saving than just this as well but for now that's out of scope as
you have to mess with linux device autosuspend timeouts and a bunch
more (wowlan ... blahblah).
i need to find the source of the intermittent wakeups too in e. there
is a long lived timeout (8-ish seconds?) but more specifically e keeps
waking up from fd's and then reading /sys stuff about battery - some
event is causing us to do this... maybe to suspend this or make
battery checking very rare when in freeze mode (or screen off) etc.
so this fixes some glitches as well as supports a new way of sleeping
"alive" when hardware literally doesnt support normal s3 sleep... so
kind of a fix with a feature.
so new laptops now seem to no longer support S3 sleep. sleeping is
done basically by going as idle as possible. you can ask the kernel to
freeze execution BUT this seems to use about the same power as staying
alive in my tests. to support this add 2 things:
1. a FREEZE powersave mode which implies we're alive but want to
really stay as idle as absolutely possible.
2. powersave aware sleep functions that replace the usleeps in threads
so they can switch from being super sleepy when in freeze mode to
normal.
Mike Blumenkrantz
Carsten Haitzler
Derek Foreman
Amitesh Singh