On Thu, 18 Jun 2020 10:09:49 -0700 Marc MERLIN <marc_...@merlins.org> said:
> 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). you could also just disable e's monitor hotplug support. hotplug support means actively handling connects/disconnects when e knows about them. if it's happening due to bad cabling or something... it's still happening. :) > 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. it may be indeed better. one of my screens sometimes (maybe once or twice a day) blanks out for like half a second then recovers (dp too - didn't happen on hdmi). it may be the cable too, but it's always been very transient... > > 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. aaah now this hits the problem. i actually spent a lot of time messing with this timeout. i ended up at 1 second as a compromise. if i had it wait 3-5 seconds everything seemed far too slow. basically you went "did it get the connect? what's going on" point as a human. it felt buggy if it was too long. if i had it change the moment got an event it could easily flicker back and forth between settings sometimes as you plug and unplug a connector it sometimes gets spurious plug and unplugs for like 0.1 or 0.2 seconds as the electrical connection is still not quite there yet as the connector slides in. i've also noted that things like unsuspend might have connectors appear one after the other but in quick succession thus also creating gaps. the 1 second ended up the happy medium i could live with with "it responds reasonably" and "it's jumping around too much al the time". > > 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 i also just added a feature "ignore disconnects" for a specific screen... it's in git master... :) so technically you could just flag a screen as a problem child and turn this on. it does mean if you use a laptop and actually dock/undock AND have "problem connectors" e can't handle the disconnect for that screen until you manually remove the "ignore disconnects" for that screen, THEN unplug it. in the end e is at the point where it doesn't know if its an actual disconnect or a broken cable. if you disable hotplug then e can use a fixed setup - probably good for a desktop that has its screens fixed in place 99.999% of the time. the "ignore disconnects" now allows a per-screen version of this for "problem screens" but ... comes with a downside. the only other option is to make this 1 second a configuration value for the user. it's not pretty but might help hide your problem a bit, but you'd need to go using git master to get such features if i added them even today... or you wait for the next release... :) > -- > "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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
