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.