From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 33011] HDMI-A-1 Does not work after resume (But claims it does) Date: Fri, 4 Feb 2011 09:13:45 -0800 (PST) Message-ID: <20110204171345.31ADE13004D@annarchy.freedesktop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from annarchy.freedesktop.org (annarchy.freedesktop.org [131.252.210.176]) by gabe.freedesktop.org (Postfix) with ESMTP id 7B0049E89D for ; Fri, 4 Feb 2011 09:13:45 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org https://bugs.freedesktop.org/show_bug.cgi?id=33011 --- Comment #17 from Alex Deucher 2011-02-04 09:13:44 PST --- (In reply to comment #16) > Just a few followups. It doesn't seem to be related to the docking station > switching. The problem occurs even without the docking port. > > Additionally, if I plug an HDMI cable into the laptop while the docking station > is plugged in, the monitor is not detected at all. Where-as after I resume and > have a problem, the monitor is detected, it just doesn't get sync. So the > docking station switching disables the port "more" than the resume problem. This is consistent with the gpio controlled data and ddc routing that I suspect is happening. There's probably a small mux which routes the ddc/hdp lines (for detection and edid) and the data lines (for the actual video signal) between the HDMI port on the laptop and the DVI port on the docking station. When you dock, the acpi docking method probably calls some other method which switches the mux to the other connector. The same thing probably happens on undock. The question is, is this handled by an acpi method or some platform specific gpio/i2c setup. Newer radeon-based laptops that use a mux like this have a special entry in the vbios object table that describes the mux. Unfortunately, your system doesn't have this, so it's probably some system-specific configuration. When you suspend, the mux loses power and goes into some undefined state on resume the signals are not routed correctly since the mux state is wrong. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.