Enlightenment Window Manager: GIT ONLY
Thu, Jan 21
Tue, Jan 19
Yea....not going to happen
Mon, Jan 18
Dec 11 2020
Dec 10 2020
this should be fixed now fyi.. it was just broken in how it was all handled. in adding the xinput touchapand etc. controls i also fixed this.
Dec 1 2020
I don't know if it's useful. I remember i reported a problem with backlight in 2020 april
Enlightenment disturbed backlight in all tty but it was with wayland session, not X
I solved it with "don't fade backlight".
actually i take that back. xorg has a hack. a property on root "XFree86_has_VT" and "XFree86_VT". not documented anywhere....
there is no x event or api that tells us when the user switched vt. so e doesn't know as it doesn't control the vt and is not involved in switching (xorg server does that). xserver still sends screensaver timeout events in the background while the switched-away xorg still runs so e gets a "screen went idle - screensaver kicking in" and so does that is is configured to do. in wayland mode e DOES the vt swtich. without e actively doing it the vt is locked, so e knows. i don't know what xfce does but does it dim anything?
Nov 27 2020
the change events are if a device was added, removed or properties in a device changed. its a direct result of an event from xorg ... :)
Nov 26 2020
Ok so these are my results, it seems like the lag is gone after the update, and now I read some messages about the device changes on my ~/.xsession-errors file, let me detail them:
try eeb015c0b972b6aa7322b21425077083df2be76b - avoid re-applying if device list looks the same...
hmmm that new dev changes is part of new input config. e is seeing devices changing - something is adding/removing (seemingly not as count is the same) or modifying input device properties. every time this happens, e will look at all the devices you have and ensure they are configured based on the new touchpad config. it could be e requesting input device properties because syndaemon keeps altering device properties again and again very rapidly
in x input goes directly to apps. the wm is not involved in key events getting to apps. all a wm does is set focus to a window (telling x where to send key events that are not grabbed). e's key bindings use grabs - so those keys will not go to apps but to e. i would believe your issue is with syndaemon and what it is doing with the xserver.
Now, I don't know how much related is but I rebooted the machine and trying to login in E24 and the desktop shows even much more laggy (with an E process under 100% cpu), I can read these messages in the ~/.xsession-errors file:
Nov 25 2020
Nov 21 2020
#4 0xb7e4a411 in __dlclose (handle=0x0) at dlclose.c:46
#5 0xb1ab76ad in e_drm2_compat_shutdown () at ../src/modules/../bin/e_drm2.x:65
Execute Same using SW engine, THEN let me know it fails....
" tty with enlightenment_start (Wayland is used), it seems to start fine. Then opening uxterm (Xwayland),"......
Nov 19 2020
that new bt is different to the other one - completely different. this says "heap is corrupted". the bug happened before this bt - so the bt itself is useless. you need to use ASAN or valgrind to find the real source. can't do anything with that backtrace
Nov 18 2020
Just for the record, I attach another crashdump: http://paste.openstack.org/show/800183
Nov 15 2020
driver issue should be not an E issue, so let's close it...
Nov 14 2020
Nov 11 2020
that bt doesn't show e actually crashed. if it crashds inside select... i am guessing something did a "kill -SEGV pidof enlightenment" as that is the only way i can see this happening there.
this normally happens if the filesystem is in use by something.
Nov 10 2020
this isnt wrong.. it's just a bit ugly... maybe just managed -> int and if (managed > 0) in later if's... :)
Nov 9 2020
I agree here ....
There is a part of Enlightenment settings that does Not properly respect WL ones ....
The stringshare_del in #10 looks wrong here ....