Just a note.

I pushed several patches for review here:
https://phab.enlightenment.org/D12247

I already implemented the parts in emixer (set to / update from pulseaudio default source and sink), and also change the tray icon volume image to the default sink at all times.

something is forbidding installation of the service file where dbus says service files should go

http://ppa.launchpad.net/niko2040/e19/ubuntu focal Release
404 Not Found [IP: 91.189.95.85 80]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/niko2040/e19/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

I’ve been trying with version 1.25.1 from both the source file I downloaded as well as wget

Could you please give us the version you tried to use and where it is from?

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

should be fixed now. Closing. If not, then reopen it please...

I think I was finally able to reproduce the issue, it was not in an "inactivity moment" but while watching a documentary in the external TV plugged on hdmi (like in the other moments that happened)

ok thanks for the reply. By the way i will try to maintain the current theme at because i like it more.

no. this will replace the old default. i don't have time to maintain multiple themes in parallel. flat is easier to maintain ads its simpler as well.

Hi, when the new theme will be ready the old default theme will be still provided in the new Enlightenment versions?

Guess I will do it myself....make it proper, then submit it.....

Hello @raster :-) If creating a dedicated group of keys and key bindins to filter that would work on a lock screen then fine, no specific difference for me, except we have multimedia keys (Vol+, Vol-. Mute, Play, Pause, Next, Previous, etc) on that list by default.. that should give the multimedia controls available on the lock screen by default :-)

In T8840#154321, @raster wrote:

they are logged to so if you get multiple crashes... you have them all there. the latest (one at end of log) is .. the latest crash.

those pings are the same thing you see when you run ping on the cmdline. if you enable some device as a lock device (blueze5/bluetooth) then e will ping that device to see it's around (it's the only reliable way i've found to know this). it will also do it if you enabled "force connect". these pings are debug so you know e is actually doing this. the device you set to a lock device is obviously not around... :)

they are logged to so if you get multiple crashes... you have them all there. the latest (one at end of log) is .. the latest crash.

Why on Earth assign this to me? I do not know a thing about bluetooth internals and nothing really about efl.

Thanks for the details, I wonder if the backtrace files should be re-created as new ones instead, or adding something like a bunch of spaces or date stamps to differentiate between the reports

OT Question: since I see so many lines in the crashdump file, it is created in incremental mode?

that backtrace implies its segfaulting inside select... which smells wrong.

@devilhorns i had long debates about people complaining "its so much more work" over a single click ... e.g. having to hit save then click something then ctrl+c ... like a long debate. so the "it gets dropped into this dir always and you get shown it to then do what u want with it" is avoiding extra clicks to keep them happy. you'd be amazed... :) but adding config to where to save is possible - but again... really is it necessary?

Reopen as per OPs comment. @raster

those gadgets mentioned above are now gone. so ... you can't do that lock screen gadgets thing anymore. might bring it back later with old gadgets.