Xfce resets TV mode to NULL when power cycled

Bug #1308105 reported by Mario Limonciello on 2014-04-15
362
This bug affects 59 people
Affects Status Importance Assigned to Milestone
Mythbuntu
Medium
Unassigned
xfce4-settings
Confirmed
Critical
nvidia-graphics-drivers (Ubuntu)
Undecided
Unassigned
nvidia-graphics-drivers-331 (Ubuntu)
Undecided
Unassigned
xfce4-settings (Ubuntu)
Undecided
Unassigned

Bug Description

I had an HTPC with Mythbuntu 12.04 installed. Upon upgrading a new behavior that if the TV is power cycled it no longer detects a link with the HTPC.

When this happens I can find in the xorg log that there is an accompanying log item:

[ 39829.509] (II) NVIDIA(0): Setting mode "NULL"

After debugging with NVIDIA at https://devtalk.nvidia.com/default/topic/729955/linux/tv-stops-being-detected/ we've deteremined it's a X client that reacts to the RANDR events causing the mode to be set to NULL.

Working through the list in an Xfce environment, the culprit is xfsettingsd. If xfsettingsd is running, it causes the TV to come up in a NULL mode. If it's killed, it remains in the mode it was previously running in.

Until this is fixed, this behavior can be worked around with a simple shell script:
==============================
#!/bin/sh
#Fix TV state when HDMI link is lost.
#By Mario Limonciello <email address hidden>

OUTPUT="HDMI-0"
BAD_MODE="1280x720"
GOOD_MODE="1920x1080"

for MODE in $BAD_MODE $GOOD_MODE; do
 DISPLAY=:0 xrandr --output $OUTPUT --mode $MODE
 sleep 2
done
==============================

Mario Limonciello (superm1) wrote :

For people on mythbuntu who encounter this with a mceusb remote, here's how i'm working around it:

1) Save this file to /home/user/fix_tv_state.sh and make it executable
==============================
#!/bin/sh
#Fix TV state when HDMI link is lost.
#By Mario Limonciello <email address hidden>

OUTPUT="HDMI-0"
BAD_MODE="1280x720"
GOOD_MODE="1920x1080"

for MODE in $BAD_MODE $GOOD_MODE; do
 DISPLAY=:0 xrandr --output $OUTPUT --mode $MODE
 sleep 2
done
==============================

2) Create ~/.lirc/irexec and put these contents:
==============================
begin
     remote = mceusb
     button = KEY_POWER
     prog = irexec
     repeat = 0
     config = /home/user/fix_tv_state.sh
end
==============================

3) Add to ~/.lircrc this line:
include ~/.lirc/irexec

4) Restart machine, lightdm or log out/in

Now power button on your mceusb remote will fix the HTPC video output state.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nvidia-graphics-drivers (Ubuntu):
status: New → Confirmed
Changed in nvidia-graphics-drivers-331 (Ubuntu):
status: New → Confirmed
Mario Limonciello (superm1) wrote :

After some more sleuth work with NVIDIA, we've discovered that this is happening because of a RANDR event. An X client is responding to the RANDR events and forcing it to this NULL resolution.

I checked what clients were running, and it's xfsettingsd causing this problem. If I kill xfsettingsd prior to turning on/off my TV it comes back at the right resolution.

Changed in xfce4-settings (Ubuntu):
status: New → Confirmed
Changed in nvidia-graphics-drivers (Ubuntu):
status: Confirmed → Invalid
Changed in nvidia-graphics-drivers-331 (Ubuntu):
status: Confirmed → Invalid
Changed in mythbuntu:
status: New → Confirmed
importance: Undecided → Medium
summary: - HDMI Handshake fails after TV powered off
+ Xfce resets TV mode to NULL when power cycled
description: updated
Mario Limonciello (superm1) wrote :

Here is the xfsettingsd debug output when the RR events are received. When the TV comes up there is a handful of change events and the end result is that the output gets disabled but not re-enabled.

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

Jack Deslippe (jdeslip) wrote :

I'm seeing a similar issue after upgrading from mythbuntu 12.04 to 14.04. Only I'm using integrated graphics from intel sandybridge.

Stuart Matthews (mtrauts) wrote :

This issue also affects Gigabyte GA-EG45M-UD2H motherboard with Intel GMA X4500HD integrated graphics. Fresh install of mythbuntu 14.04. 13.10 was not affected.

Thomas Goerke (t-tom-w) wrote :

I have the same issue with ASUS P5E-VM HDMI motherboard. Fresh install of 14.04. Previous version (13.??) was not affected.

Trey Boudreau (trey-v) wrote :

Same problem with Intel NUC D54250WYK. I've only ever run 14.04 on it.

Ernst Sjöstrand (ernstp) wrote :

One workaround is to install gnome-settings-daemon and check the box in Xfce session settings to start gnome services on startup.

rhpot1991 (rhpot1991) wrote :

I added the following in /etc/mythtv/session-settings to work around this issue:
killall xfsettingsd

This will kill xfsettingsd when mythfrontend starts.

Gabriel Pannwitz (gabkdlly) wrote :

I think that I was experiencing this problem. I tried the workarounds mentioned above, but none of them really "worked". But I do not seem to be experiencing this issue when I switched to using DVI instead of HDMI. For what is worth, I am running Xubuntu 14.04 on a Dell Studio-XPS.

Weston (westont) wrote :

I am experiencing the same with Mythbuntu 14.04 and an AMD A10 APU. Deactivating the autorunning of xfsettingsd fixed the problem.

Bubu Fearn (bubu-fearn) wrote :

I have the same bug with Xubuntu 14.04 on AMD Radeon 6770 with a Toshiba HDTV

Turn off TV and signal is lost and can't get it back again until I restart the desktop.

Bubu Fearn (bubu-fearn) wrote :

Oops, I got linked to this bug from

http://ubuntuforums.org/showthread.php?t=2220583&page=4

I didn't realise it was registered as an Nvidia bug though.

Clearly its not as my card is an AMD.

AMD owns nVidia these days as one of their brands. You may perhaps be in
the right place.

Nick (soapduk) wrote :

^No AMD owns ATI, the other major graphics card provider.

I am also experiencing this problem on integrated Intel graphics on Xubuntu 14.04 when using HDMI. It's the first distro I have used on this system but I never had the problem on Xubuntu 12.04 on my previous sytem (which was VGA/D-sub).

I do not get 'NULL' in my /var/log/Xorg.0.log but the issue is basically the same problem. I do get null in dmesg however:

[code][ 0.152426] ACPI: SSDT (null) 0004C4 (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 0.153472] ACPI: SSDT (null) 000433 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 0.160066] ACPI: SSDT (null) 00015F (v01 PmRef ApIst 00003000 INTL 20061109)
[ 0.163743] ACPI: SSDT (null) 00008D (v01 PmRef ApCst 00003000 INTL 20061109)[/code]

Straximus (straximus) wrote :

I downgraded xfce-settings to the 4.11.0 package from Saucy, and locked it at that version. It eliminated the issue, and everything appears to function normally.

Nick (soapduk) wrote :

Thanks Straximus, that worked for me too.

Download full text (4.3 KiB)

tl;dr - There is a bug in xfsettingsd that not only affects external monitors, but primary monitors as well.

I believe that I am encountering the same bug, but by a different scenario. This may also be the same bug as #1313539.

I am running Xubuntu 14.04 on two of my four computers. I have all four computers connected to a single keyboard, monitor and mouse via a 4port KVM switch. Prior 14.04 upgrade, this setup worked like a dream. Post 14.04 upgrade, I have found that switching to either of the Xubuntu machines results in a blank monitor. On one machine, I am usually able to get to a virtual console and reset of the video by restarting lightdm. On the other machine, I am not able to even get a virtual console, and I have to ssh into the machine in order to restart lightdm.

The dying video happens so frequently that I starting the process of migrating away to XFCE. I installed Gnome Shell on one machine and Fluxbox on the other. Neither of these WM's exhibited the dying video phenomena.

Based upon this bug report, I decided to investigate the possibility that xfsettingsd might be the problem. Here's what I did.

1) Log in to a Xubuntu session.

2) Open a terminal window. Because I needed to do part of this from the Xubuntu session and part of this via ssh, I opened a new Byobu session (screen or tmux would work too). Then,

    $ killall xfsettingsd
    $ XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon 2>&1 | tee output.txt

3) After the initial output from xfsettingsd had finished,

    $ cp output.txt before.txt

4) Here's where the fun begins: I unplugged the monitor from the KVM switch. I waited a few seconds, and then I plugged the monitor back into the switch. No video. I switched the KVM to one of the other computers and verified that the monitor was corrected plugged in and working.

5) On one of the other computers with working video, I ssh'ed into the machine running the Xubuntu session and reconnected to the Byobu session. I found that xfsettingsd had crashed.

6) Executing "sleep 5; xfsettingsd" on the ssh session and switching to the Xubuntu machine restored the video.

7) I diff'ed the "before.txt" with the "output.txt". Here is the output that was generated when the monitor was unplugged and replugged.

xfce4-settings(displays): RRScreenChangeNotify event received.
xfce4-settings(displays): Refreshing RandR cache.
xfce4-settings(displays): Detected CRTC 63.
xfce4-settings(displays): Detected CRTC 64.
xfce4-settings(displays): Detected CRTC 65.
xfce4-settings(displays): Noutput: before = 1, after = 0.
xfce4-settings(displays): Output disconnected: VGA1
xfce4-settings(displays): Disabling CRTC 63.
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 63.
xfce4-settings(displays): Detected CRTC 64.
xfce4-settings(displays): Detected CRTC 65.
xfce4-settings(displays): Noutput: before = 0, after = 0.
xfce4-settings(displays): RRScreenChangeNotify event received.
xfce4-settings(displays): Refreshing RandR cache.
xfce4-settings(di...

Read more...

Following Straximus's lead (comment #18), I downgraded to the xfce4-settings package from Saucy. I left the machines allow all weekend long, and this morning the video on both machines worked as expected.

There is a regression bug between xfce4-settings 4.11.0-1ubuntu1 (saucy) and 4.11.2-1ubuntu2 (trusty).

nick_s (nickstylianou) wrote :

This also affects me on Mythbuntu 14.04 x86 64bit with the open radeon driver and ATI RS880 [Radeon HD 4250] graphics controller.
The workaround for me was to disable xfsettingsd in the GUI Settings under "Session and Startup":
1) In the "Application Autostart" tab I unticked xfsettingsd.
2) In the "Session" tab I selected xfsettingsd and clicked "Quit Program".

Ahh, this issue has been driving me crazy since I did the 14.04 upgrade.

I'm using ubuntu 14.04 + xfce4 + plex connected to my yamaha receiver and panasonic hdtv (with pulse-eight cec usb dongle). (setup is years old).

The procedure above (#22) did the trick for me. Thanks!

Unfortunately, the workaround in #22 does not work form me. Since my computers are plugged in to a KVM switch, I need xfsettings running in order to reset my mouse and keyboard settings after switching computers.

Workaround #18 works for me.

Has anyone reported this bug upstream?

JeanLuke (james-jasa) wrote :

I am having the same problem. I upgraded frm Mythbuntu 12.04 to 14.04 with the Asus M3N78 motherboard (Nvidia 8200 graphics card & nvidia-304-updates driver).

Using xfce4-settings from Ubuntu 13.10 (as per post #18) fixed it for me. I have not tried using the suggestion from post #10.

There is another fix in this thread that I'll try later this week -> http://ubuntuforums.org/showthread.php?t=2221496

JeanLuke (james-jasa) wrote :

I added the options:
       Option "ConnectedMonitor" "DFP-0"
       Option "UseDisplayDevice" "DFP-0"
to the "devices" section of my /etc/X11/xorg.conf and it seems to have fixed it - even with the current xfce4-settings installed.

Tests I have done:
1/ boot with the television off, turn it on and get display
2/ boot with the television on, power cycle it (off time about 30 minutes) and have display
3/ boot with the television off, switch it on for 5 minutes, off for 30 minutes, back on and have display

As above, I have the Asus M3N78 motherboard (Nvidia 8200 onboard graphics) with nvidia-304-updates driver, using HDMI.

Bengt Nilsson (bnilsson11) wrote :

I have Ubuntustudio amd64 14.04LTS on a HTPC with a TV connected to HDMI-0 on a GA-880GMA-UD2H, Radeon mobo graphics.

Tried to follow #26, but it seems I don't have any xorg.conf in my /etc/X11.
Any advice?

JeanLuke (james-jasa) wrote :

My solution only works for Nvidia graphics cards using Nvidia drivers, sorry. Technically, it's a work-around, not a fix.

For those who do use Nvidia drivers but do not have an xorg.conf file, you can generate one with the "nvidia-xconfig" tool run as root or with sudo. See http://http.download.nvidia.com/XFree86/Linux-x86/1.0-8756/README/chapter-03.html

Patrick Stump (pstump-y) wrote :

I did the fix in #26 and it fixed my issues as well.
The only difference was that in nvidia-settings my samsung tv was coming up as "DFP-1" so I had to change it to :
        Option "ConnectedMonitor" "DFP-1"
       Option "UseDisplayDevice" "DFP-1"

JeanLuke THANK YOU! This has been an huge source of frustration.

As of today this is still not assigned, so not really sure when they will get to fixing it.

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

Changed in xfce4-settings:
importance: Unknown → Medium
status: Unknown → Confirmed

I just bisected the git repository of xfce/xfce4-settings and identified the commit that introduced the issue as:

------------------------------------------

dbd76eb58bd9d7a55de753daa5572ef24867d924

Author: Lionel Le Folgoc <email address hidden> 2012-11-08 20:15:42
Committer: Simon Steinbeiss <email address hidden> 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 <email address hidden>

------------------------------------------

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 using the Yocto project to build a linux image containing xfce. I have been having the same problem with a failure to detect when disconnecting and reconnecting an LCD monitor.

I reverted commit dbd76eb58bd9d7a55de753daa5572ef24867d924, and I can confirm that I can now disconnect the monitor at will with detection.

I'll have to use this workaround for now.

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?

In , Raj B (bigwoof) wrote :

I tested this patch and it seems to have fixed the problem for me.

I have Linux machine running Ubuntu Trusty with the latest nVidia drivers (337.25-0ubuntu1~xedgers14.04.2). I used XFCE as my window manager for a mythtv/xbmc setup.

patching xfsettingsd has solved the loss of display issue for me.

My machine is connected to an Onkyo receiver which is then connected to an Epson projector.

Bengt Nilsson (bnilsson11) wrote :

I would like to try "this patch".
Please supply a link to where I can find it, and some detailed instructions on how to apply it. I am not a programmer.

Regards,

B. Nilsson

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

Chris (christopherdbennett) wrote :

Alexander's patch also works nicely for me! So awesome to have a font I can read again and not to have to mess with Linux every time I turn off the receiver or switch it to a different input. Nice work!

Hey can you please send me some install information so that I can try it
out.

Cheers

Doug
On Nov 23, 2014 3:40 PM, "Chris" <email address hidden> wrote:

> Alexander's patch also works nicely for me! So awesome to have a font I
> can read again and not to have to mess with Linux every time I turn off
> the receiver or switch it to a different input. Nice work!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1308105
>
> Title:
> Xfce resets TV mode to NULL when power cycled
>
> Status in Mythbuntu, Ubuntu derivative focused upon MythTV:
> Confirmed
> Status in xfce4-settings:
> Confirmed
> Status in “nvidia-graphics-drivers” package in Ubuntu:
> Invalid
> Status in “nvidia-graphics-drivers-331” package in Ubuntu:
> Invalid
> Status in “xfce4-settings” package in Ubuntu:
> Confirmed
>
> Bug description:
> I had an HTPC with Mythbuntu 12.04 installed. Upon upgrading a new
> behavior that if the TV is power cycled it no longer detects a link
> with the HTPC.
>
> When this happens I can find in the xorg log that there is an
> accompanying log item:
>
> [ 39829.509] (II) NVIDIA(0): Setting mode "NULL"
>
> After debugging with NVIDIA at
> https://devtalk.nvidia.com/default/topic/729955/linux/tv-stops-being-
> detected/ we've deteremined it's a X client that reacts to the RANDR
> events causing the mode to be set to NULL.
>
> Working through the list in an Xfce environment, the culprit is
> xfsettingsd. If xfsettingsd is running, it causes the TV to come up
> in a NULL mode. If it's killed, it remains in the mode it was
> previously running in.
>
>
> Until this is fixed, this behavior can be worked around with a simple
> shell script:
> ==============================
> #!/bin/sh
> #Fix TV state when HDMI link is lost.
> #By Mario Limonciello <email address hidden>
>
> OUTPUT="HDMI-0"
> BAD_MODE="1280x720"
> GOOD_MODE="1920x1080"
>
> for MODE in $BAD_MODE $GOOD_MODE; do
> DISPLAY=:0 xrandr --output $OUTPUT --mode $MODE
> sleep 2
> done
> ==============================
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mythbuntu/+bug/1308105/+subscriptions
>

I'm running mythbuntu and upgraded to 14.04. When I switched video inputs on my receiver the screen would die and I would have to manually run xrandr to force the display to start again. But after following the steps in post #22 the issue was resolved. Thanks Nick I would have never found that setting.

Derek (glubbish) wrote :

Hi,
I was wondering if someone could help me out on this.
I would like to apply the patch, but have very little ubuntu knowledge.
I am running ubuntu 14.04 and have found I get this problem.

The workaround in #22 works for me, but makes the fonts hard to read. This is why I would like to use Alexander's patch.

However, I am not sure how to do it.

I checked my system for xfsettingsd and displays.c but could not find either
sudo . -name displays.c -print
returns nothing (run from the root dir)

I assume that if I can find displays.c all I need to do is go to that directory and do:
patch < {patchname}

Any/All help appreciated.

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

Thomas Mashos (tgm4883) on 2015-01-12
tags: added: downstream
In , Dave (xwebsubs) wrote :

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...

John R (h-ubuntu-3) wrote :

Hey guys - a little help for a relative Ubuntu n00b?

I'm *not* running Mythbuntu - I'm running standard Ubuntu Desktop 14.04. I don't have xfce4-settings installed, but I am seeing very similar behaviour to that described in this bug report. I have a DisplayPort monitor attached. If I switch it off and switch it on again (or switch it to a different input and back again), Ubuntu doesn't detect the monitor and it says black. I have to reboot the box to get the display back. (There may be a way of getting it back using ssh but I haven't been able to do that yet).

If I change the monitor cable from DisplayPort to DVI this does not happen. I'm using a GTX660 with an HP LP2475w.

My behaviour looks like the same bug, but changing xfce4-settings won't help as I don't have it installed!

Can anyone verify this behaviour, and if verified, add the appropriate data in the "Affects" field? Thanks.

Arjen (acm-tweakers) wrote :

What works for me to get some output on my blank screen is to execute 'xrandr --auto' via ssh.

That only works when X was started in the first place, which may not be the case if you had booted without the screen on or something like that.

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?

Changed in xfce4-settings:
status: Confirmed → Incomplete

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 =)

Bengt Nilsson (bnilsson11) wrote :

Could someone involved in this discussion PLEASE describe how to implement this patch.

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

Changed in xfce4-settings:
status: Incomplete → In Progress

@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 <email address hidden>
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

Changed in xfce4-settings:
status: In Progress → Fix Released

@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?

Changed in xfce4-settings:
importance: Medium → Critical
status: Fix Released → Confirmed

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.

Alexander Schmidt (voidcastr) wrote :

With the current git-master (xfce4-settings 8adbd2e2463f5cc46c7ed94c0acf264155476268) and NO patches the issue does not occur for me. That is, neither when powering my HDMI-connected screen off and on again nor when physically disconnecting and reconnecting it.

However, I cannot even reproduce the original issue anymore. Weird!

My current configuration:
Xubuntu 14.04 x64
Kernel 3.13.0-45-generic
Intel Core i5-4590S
Intel driver 2.99.911-0intel1
Monitor attached with a HDMI-to-HDMI cable

Things that indeed changed:
- new, different mainboard (the old one died some weeks ago due to a power supply voltage peak)
- new but identical CPU (died due to the same reason)
- upgraded packages from the official Xubuntu 14.04 sources (got no related PPAs or such, so it's just regular updates)
- new kernel version (probably does not matter)

Btw, my machine is not a laptop, so I'm down to 0 outputs when physically disconnecting my screen (I kind of remember this being relevant in the source code).

fkervin (fleckskervin) wrote :
Download full text (3.5 KiB)

Hi Everyone,

I'm glad to have found this thread (Many thanks to ToZ in forum.xfce.org): https://forum.xfce.org/viewtopic.php?id=9391

My problem is I read so many possible solutions that I really don't know what to do. I have an intel onboard graphics card and if I turn off TV i have blank screen when later I switch it on again (Xubuntu 14.04)

What is the procedure you reccomend me to do? From last posts here it seems to be a fixed releaded, how do I install?

I've make a recopilation of all the possible solutions I've read here:

****FIRST - Use this script when problem happends:
==============================
#!/bin/sh
#Fix TV state when HDMI link is lost.
#By Mario Limonciello <email address hidden>

OUTPUT="HDMI-0"
BAD_MODE="1280x720"
GOOD_MODE="1920x1080"

for MODE in $BAD_MODE $GOOD_MODE; do
 DISPLAY=:0 xrandr --output $OUTPUT --mode $MODE
 sleep 2
done
==============================

My question is: How can I run the script when HDMI link is lost if I've no video signal?

****SECOND - install gnome-settings-daemon and launch on system boot.
It seems too easy to be true, hehe, Do i try?

****THIRD - killall xfsettingsd
In my case I can leave computer on with desktop on screen, so I can't do this on any program boot. Whose are the consequences of killing this application on system boot?
I've read it can causes an undesired problem, fonts are unreadable (could cause some problem with image quality)

****FOUR - Using DVI cable instead of HDMI
I could use a DVI to HDMI cable, at last I can get sound from it, althought I'd prefer maintaining the DVI connection.

****FIVE - downgrade xfce-settings to the 4.11.0 package from Saucy, and locked it at that version (4.11.3 causes the problem).
How can I do this?

****SEVEN - Create xorg.conf and add those lines:
Option "ConnectedMonitor" "DFP1"
Option "UseDisplayDevice" "DFP1"

OR
       Option "ConnectedMonitor" "DFP-0"
       Option "UseDisplayDevice" "DFP-0"

to the "devices" section of /etc/X11/xorg.conf.

Only for nVidia cards

****EIGHT - Install a patched 4.11.3 (from my PPA here: https://launchpad.net/~landronimirc/+archive/ubuntu/collection , includes fix_for_bug11107.patch).
The person who told this seems to not have solved with this procedure. How can I do this? I mean, How can I Install this patched version.

****NINE - Sean's patch, "fix_for_bug11107.patch"
I don't know where to download it from or how to install, it seems to be explained in next option (TEN)

****TEN - Alexander's patch, also Sean's, explained here:
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 uninsta...

Read more...

@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

fkervin (fleckskervin) wrote :
Download full text (6.3 KiB)

 I've spent a good amount of hours researching and making tests, unfortunately I can't make it work and I'm really desperate, so I'd really thank any help.

I hope someone can lend me a hand (mainly on the procedures of patches of alexander and sean, I can't make them work).
----

The script of first solution works (in my case replacing HDMI-0 with HDMI1), I create it in ~/fixhdmi.sh and chmod 755 it.

The question here is automating the process, and in this I've not been able to, It only works running script manually from terminal (I've no try to make a shortcut, it's not valid for my needs) :(

I even added a wait time before the process (since the TV takes some time in beign ready I thought it could help) and a message after with zenity:

[code]#!/bin/sh
#Fix TV state when HDMI link is lost.
#By Mario Limonciello <email address hidden>
sleep 10
OUTPUT="HDMI1"
BAD_MODE="1280x720"
GOOD_MODE="1920x1080"

for MODE in $BAD_MODE $GOOD_MODE; do
 DISPLAY=:0 xrandr --output $OUTPUT --mode $MODE
 sleep 2
done
zenity --info --title="HDMI" --text="fixhdmi.sh has been executed"
[/code]

I've found a few entries explaining the procedure of udev, so I've create a the file /etc/udev/rules.d/hdmi.rules with this content

[code]KERNEL=="card0", SUBSYSTEM=="drm", ACTION=="change", RUN+="/home/fkervin/fixhdmi.sh[/code]

I also tryed:
[code]SUBSYSTEM=="drm", ACTION=="change", RUN+="/home/fkervin/fixhdmi.sh[/code]

I tried another ones I don't remember...

The result without the udev entry is "no signal message", with it I have cursor on screen over black for a seconds but then dissapear and "no signal" message again. It makes me think that

the udev could be working on TV disconnect but not on connect (only an idea). Later when I tried the alexander's mod I had the same effect, (cursor and blank screen), I don't how it there is any relation.

I've try udevadm in a power-off/power-on of the TV, having this result:

[code]
fkervin@fkervin:~$ sudo udevadm monitor
[sudo] password for fkervin:
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[121.525065] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV [135.590008] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
KERNEL[142.156140] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV [156.226634] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
[/code]

I can't figure out how to make udev rule work :(

-----

I've try to install Xfce 4.12 packages:

[code]
sudo add-apt-repository ppa:xubuntu-dev/xfce-4.12
sudo apt-get update
sudo apt-get upgrade
[/code]

It unfortunately doesn't solve the problem.

------

killing xfsettingsd makes it work, but since it interfere on the icons, text and many elements, it's not appropiate.

------

In the option of installing an older xfce4-settings:

by adding the saucy mirrors to you sources.list, and running apt-get update && apt-get install xfce4-settings/saucy or apt-get -t saucy install xfce4-settings

I don't know what should I add to sources.list.

------

Alexander and sean's procedures:
I've try several times with no results, for example:

...

Read more...

Glen Dragon (gdragon) wrote :

For those trying the above commands... the curl to get the patch files is likely not working.
I'm not motivated enough on curl to figure out the problem, but i was able to copy/paste with a browser.
If you are unsure, look at the patch files, git diff, the output of patch, etc...

For me the latest git did not fix the problem.
Sean's (updated) patch also did not fix the problem.
Alexander's patch *did* fix my problem.

My use case is with a single display attached to a A/V receiver. Turning the receiver off, and back on did not come pack.
Using alexander's one liner, it works great.

IMHO, this is a big issue, and i'm shocked that it's not been rectified yet.

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

fkervin (fleckskervin) wrote :

Hi all,

Some days ago appeared xfce 4.12, I've made an sudo apt-get update and upgrade but problem is not solved.

Have I done something wrong or the problem is still not solved?

Regards

Sean Davis (bluesabre) wrote :

@fkervin The bug status is still not marked as fixed. There has not been a valid fix that doesn't cause a regression.

I have been having this issue on my 14.04 install for a while now (probably as long as Mario), i have been using my rPi and a button to run a command over ssh to fix it
DISPLAY=":0.0" xrandr --output HDMI-0 --auto

i upgraded me and my dad to xfce 4.12 and now he has the issue ga-a55m-ds2 motherboard and a AMD A6-3500 APU
he is running xubuntu 14.04 w/ linux 3.16.7 w/ xfce 4.12 (open source drivers, NOT fglrx/catalyst)
he is using DVI on a HP 2009M monitor
this command restores the display for him
DISPLAY=":0.0" xrandr --output DVI-0 --auto
he seems to have this issue wen the power manager turns the display off and the monitor goes into standby

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.

Adam Kaminski (thimslugga) wrote :

I am currently experiencing this issue with a foxconn d180s j1800 motherboard and Xubuntu 15.04. After turning off the TV and receiver I do not receive any video when turning them back on. Running the script fixhdmi.sh posted above or 'xrandr -d :0 --auto' seems to fix the issue. I just need to figure out how to trigger when TV turns back on.

Arjen (acm-tweakers) wrote :

You could probably just use 'xrandr --auto', at least that worked for me.

I have actually now a different 'fix', by simply never having the system notice the hdmi-link goes down. I used this wiki-page to fix that for my Intel Haswell-cpu graphics.

https://wiki.archlinux.org/index.php/Kernel_mode_setting

My final cmdline is now this:
video=HDMI-A-1:1920x1080@60e dmr_kms_helper.edid_firmware=HDMI-A-1:edid/tv-edid-data.edid

The tv-edid-data file is located in /usr/lib/firmware/edid/ and was derived via 'get-edid'. It actually also seemed to work with the built-in '1920x1080.edid' (saves you retrieving it from your receiver, but I thought it a bit more save to have the actual edid).
Just supplying the video-parameter wasn't enough in my case, it failed to actually set the resolution to 1920x1080 (and used 1024x768 instead). Adding the edid-data fixed that (it may even be sufficient to only force-load the edid data).

The reason this works is not because it fixes the issue, but because it prevents the hdmi-link from ever going down - as far as the kernel is concerned.

Ernst Sjöstrand (ernstp) wrote :

My best solutions to the MythBuntu/XBMC/Kodi usecase:

1) Run a MythBuntu/XBMC/Kodi-session without any desktop at all! They're in /usr/share/xsessions/
for running completely standalone.

2) Running a really minimal WM that doesn't try to manage screens at all like Openbox. Works
well with Steam big picture mode.

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.

Erik Hovland (erik-m) wrote :

Adding my me too. I have a ECS Liva X with an intel graphics chip. When I turn off my Samsung TV the screen goes away. I added the suggestion above (killall xsettingsd) to the /etc/mythtv/session-settings and was able to confirm that it does workaround the problem.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.