Summary:
these are all harmless but will trigger error messages from efl
ref T7030
Depends on D6315
Reviewers: ManMower, devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Tags: #enlightenment-git
Maniphest Tasks: T7030
Differential Revision: https://phab.enlightenment.org/D6316
It happens that some devices are considered as batteries, even if they
cannot be charged or used as a power supply for the laptop.
The ELAN device deals with the touchpad and is a "battery". When looking
at the udev info, it appears that there is no technology present as
well as the basic battery info (energy levels).
P: /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-ELAN24CC:00/0018:04F3:24CC.0003/power_supply/hid-0018:04F3:24CC.0003-battery
E: DEVPATH=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-ELAN24CC:00/0018:04F3:24CC.0003/power_supply/hid-0018:04F3:24CC.0003-battery
E: POWER_SUPPLY_CAPACITY=1
E: POWER_SUPPLY_MODEL_NAME=ELAN24CC:00 04F3:24CC
E: POWER_SUPPLY_NAME=hid-0018:04F3:24CC.0003-battery
E: POWER_SUPPLY_ONLINE=1
E: POWER_SUPPLY_PRESENT=1
E: POWER_SUPPLY_SCOPE=Device
E: POWER_SUPPLY_STATUS=Discharging
E: SUBSYSTEM=power_supply
The issue with that kind of devices is that it confuses the battery
gadget. Since two batteries are present, the total capacity is divided
by 2, resulting in the gadget displaying only 50% when the battery is
fully charged.
To avoid this, we check that the battery technology is known.
@fix
e was not properly handling the opacity hint in its 0-0xffffffff
range. in one case it converted e's color value to this range but just
with << 24 which is wrong as it then ignors the next 24 lower value
bits, so it should fill the next 3 bytes with repeats of the same
value to do this right, but far worse is on READING the value it just
used the value as-is as if it were a 0-ff (0-255) alpha value that we
use in evas and didnt "thunk it down" with val >> 24. this resulted in
renoise menus being blank as renoise set the opacity value on its
menu windows and e happily made them transparent thanks to this.
this fixes that.
not to peolpe fro the above. bitshifting DOWN is ok, but bitshifting
UP leaves the lower bits all 0 and you should fill this range with
repetitions of the value to properly scale in integert space with
bitshifts. :)
@fix
wizard module was relying on implicit symbol linking for pages. since
i chnaged dlopens to be local this broke page loading. this local
dlopen change is all about not leaking symbols into the global table
which is good/right, but this stops the wixzard setup from working, so
move to explicitly exposing symbols to the modules in a struct.
The symbol table fix on Linux doesn't translate well on BSD.
Adding code to use the older behaviour with the BSD systems
and retaining the new preferred behaviour when using dlopen(3)
on Linux.
running emixer from the mixer module popup was resulting in crashes.
it was this exe event handler handle and leaving a dangling garbage
ptr after it was deleted.
@fix
so users will be mucho displeased and bewildered when the bt adatper
is powered on but nothing happens... it ends up that with some bt adatpers
it will be rfkill blocked by default. this is highly unfriendly. at
least if you have bluez5 module loaded and configured the adatper to
be powered on... i see no reason why it shouldn't be unblocked if the
adatper is powered on. i have considerted making it an option but for
now can't think of good reasons to really do that.
so bluez itself wont go rfkill block or unblock the bt device. you
have to rfkill unblock separately if it's blocked. this is needed to
make bluez at a minimum work right. possibly should be added to
connman too. but this is the first step.
dir_sysconf was set to "etc". not even a /. this meant
enlightenment_sys couldnt find/load sysactions.conf as it used a
non-relocatable fixed location due to security (setuid root) reasons.
so i spent a few days lopening and closing the lids of a few laptops,
plugging and unplugging external screens in, plugging and unplugging
ac power and doing lots of combinations of these. this led to a whole
slew of interrealted issues that were pretty hard to detangle into
just single issues, so this is all one blob.
this fixes:
1. if a lid close gets a monitor unplug from x or e's randr wants to
unplug then this lead to slow unsuspend or lid open times as e was
reconfirguring the screens entireluy on lid open. dont do that. just
keep things as is, unless we have an external display, then reconfigure.
2. we had 2 systems monitoring for a wake. a poller and a systemd
event. this was redundant and lead to interesting things in the debug
output, so clean that up and on systemd systsems use the systemd wake
events
3. some systems dont shut down their screens on lid close, so they
stay open until screensaver timeouts kick in. bad. so also force the
screen to go off on lid close (if the lid screen is the only one we
have).
4. x seems to have a bug where if you force dpms off etc. to turn the
screen on, it still thinks it's of and wont dpms off again after that
until you eother give some input to have the wake event make the dpms
system in x think its now time to go on, or you toggle dpms on and
off, so i found toggling tricks x into thinking the right thing.
this makes some debugging also be consistent with printfs.
all in all i have a pretty well supported laptop doing swimmingly with
e and a not so well designed (acpi dsdt - missing many events like
acpi battery ones, ac power change acpi events, missing logic to power
off a closed screen in firmware or hardware and leaving it to sw...
not this laptop has a tocuh panel and extra fun points awarded since
the touch panel doesnt shut off on lid close... AND it reprots touch
events when it closes as it touches the keys/case... hooray! that has
another work-around local to my system, as efl has no mechanism to do
this).
@fix
Summary:
bluez4 support is now basically dead. nothing ships it anymore. bluez5
is a new api that is rather different so new code. also a new gui with
more complete features etc.
not everything is done as i'd like. need:
1. many more icons for device types (60-70 maybe?)
2. a few specific custom icons for some action buttons (like
pair/unpair)
3. icons for group headers
4. gadget status - the gagdte itself displays zero status. it's a
button to display a popup. that's all.
Reviewers: zmike!
Subscribers: devilhorns, cedric
Tags: #enlightenment-git
Differential Revision: https://phab.enlightenment.org/D6148
Summary:
this is part of the datadir distribution, it should not be in a different
directory than the rest of the datadir distribution
the gnu coding standards (https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
define 'datadir' as:
The directory for installing idiosyncratic read-only architecture-independent
data files for this program. This is usually the same place as ‘datarootdir’,
but we use the two separate variables so that you can move these program-specific
files without altering the location for Info files, man pages, etc.
This should normally be /usr/local/share, but write it as $(datarootdir).
(If you are using Autoconf, write it as ‘@datadir@’.)
The definition of ‘datadir’ is the same for all packages, so you should install your
data in a subdirectory thereof. Most packages install their data under $(datadir)/package-name/.
while this text has no clear requirement or suggestion for a corresponding
repository layout, projects typically employ a certain consistency in their
repository layout both for ease of maintenance and ease of learning for new
contributors.
this project has both a data/ directory, which contains the datadir distribution,
as well as the config/ directory, which also contains the datadir distribution.
this complicates matters both for active maintainers/developers who must
remember that the repository and build tree layouts have this exception,
and for new contributors who will initially be confused by this exception
other well-organized open source projects, such as wayland, have chosen to not
use a data/ directory. these projects have the datadir distribution in the base
directory of the repositor, which is a fine practice as it maintains consistency
for the project since all the files for the datadir distribution are in the same
directory.
by applying this patch, the project will move towards a more easily readable and
learnable layout. current and future developers will no longer need to wonder why
this directory is outside of the data/ directory, and anyone attempting to reference
these files from the source/build trees will be able to do so more easily
ref D6013
Reviewers: cedric, raster, bu5hm4n
Reviewed By: raster
Subscribers: devilhorns
Tags: #enlightenment-git
Differential Revision: https://phab.enlightenment.org/D6154
This commit broke e's config and therefore broke gadget key modifiers, gadget loading, among other things. This reverts the changes in config/* that broke this.
Under wayland, if a client declares itself iconified before its first
commit, we should wait until it's no longer iconified before sending it
a configure. This way it can avoid uselessly rendering buffers that
will never be displayed.
ref T6834
this fixes when you drag a wqindow to screen edge and it flips if you
use alt+drag as opposed to just dragging titlebar around without alt.
it fixes it by updating your config to allow "any modifier" for edge
flips which is actually correct.
@fix
handle quotes, escapes and so on for the shell command so you can do
things like Exec="ls" and it still work. this will also allow
executables with spaces in them as well with quotes or escapes as
backslash.
this fixes T6787
@fix
is e crashes, catches it and restarts while locked you end up
unlocked. this lets enlightenment_start know this lock down state and
it sets an env var to ensure locking happens on restart after recovery.
Turns out this is called too late in the render pass and a single frame
can occur with the old border setting. This can lead to nasty flicker
artifacts.
this moves to the newer mimeapps.list file in ~/.config from the older
defaults.list. it also provides a migration (copy file ovr if target
doesnt exist on e startup).
this fixes T6784
@fix
this shou,ld provide a compile failure for when no pam headers are
found and thus pam not enabled if we need pam for auth (i.e. linux).
so it'll be harder to foot-shoot now.also an add-on fix to T6779
if no pam support detected at build time, dont even lock to begin
with. this should fix T6779
yes - even better is making pam a requirement for building and to be
optionallhy disabled, but then even if disabled we still need this check.
this has been a long long long standing bug in e. i think this is why
we had some reports of "any password unlocks e" - because it was built
without pam support and before auth was always succeeding without pam.
now it is always FAILING instead (which is probably better).
@fix
The gadget can now live in both shelves and bryces.
There is still a strange issue in the popup: the progressbar
(that should be hidden on show) dont want to honor the
evas_object_hide call. This only happen when inside an elm
ctxpopup while works as expected when in a gadcon popup, so
I suspect a bug in ctxpopup...