From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francisco Jerez Subject: Re: Radeon 3650HD laptop LVDS lid open/closed detection problem Date: Mon, 21 Jun 2010 17:52:08 +0200 Message-ID: <87sk4gz8lz.fsf@riseup.net> References: <20100621123119.GJ17817@reaktio.net> <20100621125159.GE2350@barney.localdomain> <87y6e8zbb0.fsf@riseup.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1328650725==" Return-path: Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by gabe.freedesktop.org (Postfix) with ESMTP id 7C39E9E7CA for ; Mon, 21 Jun 2010 08:49:21 -0700 (PDT) In-Reply-To: (Alex Deucher's message of "Mon, 21 Jun 2010 11:12:51 -0400") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 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: Alex Deucher Cc: dri-devel@lists.freedesktop.org, Pasi =?utf-8?B?S8Okcmtrw6RpbmVu?= List-Id: dri-devel@lists.freedesktop.org --===============1328650725== Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alex Deucher writes: > On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez = wrote: >> Jerome Glisse writes: >> >>> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi K=C3=A4rkk=C3=A4inen wro= te: >>>> Hello, >>>> >>>> After fixing the dvi/hdmi detection problem I now have another problem >>>> with the HP EliteBook 8530p, which has Radeon 3650HD adapter. >>>> >>>> Here's a summary of the environment: >>>> >>>> =C2=A0 =C2=A0 =C2=A0- laptop connected to a docking station. >>>> =C2=A0 =C2=A0 =C2=A0- external display in use, connected with DVI to t= he dock. >>>> =C2=A0 =C2=A0 =C2=A0- laptop lid closed, so internal LVDS display is n= ot used. >>>> >>>> Now, when I start the laptop, I can see the BIOS and grub on the exter= nal DVI display. >>>> All fine so far. I select the Fedora 13 kernel, and Linux starts. I se= e the Fedora >>>> graphical boot on the external DVI display, just like it should be. GD= M login prompt >>>> appears on the external DVI display, still everything fine. >>>> >>>> And then it goes wrong. After I login to X, the external display only = shows the background >>>> picture.. it turns out the desktop stuff has been started to the inter= nal LVDS display, >>>> which shouldn't be used at all since the laptop lid is closed!! >>>> >>>> When the laptop lid is closed, and external display is connected, I wa= nt to use only the external display.. >>>> >>>> Any ideas how to troubleshoot this one? > > Does it work ok if you boot up without the external display connected > and then connect and enable the secondary display after you've logged > in? I have a similar issue here; I think it's an issue with rhgb and > starting X. If I boot with an external display, the entire plymouth > load sequence works fine, but then when X starts the external display > goes blank and the internal display hangs on the plymouth screen. On > a related note, if I close the lid and turn off the LVDS output, gpm > never blanks the external monitor. I have to manually force dpms with > xset. > > >>>> >>>> -- Pasi >>>> >>> >>> It's better to open bug when you face issue rather than mail, as it's >>> harder to track information in mail thread than in a bug. Your issue >>> is not easily fixed because there is many laptop with broken acpi which >>> report wrong lid status (some of them always report lid closed what ever >>> is the lid status, other always report lid open, ... i am not expert on >>> how broken this is but from what i have been told i should rather consi= der >>> drinking than trying to look into it and then go to the drinking step). >>> >>> Bottom line is that lid detection is unreliable thus so far we ignore >>> it silently. I think the plan is to monitor lid status change and if >>> we detect change from either open to close or close to open then we >>> can start assuming that acpi lid status is reliable and act accordingly. >>> >> In Nouveau we report connector_status_unknown for closed lids (On the >> kernel side unknown outputs are left disabled unless there's nothing >> else definitely connected: if lid detection doesn't work at all the >> system will still be usable). This would solve your problem if we made >> the X server set the first output known to be connected as RandR >> primary. >> >> In short, I see two different "bugs" here: >> =C2=A0* radeon reports connector_status_connected when the lid is closed. > > Do we really want to report disconnected when the lid is closed? Definitely not, my point was that you could report connector_status_unknown. > The monitor is still connected. Considering how unreliable lid events > are I don't think that makes sense. We probably actually want dpms > off, but connected which is more of a policy thing and should be > handled by userspace. > > Alex > >> =C2=A0* the X server doesn't select a primary output among the definitely >> =C2=A0 connected ones. >> >>> Cheers, >>> Jerome >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAkwfiqgACgkQg5k4nX1Sv1vW+AD+NrJZ39v2UCnXbDcQJIp40ooP rHBzHjI4jplPaj8TLE0A+wZPYBiUcmaPwd0mIvFypaWI9WPX6ejEZcsWsylGRz5u =cm0f -----END PGP SIGNATURE----- --==-=-=-- --===============1328650725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1328650725==--