In xfsettingsd 4.11.2 there appears to be a regression that when a TV hooked up to the computer via HDMI gets power cycled, it stops displaying anything. It happens via a RANDR event being sent to all X clients when the TV gets turned off. xfsettingsd thinks that it should switch to an internal output, but desktops don't have one. So when the TV comes back on the bus it seems like it's an extra monitor and xfsettingsd gets confused. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 447. xfce4-settings(displays): Detected CRTC 448. xfce4-settings(displays): Noutput: before = 1, after = 0. xfce4-settings(displays): Output disconnected: HDMI-0 xfce4-settings(displays): Disabling CRTC 447. xfce4-settings(displays): No active output anymore! Attempting to re-enable the internal output. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 447. xfce4-settings(displays): Detected CRTC 448. xfce4-settings(displays): Noutput: before = 0, after = 0. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 447. xfce4-settings(displays): Detected CRTC 448. xfce4-settings(displays): Detected output 452 HDMI-0. xfce4-settings(displays): Noutput: before = 0, after = 1. xfce4-settings(displays): New output connected: HDMI-0 Additional details can be found on the Ubuntu bug report located here: https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1308105
I just bisected the git repository of xfce/xfce4-settings and identified the commit that introduced the issue as: ------------------------------------------ dbd76eb58bd9d7a55de753daa5572ef24867d924 Author: Lionel Le Folgoc <lionel@lefolgoc.net> 2012-11-08 20:15:42 Committer: Simon Steinbeiss <simon.steinbeiss@elfenbeinturm.at> 2012-11-08 20:50:40 Parent: 82ab3a355a4b7eff6cffa57ca5a8e8622feb2d31 (l10n: Updated Portuguese (pt) translation to 100%) Child: cf67ba0d283d991c67a4e3df2de758f94cb2f7d2 (l10n: Updated Spanish (Castilian) (es) translation to 99%) Branches: master, remotes/origin/bluesabre/display-settings, remotes/origin/bluesabre/display-settings2, remotes/origin/master, remotes/origin/ochosi/primary Follows: xfce4-settings-4.11.0 Precedes: xfce4-settings-4.11.1 Re-enable the internal display when the external one is disconnected (and add the possibility to start xfce4-display-settings --minimal when a new display is connected) Signed-off-by: Simon Steinbeiss <simon.steinbeiss@elfenbeinturm.at> ------------------------------------------ Building and using its immediate predecessor fixes the issue for me. Can anybody confirm? I am currently investigating the code, trying to find what's wrong. However, I have little to no experience regarding the code base, so this might take a while. Any help would be greatly appreciated.
I am currently stuck analyzing this issue. The following considerations refer to commit dbd76eb58bd9d7a55de753daa5572ef24867d924. After adding lots of debug output to displays.c, I noticed a potential issue in static GPtrArray* xfce_displays_helper_list_outputs (XfceDisplaysHelper*) which contains the line of if (output_info->connection != RR_Connected) When powering off a screen and powering it on again, the value of output_info->connection is always 1 (=RR_Disconnected). Hence, the rest of the surrounding loop's iteration is skipped, no modes are detected, etc. According to my current understanding (which might be completely erroneous) of how the code works, this is wrong and it could hint to the actual cause of the issue - which I'm still unable to identify. Further observations: xfce_displays_helper_list_outputs is called twice in displays.c - once by xfce_displays_helper_init(...) and once by xfce_displays_helper_reload(...). In the former case, (output_info->connection != RR_Connected) is false for one of my outputs, thus modes are getting detected, etc. In the latter, it is not. Can anybody assess whether or not I am on the right track? Any help debugging this would still be greatly appreciated. :)
Created attachment 5681 HDMI power cycling patch Created and attached a small patch that fixes the issue for me. It applies to any xfce4-settings version starting from dbd76eb58bd9d7a55de753daa5572ef24867d924 (contained in 4.11.1), up to the current origin/master. Can anybody confirm this patch fixing the issue while not introducing undesirable side effects? As I understand, it is indeed a suitable solution (cf. the implementation in 641c6c4d7dda4ac41f811c8c0f9e26738f12a732 which used a corresponding approach) but it might conceal another underlying problem: g_ptr_array_unref(GPtrArray*) is expected to have the same effect as g_ptr_array_free(GPtrArray*, TRUE) in case there is exactly one reference to the given argument. However, in the case at hand, the effects differ, which leads to the conclusion that there is more that just one reference left to the given argument, prior to calling g_ptr_array_unref. This could indicate some bug/leak -- but as I understand, calling g_ptr_array_free with free_seg=TRUE deals with that (somebody correct me if I'm wrong).
I just tested the HDMI power cycling patch. I am able to unplug and replug the VGA connector on my motherboard and still detect it.
I've tested the patch, and noticed that without the patch xfsettingsd sometimes crashes when an external display (in this case, a TV) is unplugged. Without the patch, xfsettingsd no longer crashes.
(In reply to Sean Davis from comment #5) > I've tested the patch, and noticed that without the patch xfsettingsd > sometimes crashes when an external display (in this case, a TV) is > unplugged. Without the patch, xfsettingsd no longer crashes. Now you got me confused, "without the patch" in both cases? Just to be sure, which is it?
Created attachment 5723 HDMI and Screen On Event Patch I think I figured out the failure in the logic. You are right, since we are clearing the caches in that particular function, it makes sense to make sure they are truly freed. The above fix uncovered another issue with the order of events when the "Configure new displays when connected" feature is enabled. I found that we are clearing our caches in the middle of the screen event (thats the leftover reference you found). I reordered the code for that function, and now I think I should have a fully functional patch. Please try the attached patch and let me know if the issue is still resolved for you.
posted this on the ubuntu launchpad. tried the patch by Alexander. It works. trying the patch by Sean now (reverted the previous patch). so far so good. using the xfce4-settings-4.11.2 code base b.t.w. my setup is a ubuntu trusty machine using latest nVidia drivers (337.25-0ubuntu1~xedgers14.04.2) connected via HDMI to an Onkyo receiver which is then connected to an Epson projector. I used to lose the signal when I turned off the receiver. but so far so good with both patches
I'm afraid but Sean's patch, "fix_for_bug11107.patch", does not fix the issue for me. I tried with both git-master (d532c0f06d4a629aebf11e8bead63617931001d2) and tag 4.11.2 (e329018189663837f2cd9c50807e4376a852cc88). My patch in turn still works with both said commits. However, since my patch only addresses the issue's symptoms but not its actual cause, Sean's patch should be further improved instead of just using mine. It's interesting to see that "fix_for_bug11107.patch" already fixes the problem for Raj, which makes me think that there's more to this issue than we understand thus far. Btw, I tried both enabling and disabling the "Configure new displays when connected" feature but that did not have any effect. I'm out of ideas right now. My configuration: Xubuntu 14.04 x64 Kernel 3.13.0-39-generic Intel Core i5-4590S Intel driver 2.99.911-0intel1 Monitor attached with a HDMI-to-HDMI cable
Odd, I tested Sean's patch with 14.10 with Nvidia drivers and it rid me of the spawning of countless minimal dialogs. That said, I've never really been able to reproduce the original bugreport, I was mainly regression-testing.
This is strange. The new patch did not work for me. Left everything off for a day, came back and turned it off and the signal was gone. I had to use my hack /usr/bin/xrandr -s 1 /usr/bin/xrandr -s 0 to get the signal back. no such issues last week with Alexander's 1 liner. I noticed that the longer patch has that 1 liner as well and then some. wierd! Raj
have been running Alexander's patch for about one week now and it has solved the issue for me. I no longer have to reset the display even after switching off the receiver and the projector for multiple hours. Raj
Happy to report Alexander's patch worked for me as well. Ubuntu 14 Kernel 3.13.0-24-generic x86_64 Radeon HD 5450 (open 'radeon' driver) Connected via HDMI to an A/V receiver (connected to TV) Power-cycling the receiver caused the issue before the patch
I've had this same problem which led me here, though I'm using a distro and wasn't sure how to patch it. Someone for the distro used the first patch and uploaded a new build. It solved my problem. I'm using Manjaro .8.11 with kernel 3.18 on an Asus Chromebox M400 Here's a link to the forum post. https://forum.manjaro.org/index.php?topic=19411.0 Thanks for the patch
Hello, Apologies if this is not the correct procedure, I'm new to Linux. I have a PC with Linux Lite 2.2(Ubuntu 14.04/xfce based) If I swap the HDMI output to another PC, and then switch back to Linux Lite I have a black/blank screen, I think it is the issue described here. How can I apply the fixes/patches noted at the top.?? Many Thanks... Dave
I suspect that I'm seeing the same issue as the original poster. Running xfce4-settings 4.11.3, without any of the published patches. When unplugging the HDMI cable I very often get an 'xfsettingsd' crash. This results in Xfce reverting to some fallback, default (and ugly) theme, as well as the font size changes. When it crashes, I get this message in the console: liv@liv-inspiron:~$ The program 'xfsettingsd' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRRCrtc (invalid Crtc parameter)'. (Details: serial 1191 error_code 148 request_code 140 minor_code 21) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) l A quick and dirty, but useful solution is to then run 'xfsettingsd' from a terminal. This reverts from the ugly theme to the usual desktop appearance settings. In any case, I've just upgraded from 4.11.2 to 4.11.3, and this bug has suddenly become all the more visible...
Liviu, this is an issue I had found while investigating this issue.. Can you test if the patch I posted in comment 7 https://bugzilla.xfce.org/show_bug.cgi?id=11107#c7 fixes the issue for you?
Hi! Unfortunately this doesn't seem to help in my case. I've installed a patched 4.11.3 (from my PPA here: https://launchpad.net/~landronimirc/+archive/ubuntu/collection , includes fix_for_bug11107.patch), then logged out, logged in. Then: - connect HDMI cable for external display - in simple dialog select Display #2 (right-most choice) - then select Display #1 (left-most choice) - then unplug HDMI cable More often than not this is sufficient to trigger the xfsettingsd crash.
@Dave For Ubuntu 14.04, this is how your you can build xfsettings with the patches: sudo apt-get install xfce4-dev-tools libexo-1-dev libgarcon-1-0-dev libxfce4ui-1-dev git clone git://git.xfce.org/xfce/xfce4-settings cd xfce4-settings curl https://bugzilla.xfce.org/attachment.cgi?id=5681 > alexander-patch.diff curl https://bugzilla.xfce.org/attachment.cgi?id=5723 > sean-patch.diff Choose a patch to Apply: patch -p1 < <patch> ./autogen.sh && make && sudo make install /usr/local/bin/xfsettings --replace If you wanna to try other patch, first remove what's applied: patch -R -p1 < <applied patch> After playing, remember to remove the installed xfsettings: sudo make uninstall
@André I've tried your instructions, but now Sean's patch no longer applies cleanly to master: sh>patch -p1 < "sean_fix_for_bug11107.patch" (3834) patching file xfsettingsd/displays.c Hunk #2 FAILED at 407. 1 out of 6 hunks FAILED -- saving rejects to file xfsettingsd/displays.c.rej sh>patch -p1 < "sean_fix_for_bug11107.patch" (3834) returned '1' >cat "displays.c.rej" (3854) --- xfsettingsd/displays.c +++ xfsettingsd/displays.c @@ -407,7 +407,7 @@ gpointer data) { XfceDisplaysHelper *helper = XFCE_DISPLAYS_HELPER (data); - GPtrArray *old_outputs; + GPtrArray *new_outputs; XfceRRCrtc *crtc; XfceRROutput *output, *o; XEvent *e = xevent; >cat "displays.c.rej" (3854) returned '0'
My fault, I wrote this little guide at work and due an annoying proxy I couldn't git clone... so I downloaded the latest release from: http://git.xfce.org/xfce/xfce4-settings/snapshot/xfce4-settings-4.11.3.tar.bz2 IDK, maybe the following commit has broken the patch: http://git.xfce.org/xfce/xfce4-settings/commit/xfsettingsd/displays.c?id=404d982f2936a58649423642956be563982b2ffa It's seems to be fairly simple to update the patch, but I'm bit in a hurry, if none does that, as soon as possible I'll upload a new patch.
I tested Alexander's patch, and although I'm not yet sure if it helps with the xfsettingsd crash, the approach is buggy. First I notice that 'Mirror displays' option is now disabled, and each time I switch from one option to the other, 4 instances of the display window are being opened. Overall, not the way to go. @André It would be great if you could post an updated version of Sean's patch!
Created attachment 5908 HDMI and Screen On Event Patch(Updated) @Liviu Here you are =)
Thanks a lot André! And thanks a lot for the instructions; although I know most of them individually, stringing them all together wasn't immediately obvious. I've tested Sean's updated patch and I'm happy to report that it seems indeed to solve the `xfsettingsd` crashes. I will test it for a couple more days to make sure that all is OK, but so far looks very promising! I'll report back if I'm still hitting trouble. (The only nagging issue was that after `make install`---hence having both /usr/bin/xfsettingsd and /usr/local/bin/xfsettingsd---for some reason the "Mirror display" option was greyed out. I suspect it's some issue with having both binaries installed at the same time, but I can't say.)
Hi Liviu, Let us know in a few days if the bug is fixed with the patch, and if no side effects were found, so we can release it in time for 4.12. Thanks.
As far as fixing the issue goes, it's very simple: - if I do `/usr/bin/xfsettingsd --replace` (4.11.3), then I can easily replicate the crash - if I do `/usr/local/bin/xfsettingsd --replace` (GIT master with Sean's updated patch), the I can no longer replicate the crash I think the patch is effective at addressing the issue. As for the disabled `Mirror displays` option, if I remove the stock xfce4-settings and only keep the /usr/local/bin installation, then the issue persists: when I connect the HDMI cable, the `Mirror displays` option is disabled (see attached screenshot). I'm not sure how else to test this...
Created attachment 5916 disabled `Mirror displays` option with Sean's updated patch
@Liviu: Is the "mirror" option available when installing xfce4-settings from git master without Sean's patch?
Surprisingly, not. >git checkout master (22206) Already on 'master' Your branch is up-to-date with 'origin/master'. >git checkout master (22206) returned '0' Then: make distclean && ./autogen.sh && make I also removed 'xfce4-settings' from Synaptic. After `make install`, I run `xfsettingsd --replace`. When I plug the HDMI cable, the `Mirror displays` option is disabled. So this issue already seems to be in GIT master. But more strangely, still, I can NOT reproduce the xfsettingsd crash. It's as if it were already fixed in master. Go figure....
OK: disabled `Mirror displays` option GIT bisect points me to: >git bisect bad (22224) 835671ad8db9bcaed4ec3d53753b7f9a8b4610a7 is the first bad commit commit 835671ad8db9bcaed4ec3d53753b7f9a8b4610a7 Author: Sean Davis <smd.seandavis@gmail.com> Date: Sat Jan 31 11:31:52 2015 -0500 Fix issues found with cppcheck (Thanks Mario) (Bug 10879) :040000 040000 f3782b2eee70c04f7715a6aa10d8a2ab7b5b3d42 4cbdb493675c1f077dfb1da25cc087eae33f8e3d M dialogs :040000 040000 995180b85348189b33ae73a4b3a1bd4f2ba675a6 f5e0a19760ca4a33b5ae0e681da7ee0976f5935e M xfsettingsd >git bisect bad (22224) returned '0' There was some unexpected impact of this clean-up...
As for the xfsettingsd crash, I noticed that with current master I was no longer experiencing the crashes. So I did some GIT bisecting, and it turns out that I can reproduce the crash with: http://git.xfce.org/xfce/xfce4-settings/commit/?id=5a7f55a049147320adb8e2dc8495d6f868c4d6ac But I get no more crashes with: http://git.xfce.org/xfce/xfce4-settings/commit/?id=404d982f2936a58649423642956be563982b2ffa It seems to me that Olivier has inadvertently fixed this issue... Just to confirm, I do NOT get xfsettingsd crashes when using master and my usual test case. As far as my setup is concerned, this issue is fixed. ===== So what remains to be addressed is the disabled `Mirror displays` option introduced in 835671ad8db9bcaed4ec3d53753b7f9a8b4610a7. Should I open a separate ticket on this issue?
Glad to hear it's fixed for you. Looking at the two commits, XfceOutputInfo *output was probably unitialised, causing a NULL check to be ignored and a SEGFAULT. Thanks for this thorough testing and debugging, Liviu. I'll close this issue, please do open another report for your Mirror Display issue, and mark it high -- I've spotted some variable initialisation bugs in that code too.
Does anyone know how one might get this fix into Xubuntu?
Here we go: Bug 11525 BTW, I wonder if this xfsettingsd crash issue was solved by addressing the Coverity scan reports... https://scan.coverity.com/projects/4135
@Jesse If everything goes well, this fix is going to be on Xfce 4.12, the question is if Xubuntu is going to ship it in 15.04. You can also build it by yourself or use a PPA, maybe https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xfce-4.12.
Hi, just wanted to point out that Sean's patch did *not* fix the screen disappearing issue for me but the one liner from Alexander did. Was a different patch apply to the main tree to fix the original reason for this bug report? I'm willing to test the latest version, but I can only do it next week at the earliest. Raj
Raj, Thanks for clarifying. There might have been several sources of crashes in the same report. Could the people who commented on this report test whether Xfce4-Settings git (hence with Olivier's recent fix) + Alexander's patch work well for them? Olivier, André: would you like to take ownership of this bug and push whichever additional patch is required?
I would only suggest to prospective testers to first try out Xfce4-Settings GIT (hence with Olivier's recent fix) with *no patch*. At least here it fixes the issue, and maybe this addresses your concerns, too.
@Steve I guess that Olivier, Alexander or Sean are more suitable to tackle this than me, all I did was to give some instructions and update the patch, so don't expect a patch from me any sooner. I use a 27" display and 19" in extended mode(configured via NVidia Settings) and everything works smoothly, but as soon as possible, I'll give it a go(with and without patches) and see what happens while switching, plugging and unplugging them.
i'll test the latest git version without any additional patches early next week when I get back home. I'll report what I find after a day or two of testing (the bug only manifests when the display has been off for quite some time) Thanks, Raj
so the original bug of the display resetting to NULL has *not* been fixed in the latest git version. I left it for a day, came back and the display was blank when I turned on the projector. I have applied Alexander's 1 line patch and I'm testing that now. But the git version has *not* fixed the problem. Someone else has reported the same issue with the git version in the ubuntu version of this bug report btw https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-331/+bug/1308105 see the last comment at the bottom can we please include the 1 line patch to the master repo? Thanks, Raj
I would add the one-line patch, but then every monitor event triggers the "new monitor" signal since all previously known monitors are now forgotten. To see this bug in action, enable the setting "Configure new displays when connected", then manipulate the monitors with the settings dialog. Move them, turn them on/off, click apply. You'll quickly find many many display settings popping up. So while this patch fixes this bug for you, it also creates a new bug for everyone. Please continue to explore and provide additional patches. It's difficult to provide a proper fix when the original issue does not affect me or Simon, the other active maintainer of the display settings..
Hi Sean, interesting. I have never tried to configure the monitor as this is my projector display and not my laptop. This is wierd as the bug you mentioned would suck for laptop / PC use where you plug in and configure external displays somewhat regularly but the bug that is the point of this bug report is terrible for anyone using a projector or LCD display that is attached to a media PC and switched off fairly regularly. I guess I'll just continue using my patched version until a suitable "fixes all bugs" version is written. Thanks for the explanation for why the patch has not been included yet b.t.w. It was very informative! Raj
I experienced this on an HDTV client, workaround and details herehttps://bbs.archlinux.org/viewtopic.php?pid=1510206#p1510206
My workaround of attaching another monitor to my desktop acting as a HDTV MythTV client is not 100% effective.
On my system (Linux bono 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) the issue appeared only cca 2 weeks ago. I don't know which package update (Debian Testing) caused it. Everytime the monitor blanks it can't resume. My workaround is to have this code running: while true; do xrandr -d :0 --output HDMI1 --mode 1920x1080; sleep 10; done My display card: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
Looking at Sean's comment of 2015-02-19, it appears that a functional patch is still being sought. I am experiencing the problem of the display not coming back when it is reconnected. I'm posting this in hopes that it assists the maintainers of the code in resolving the issue. With the 4.12 branch from git, I was able to reproduce this bug with just a regular desktop (non HDMI) by disconnecting and reconnecting the monitor. When the monitor was reconnected, the screen does not resume. In the xfce_displays_helper_screen_on_event function in the top section it has the condition of the disconnection of the monitor. In that section it is calling a forced disable of the crtc via crtc->mode = None; xfce_displays_helper_disable_crtc (helper, crtc->id); However, in the else condition below where it is adding in new outputs, the crtc is still in a disabled status when this gets executed after the cable has been reattached. (mode = None, width=0, etc) I think that the proper solution is to get the crtc re-enabled/refreshed upon reconnection and I'm hoping that those that actually know this code would know how to do this (I tried a couple of options across various functions but they did not work). The interim "hack" solution that seems to work for me is to comment out the code that is disabling the crtc. This doesn't seem to spawn additional displays but may other regression problems. And since it is a true hack rather than a correct solution, I'm not attaching it as a patch. Hope this helps, let me know if testing is needed or if you can point me to the proper method of getting the crtc information refreshed.
Created attachment 6473 Patch to call xrandr --auto when a new display is connected
I still get this in xfce4-settings.4.12.0-3 when I shut off the monitor via its power button, or switch to another pc via a K-V-M switch. I'm unable to resume the display when switching back to my Linux pc or turning the power back on. I have to run 4.10.1-1. For a while I used the 4.11.3-3 fix from Manjaro but that doesn't work now either since last -Syu. I'm running Archlinux 4.3.0-1-ck on an Asus M5A88-M mobo, with on-board Radeon 4250 graphics using the HDMI port. The HDMI is directly connected to an Asus VS247 lcd monitor. The K-V-M only switches the keyboard and mouse from the Linux pc, the other pc's it also switches the VGA as they are connected to the monitor VGA (the monitor default is HDMI so I manually switch the monitor by its selector button to VGA for the VGA pc's). I have to remote into the Linux pc and do a normal reboot in order to get the display to turn on else use the power button on front of the Linux pc :(. Not sure where to look to troubleshoot. Thank you for your consideration.
seeing this in 16.04 daily xubuntu didn't get anywhere with the script in the LP bug report, nor trying to use that AND a udev rule (from xfce forum) I am though getting success here using the one-liner (though sleeping for 3 here instead of 10) in comment #48
As suggested in comment 49 I think proper solution is enable crtc upon reconnection IF it is disabled. Here is a prototype for patch - I'm hoping maintainer (Sean?) can suggest "correct code" to enable crtc. diff --git a/xfsettingsd/displays.c b/xfsettingsd/displays.c index 095e323..af70256 100644 --- a/xfsettingsd/displays.c +++ b/xfsettingsd/displays.c @@ -415,6 +415,7 @@ xfce_displays_helper_screen_on_event (GdkXEvent *xevent, XfceRROutput *output, *o; XEvent *e = xevent; gint event_num; + gint j; guint n, m, nactive = 0; gboolean found = FALSE, changed = FALSE; @@ -496,9 +497,37 @@ xfce_displays_helper_screen_on_event (GdkXEvent *xevent, { xfsettings_dbg (XFSD_DEBUG_DISPLAYS, "New output connected: %s", output->info->name); + /* need to enable crtc for output ? */ + if (output->info->crtc == None) + { + xfsettings_dbg (XFSD_DEBUG_DISPLAYS, "enabling crtc for %s", output->info->name); + crtc = xfce_displays_helper_find_usable_crtc (helper, output); + if (crtc) + { + crtc->mode = output->preferred_mode; + crtc->rotation = RR_Rotate_0; + crtc->x = crtc->y = 0; + /* set width and height */ + for (j = 0; j < helper->resources->nmode; ++j) + { + if (helper->resources->modes[j].id == output->preferred_mode) + { + crtc->width = helper->resources->modes[j].width; + crtc->height = helper->resources->modes[j].height; + break; + } + } + xfce_displays_helper_set_outputs (crtc, output); + crtc->changed = TRUE; + } + } + changed = TRUE; } } + if (changed) + xfce_displays_helper_apply_all (helper); + /* Start the minimal dialog according to the user preferences */ if (changed && xfconf_channel_get_bool (helper->channel, NOTIFY_PROP, FALSE)) xfce_spawn_command_line_on_screen (NULL, "xfce4-display-settings -m", FALSE,
Created attachment 6590 Enable crtc if it is disabled after power cycle Added prototype patch to enable crtc after power cycle of displayport monitor. I hope maintainer can suggest improvements.
The patch in #53 is working for me. Arch Linux 4.3.3.2-ck. Asus Radeon R7-240 video card (using the hdmi port), Asus M5A88-M computer. I can now switch via k-v-m to other pc's, can turn off power to monitor for extended periods and all resumes when power is back on or k-v-m is switched back to the Arch pc (other pc's are vga).
In troubleshooing with ToZ in the forums, it seems as through this bug is related to bug #12480 as well. The patch from comment #53 seems to be allowing my monitor to wake from suspend under the 4.4.x series of kernels. I will preform more tests before calling this solved, but wanted to document this in the ticket.
Probably had 2 dozen or more suspend/wake cycles using the patch from comment #53 under linux v4.4.6 and it xfce4 is behaving as it should waking the monitor. If the patch as-is is grammatically correct, etc. I would recommended applying it to xfce4-settings.
Thanks jkampe68! Attachment 6590 completely fixes the problem for me on Ubuntu and Arch Linux. I've made an AUR package including your patch: https://aur.archlinux.org/packages/xfce4-settings-blank-screen-fix/
Haven't had any problems since installing the patch from #53. I plan to upgrade Arch next weekend but haven't seen a new release of xfce4-settings (4.12.0-3).
I was experiencing the same issue switching my display (through a kvm) between the Debian/Stretch machine running 4.12.0-2 and another machine. jkampe68's patch fixed the problem. Thank you.
I just upgraded Arch (-Syu) with xfce4-settings ignored in pacman.conf, then upgraded xfce4-settings from the aur using James' [url]https://aur.archlinux.org/packages/xfce4-settings-blank-screen-fix/[/url] and all is well (tested KVM switch, tested turn off monitor), thanks James!
Wow... thank heavens. I can also very that the patch from Comment #53 has solved this bug that has been driving me nuts for weeks. I would lose my entire X session every single day as soon as the screen blanked... quite troublesome when you're trying to make linux work as your daily drive, haha. I had to learn how to patch a .deb file properly in the process, but that was worth it too. Cannot thank you enough, @jkampe68 -- Hardware/Software -- GPU: GTX 970 over DisplayPort 1.2 Monitor: Dell P2715 (4K@60Hz, hardware rev A03) OS: Xubuntu Xenial (16.04 LTS) Manually patched xfce4-settings version: 4.12.0-2ubuntu1 Useful links on patching .deb's: https://help.ubuntu.com/community/UpdatingADeb http://www.cyberciti.biz/faq/appy-patch-file-using-patch-command/
I've had good luck with the patch (thank you!) but still see one problem. After my dual monitors turn back on, they are now in mirrored mode instead of side-by-side as they were before they went to sleep. Running `xfsettingsd --replace` after this restores the screens to their proper setup.
Running sparky linux with xfce. dual screen in expand mode after wake up works until kernel 4.3. after that it wakes up mirrored. see this thread: https://forum.xfce.org/viewtopic.php?id=10951 hope this helps to find the cause.
On Linux Mint 18 xfce, I too got bitten by this bug. After power off / power on, the monitor reports 'no signal'. Intel Integrated Q45/Q43 Graphics (Dell Optiplex 780 USFF) DisplayPort <--> DVI-D cable Acer V243HL LCD Monitor (1920x1080 @60Hz) I applied 'Enable crtc if it is disabled after power cycle' patch as provided in comment #53 by jkampe68 to the source package of xfce4-settings (4.12.0-2ubuntu1) This fixed the issue. Thank you jkampe68. I sincerely hope this patch or an adaptation that fixes the problem accordingly will find its way into the xfce4-repository. Thanks in advance! Luuk
xfce4-settings-4.12.0-5 has the patch applied in the (Arch Linux) package: https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/xfce4-settings
I'm really impressed, thanks to the persistence with trying to find a solution to this bug. As several of you have mentioned, the patch in #53 / #54 (courtesy of jkampe68) seems to resolve the issue. I have tested this patch myself, and while not being able to reproduce the original issue, I have verified that there do not seem to be any regressions with this patch. I have committed this change here: https://git.xfce.org/xfce/xfce4-settings/commit/?id=2233f20a7ec6d7cb7dcc5752d62d98e37d9c21ad I'm planning to do a new release including this patch shortly. HUGE shout out to everyone that helped figure this one out!
I see one issue in the patch; When enabling the crtc it _unconditionally_ sets the output crtc (preferred) mode, rotation etc. properties. In multimonitor setups this likely leads screens to appear mirrored after power cycle (see comment #63 and #64) The patch should be improved by reading/restoring the crtc output properties from saved xfconfig. I simply was not up to the task to write that code, maybe someone can contribute?
Similarly I keep losing my configured resolution of 1280x720, with the system defaulting back to 1920x1080 every time (which looks rubbish on my crappy monitor). Manually running "xfsettingsd --replace" is a workaround, but not ideal. All progress though, it's still much better than rebooting every time. Thanks a ton for getting us this far.
*** Bug 12786 has been marked as a duplicate of this bug. ***
I've opened a downstream Fedora bug at https://bugzilla.redhat.com/show_bug.cgi?id=1375171 with a bit more information that might be useful.
(In reply to jkampe68 from comment #68) > I see one issue in the patch; > > When enabling the crtc it _unconditionally_ sets the output crtc (preferred) > mode, rotation etc. properties. > In multimonitor setups this likely leads screens to appear mirrored after > power cycle (see comment #63 and #64) > > The patch should be improved by reading/restoring the crtc output properties > from saved xfconfig. I simply was not up to the task to write that code, > maybe someone can contribute? I suggest that we close this issue and create a new for the mirrored-after-power-cycle.
Hi - sorry to comment on an old closed bug, but has anyone ever reported the remaining problem (monitors mirrored after wake) as Natanael Copa suggested in #72? I searched but could not find anything.
Not here, I'm unfamiliar with the mirrored monitors issue other than mentioned in the bug report.
Please create a new issue if needed but refrain from posting questions like that here. This is not a mailing list.