Comment 3 for bug 1155838

First of all, you can get rid of your xorg.conf, or simplify it down to just the DontZap option. All of that should be irrelevant to this problem, but may as well exclude it.

Next, your MonitorsUser.xml looks a bit odd; the last config (which I assume is the one gnome is using for your HW since it's the only one with HDMI1) is missing configuration details on LVDS1. So, I'd try removing monitors.xml and reconfiguring in gnome. See if it generates the same (I guess invalid?) config.

The thing to do here is to study xrandr --verbose output before and after the hotplug event. The attached xrandr data I guess is from with the HDMI1 connected:

HDMI1 connected 1680x1050+0+0 (0x4c) normal (normal left inverted right x axis y axis) 473mm x 296mm
LVDS1 connected (normal left inverted right x axis y axis)

When the laptop's in the broken state, check what the xrandr output looks like.

I notice you're running a non-standard kernel. Assuming this issue is a regression and not just a misbehavior you've had but haven't noticed, then that kernel would probably be the first thing to look at (i.e. try a different kernel version and see if it reproduces). All the modesetting is done in the kernel so bugs relating to monitor output often arise from that. I've added a kernel task.

However, this actually feels more like a gnome bug. gnome-settings-daemon (or rather, libgnome-desktop) is what handles the hotplugging event and what remaps crtcs to appropriate outputs. Turn on verbose debugging for that and collect the debugging output before/during/after the hotplug event to see exactly what xrandr events are occurring. That shows what CRTCs are being mapped to what outputs. Often with these types of "output goes missing and just displays corruption" issues, the wrong crtc is mapped to the wrong output device.