Alex Deucher <alexdeucher@xxxxxxxxx> writes: > On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez@xxxxxxxxxx> wrote: >> Jerome Glisse <glisse@xxxxxxxxxxxxxxx> writes: >> >>> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi Kärkkäinen wrote: >>>> 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: >>>> >>>> - laptop connected to a docking station. >>>> - external display in use, connected with DVI to the dock. >>>> - laptop lid closed, so internal LVDS display is not used. >>>> >>>> Now, when I start the laptop, I can see the BIOS and grub on the external DVI display. >>>> All fine so far. I select the Fedora 13 kernel, and Linux starts. I see the Fedora >>>> graphical boot on the external DVI display, just like it should be. GDM 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 internal 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 want 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 consider >>> 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: >> * 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 > >> * the X server doesn't select a primary output among the definitely >> connected ones. >> >>> Cheers, >>> Jerome >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >>
Attachment:
pgpllmorraGlA.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
