Thank you, unchecking the monitor hotplug option helps (but of course this is more of a workaround). I am not sure whether this is really a problem outside of e's code, since other WMs don't exhibit this problem (while still reacting on such events).

ok after monitor switched off in 02-monitor-switched-off.txt:

Just in case it helps I have run through the sequence again and created a sequence of e output logs.

you first log doesn't seem to tell me when it suspends or resumes. no systemd? i don't see any SSS: lines that would tell me it's suspending/resuming.

In T8217#150609, @raster wrote:

in this case the xrandr tool will not be very helpful. the stdout log from e will be. the likes starting with RRR specifically. does x report screens chnanging/being plugged/unplugged before/after suspend/resume in the log? what does it say?

accepted... 19fe001f4f28287e0593ac4ac575e71e48cd0edd

in this case the xrandr tool will not be very helpful. the stdout log from e will be. the likes starting with RRR specifically. does x report screens chnanging/being plugged/unplugged before/after suspend/resume in the log? what does it say?

In T8217#150602, @ProhtMeyhet wrote:

... and I should be be giving more details. The difference I see between those two is just the following

In T8217#150357, @mbert wrote:

Sorry, I noticed this comment a bit late. Here's the output you were asking for.

Before:

before.txt1 KBDownload

After:

after.txt1 KBDownload

but that's not what the action does - it shuffles up and down by screen number which is dictated by priority. it's NOT a "move window left or right one screen" which would do what you want. :) we don't have such actions... :)

In T8601#150535, @raster wrote:

that's because you have your screens backwards. the bindings change screen count by 1 or -1 ... screens are numbered based on which is primary or not (0) as well as the priority value in the screen setup - highest priority is sorted to start of screen count. if priority is the same then it's in order of x value .... then y value for screen location.... :)

Simon Tischer <simon@t-tischer.de>

that's better :) now what do you want me to do with this. if i snarf this from phab using arcanist the commit ends up being from me n the log (not you). Can you give me an email line to use as author like:

update diff according to comments

ok. sounds good. let me actually just make a few comments in the code :)

ok, with this background information i agree with you to set the range to 0 - 100. :)
i will update the diff according

why not a range of 0 to 100? you know that 0 could be black or could just be very dim. it varies from hardware to hardware. also lowest level backlight could be hit at 10/100 if the backlight device only has 9 steps... i've seen backlights with 8 and 5 levels before... others i've seen with 8000 levels or so... others with 255, some with 100 (at the kernel interface). the whole backlight system just simplifies it to 0.0 to 1.0 at the api level in e as there is no way to know when/if the screen actually goes totally off or if 0 is just a very dim value without experimenting on each and every device. if we're suing xrandr as the controller (which we do if it offers it in x) then nothing in e sees even the number of available levels - it's also abstracted out like inside of e by the xserver/xrandr.

rebase to latest master backlight changes

that's because you have your screens backwards. the bindings change screen count by 1 or -1 ... screens are numbered based on which is primary or not (0) as well as the priority value in the screen setup - highest priority is sorted to start of screen count. if priority is the same then it's in order of x value .... then y value for screen location.... :)

*cough* *cough* please, Simon, you are capable of adding tags on your own. Please do in the future.

Sorry, I noticed this comment a bit late. Here's the output you were asking for.

Confirmed!!
Works fine now.

seems fixed from T8584, @triantares can you confirm is the same issue?

Seems like it works now, tried with a recent build, will close the report it for now in order to keep the reports clean and smaller :)

:)

alright, I forgot that the theme comes from efl and not E, confirmed the fix here too :)

i tested it, worked for me. do you build it from souce?

Can somebody confirm that the bug is fixed? I tried a new build but the issue seems to still here

hmmm i was wondering if perhaps somehow there is a mixed up config with different bits of config saying different things (like which theme to use).

@jf_simon Thank you very much. That seems very correct :)

this should fix it

tested with default theme. can reproduce the issue.
with flat theme there is no problem

In T8316#149901, @Thanatermesis wrote:

It doesn't change, same issue

It seems to be related to the default theme

It seems like .elementary/config/openSUSE-classic/base.cfg had the wrong theme installed so i'm going to try and wipe that directory openSUSE-classic is the name of the profile i'm using (openSUSE ships several other profiles)

It doesn't change, same issue

I have not really checked, but it looks like I have not had any of those problems for quite some time. So maybe we can close this (and reopen if it reoccurs).

Is this still an issue?

I can't reproduce this.