i didn't know bl_ppower existed... i found a device that exposes this
sysfs node and it seems it's a good idea to swizzle it too in addition
to brightness. so fix that and also fix e's backlight handling to find
backlight devices for non-lid panels marked to have a backlight ... i
have such a device here. this makes backlight controls work in this
case.
so our writes sometimes would get stuck because kernel io buffers are
full and writes are slow. on specific machines with super slow write
media and small amounts of ram this was bad.
this moves writing totally to threads. the eet file is opened in a
thread and closed in the same thread. only the eet_write/eet_data_write are
done in the mainloop. this is a 'walk struct, serialise it and compress
it" which compared to blocking for possibly multiple seconds in a
write/close/rename backup cfg files doing real io to kernel 9even
though kernle should buffer these)... is a hell of a lot better.
so sure. we block lock enough to walk the structures/lists, encode the
blob and put it through a fast lz4 compress cycle and drop into memory.
the actual write happens in the thread when the file is closed and
that is a vast improvement if you hit these cases.
Add a popup for battery. It will update if left visible. The popup
avoids polling by using a slightly delayed copy of the battery
state stored in config struct.
Playing around with steam/optimus/linux/multiple heads the popup
stuck around when i did something very unusual, so make sure it
goes...trust me i'm a professional....
This behaviour can be more intelligent, but for now it covers most
cases. Yet to see tasks in use in the wild outside a shelf, though
it can happen so should be giving something reasonable for this
choice.
so this was the hiccups have been seeing... it was temperature +eeze+
udev stalling out. tempget backend works without stalls so that is now
the only one.
As we can detect for double scan (since randr 1.2), list the mode
as valid, and also ensure the refresh rate is displayed correctly.
Each line is rendered twice, doubles the dot clock, so divide the
settings view by 2 so that it makes "sense". Can always add
flags to settings if deemed necessary.
we know where service files SHOULD go... and soif systemd is not there
to tell us, put them in the known place. this is so the non0systemd
os's can buand should build with the support but its all runtime
detected/enabled already. this means that actually no one should need
tyo go disable systemd support in builds. it's all runtime.
rememebr zone randr id where clients were if forced off a zone. if a
zone is added check clients with that zone id - if they have it then
restore them there. thbis will get loat if you move those clients
between zones after they are dumped on the other zone or you change
their virtual desktop etc.
If the comp mirror fails add a timer to delay the mirror object
creation. When iconified and in-preview on an E restart the
miror object was failing. Here we try once per icon, per
iconification. This *should* only be occurring once at this point
when E restarts.
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
additionally, this ensures that clients that cannot be layouted are
definitly outside the tree. Without applying the window tree again.
With all this tiling can be used quite normally. If you want to know
exactly what is going on, set notify level to info, then tiling tells
you what cannot be tiled.
This reverts commit 265c306874.
This is somehow the wrong way of doing that. Next commit will bring
protection against multiple recursive window_tree_apply calls.
Additionally, we should prepare to *not* accidently tile a window that
has been previously untiled.
there is an FDO version of this. it seems it's not widely supported
but the org.kde is. at some point we probbably have to move over but
for now there isn't a need, but make note of this and have DOMAIN able
to switch in a heartbeat if we want to.