© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
And I completely misstated myself. :(
What I think I want is: 237ed86c with the current patch for this bug applied.
Here is what I'm seeing, and trying to isolate it to these two patches, or if it's something yet newer that we'll need to bisect all over again:
With current xenial (4.4.0-13 and -14), but not with the trunk prior to 237ed86c, when the OS stops sending video to the displays (in my case after screen locks and there is still no keyboard/mouse activity), then the windows get jumbled around in a manner that is consistent with X deciding that it's single-headed again, and then back to double headed.
The kernel in #40 does not exhibit this behavior. It would be interesting to see if 237ed86c with the xenial fix does or does not. If it does, then this remains an open bug. If it does not, then we have a new bug, and a need to bisect again, with 4.4.0-13 (from the archive) being the initial bad, and 237ed86c+fix as the first good. Sadly, every single kernel in that bisect will need to have the fix applied post-bisect, so lets hope it's still this bug. As of right now, initial good is 237ed86c~1(with current fix -- I don't think I tested for this when we were doing the initial bisect.)
Thanks