On Tue, Jun 09, 2020 at 09:43:53AM +0100, Carsten Haitzler wrote: > likely going to try debug an older release of e unless you're willing to > actually hack on the code and add appropriate debug, find the issue and > identify it's the same one in the current release and maybe send a patch... :) > i can easily turn off one of my monitors and over displayport this means it > looks disconnected and then reconfigures screens. i've just tested both > side-by-side and clone here and turned my right screen on and off like ever > second or so now 5-10 times. if i keep turning it on and off fast enough > nothing happens (screen is not faded in or out - that's the sign e's randr is > about to reconfigure). if i let it sit for a second or so then e responds and > does its thing. Thanks for your answer. I stepped back a bit and had to agree that there is something wrong with hte hardware/conectivity which is in turn causing an issue in E. Fixing that in E would be nice, but the real issue is underneath, and the one I should actually fix (the display should not connect/disconnect so much).
Apparently using na HDMI cable instead of DP, seems to not trigger this problem. I'm also now trying a mini-DP to mini-DP cable that goes into a different input of the monitor to see if that helps (it looks like it might). If so, that's probably my best fix. > e does have a delay timer to at 1 second for things to settle on changes in > screens to precisely avoid the "a bunch of screens plug/unplug at about the > same time" (plugging into a dock or unplugging for example, or a dodgey > connector that disconnects and then reconnects quickly), so it already has > code > to deal with this situation. as long as it sees changes happening within 1 > second of each-other it'll keep deferring doing anything about it until that > stops. if a screen unplugs and plugs for like 0.5 sec it should ignore it > then. > like any change events from x's randr events call Yeah, I have seen that, the screen flips a few time (at more than 1Hz I hope), and eventually things settle and E tries to do what it needs to then. I may actually be helpful to allow raising this to 2-3 seconds instead of 1, but then again that might be helpful to anyone, so that's hard to say. > software stack in android and after 2 weeks of chasing a "bug" they thought > might be in the kernel driver (i was picking through it to figure out if it > was > and threw in some debugging to find out and ruled it out) it turned out that > simply the bug was already fixed a while ago in "master" in a userspace > component and we wasted multiple peoples full time jobs for a few weeks and a > whole bunch of managers stressing out over "not up to date" tendencies. it > happens far too often, so i encourage you to update first. perhaps just Yeah, I hear you. I have the latest nvidia driver, but it's likely a hardware/cabling problem in this case, so I'm going to try and fix that (substandard cables that don't like 4K? or hardware that is borderline on signalling and not fully compatible if things aren't "just right"). Thanks for the detailled answer and suggestions. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
