Radeon 3650HD laptop LVDS lid open/closed detection problem

[Francisco Jerez]

Alex Deucher <alexdeucher at gmail.com> writes:

> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez at riseup.net> wrote:
>> Jerome Glisse <glisse at freedesktop.org> 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 at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100621/d27ec200/attachment.pgp>