Yea....not going to happen

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.

I don't know if it's useful. I remember i reported a problem with backlight in 2020 april
Here
https://phab.enlightenment.org/T8647e
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?

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 ... :)

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:

and 281675ee3c0c017df26cd5e76118b3cfe989f289

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:

#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),"......

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

Just for the record, I attach another crashdump: http://paste.openstack.org/show/800183

driver issue should be not an E issue, so let's close it...

In T8840#154460, @raster wrote:

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.

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.

In D12169#233047, @raster wrote:

this isnt wrong.. it's just a bit ugly... maybe just managed -> int and if (managed > 0) in later if's... :)

this isnt wrong.. it's just a bit ugly... maybe just managed -> int and if (managed > 0) in later if's... :)

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 ....

Right Here ....