From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg Date: Mon, 16 Apr 2012 16:07:59 +0000 Message-ID: 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 259369EBF0 for ; Mon, 16 Apr 2012 09:07:59 -0700 (PDT) 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=46711 --- Comment #9 from Alex Deucher 2012-04-16 09:07:59 PDT --- (In reply to comment #8) > > Brief look doesn't show me any locks there, I'll dig in. The locking (or lack there of) would be on the kernel side. > > If relevant, we have the same symptoms with and without a "desktop > environment". Meaning same thing happens with pure X, and also with our > software running which does explicit output probing when nothing is connected. > > Problem is (seems to me) xrandr reports monitor connected when in that state. > > Also if relevant we do get two RandR events (RRScreenChangeNotify and > RRNotify_OutputChange) when re-plugging the monitor. > > Unless there is no intersection between RandR and DPMS... ? We don't change the dpms state in the hotplug handler we just use the dpms code paths to properly tear down and bring up the display when an enabled monitor is connected or disconnected. Unfortunately it's been a while since I looked at this so I don't remember how events are handled once X gets them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.