Radeon 3650HD laptop LVDS lid open/closed detection problem

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

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? 

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Jerome Glisse]

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? 
> 
> -- 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.

Cheers,
Jerome

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 2871 bytes --]

Jerome Glisse <glisse@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? 
>> 
>> -- 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.
 * the X server doesn't select a primary output among the definitely
   connected ones.

> Cheers,
> Jerome
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Alex Deucher]

On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez@riseup.net> wrote:
> Jerome Glisse <glisse@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?  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@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
>
>

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 4342 bytes --]

Alex Deucher <alexdeucher@gmail.com> writes:

> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez@riseup.net> wrote:
>> Jerome Glisse <glisse@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@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
>>
>>

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 02:51:59PM +0200, Jerome Glisse wrote:
> 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? 
> > 
> > -- 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).
> 

Hey, I'm from Finland, so drinking and debugging is not a problem ;)

> 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.
> 

I hate to play the "windows card" but the lid detection seems to work in windows.. 
so there's a way to make it work :)

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez@riseup.net> wrote:
> > Jerome Glisse <glisse@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 just tried this.

I boot up the laptop with lid open, so ONLY the internal LVDS is active 
(DVI cable disconnected), and I get the GDM login prompt on the internal LVDS.

Then I plug in the external DVI display, and the external display
gets automatically active when X starts. Gnome panel etc are on the internal LVDS,
external DVI display only has the background image and nothing else.

So that works as expected. No problems there.

>  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.
> 

The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied 
my system mostly works now, but here's a summary about the problem I still have
with the lid detection:

- I boot up the laptop with lid closed (LVDS inactive) so there's only external
DVI display connected. Kernel boot messages show up on the external DVI display,
and GDM login prompt appears on the external DVI display. All fine so far.

- The actual problem: when X starts gnome panel etc show up on the internal LVDS
display, which I can't see at all since the lid is closed! So those should go to the
external DVI display only.. LVDS should be disconnected or inactive or something..

Any pointers appreciated where to look at in the source.. I can do some debugging.

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Alex Deucher]

On Mon, Jul 12, 2010 at 7:53 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
>> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez@riseup.net> wrote:
>> > Jerome Glisse <glisse@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 just tried this.
>
> I boot up the laptop with lid open, so ONLY the internal LVDS is active
> (DVI cable disconnected), and I get the GDM login prompt on the internal LVDS.
>
> Then I plug in the external DVI display, and the external display
> gets automatically active when X starts. Gnome panel etc are on the internal LVDS,
> external DVI display only has the background image and nothing else.
>
> So that works as expected. No problems there.
>
>>  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.
>>
>
> The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
> my system mostly works now, but here's a summary about the problem I still have
> with the lid detection:
>
> - I boot up the laptop with lid closed (LVDS inactive) so there's only external
> DVI display connected. Kernel boot messages show up on the external DVI display,
> and GDM login prompt appears on the external DVI display. All fine so far.
>
> - The actual problem: when X starts gnome panel etc show up on the internal LVDS
> display, which I can't see at all since the lid is closed! So those should go to the
> external DVI display only.. LVDS should be disconnected or inactive or something..
>
> Any pointers appreciated where to look at in the source.. I can do some debugging.

Your desktop session manager should check the lid status when it loads
and attempt to do the right thing if there is an external monitor
detected.

Alex

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 12, 2010 at 10:48:08AM -0400, Alex Deucher wrote:
> On Mon, Jul 12, 2010 at 7:53 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
> >> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez@riseup.net> wrote:
> >> > Jerome Glisse <glisse@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 just tried this.
> >
> > I boot up the laptop with lid open, so ONLY the internal LVDS is active
> > (DVI cable disconnected), and I get the GDM login prompt on the internal LVDS.
> >
> > Then I plug in the external DVI display, and the external display
> > gets automatically active when X starts. Gnome panel etc are on the internal LVDS,
> > external DVI display only has the background image and nothing else.
> >
> > So that works as expected. No problems there.
> >
> >>  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.
> >>
> >
> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
> > my system mostly works now, but here's a summary about the problem I still have
> > with the lid detection:
> >
> > - I boot up the laptop with lid closed (LVDS inactive) so there's only external
> > DVI display connected. Kernel boot messages show up on the external DVI display,
> > and GDM login prompt appears on the external DVI display. All fine so far.
> >
> > - The actual problem: when X starts gnome panel etc show up on the internal LVDS
> > display, which I can't see at all since the lid is closed! So those should go to the
> > external DVI display only.. LVDS should be disconnected or inactive or something..
> >
> > Any pointers appreciated where to look at in the source.. I can do some debugging.
> 
> Your desktop session manager should check the lid status when it loads
> and attempt to do the right thing if there is an external monitor
> detected.
> 

Ok.
So you think it's not a bug in the lid detection? 

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Alex Deucher]

On Mon, Jul 12, 2010 at 12:59 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Mon, Jul 12, 2010 at 10:48:08AM -0400, Alex Deucher wrote:
>> On Mon, Jul 12, 2010 at 7:53 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>> > On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
>> >> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez <currojerez@riseup.net> wrote:
>> >> > Jerome Glisse <glisse@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 just tried this.
>> >
>> > I boot up the laptop with lid open, so ONLY the internal LVDS is active
>> > (DVI cable disconnected), and I get the GDM login prompt on the internal LVDS.
>> >
>> > Then I plug in the external DVI display, and the external display
>> > gets automatically active when X starts. Gnome panel etc are on the internal LVDS,
>> > external DVI display only has the background image and nothing else.
>> >
>> > So that works as expected. No problems there.
>> >
>> >>  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.
>> >>
>> >
>> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
>> > my system mostly works now, but here's a summary about the problem I still have
>> > with the lid detection:
>> >
>> > - I boot up the laptop with lid closed (LVDS inactive) so there's only external
>> > DVI display connected. Kernel boot messages show up on the external DVI display,
>> > and GDM login prompt appears on the external DVI display. All fine so far.
>> >
>> > - The actual problem: when X starts gnome panel etc show up on the internal LVDS
>> > display, which I can't see at all since the lid is closed! So those should go to the
>> > external DVI display only.. LVDS should be disconnected or inactive or something..
>> >
>> > Any pointers appreciated where to look at in the source.. I can do some debugging.
>>
>> Your desktop session manager should check the lid status when it loads
>> and attempt to do the right thing if there is an external monitor
>> detected.
>>
>
> Ok.
> So you think it's not a bug in the lid detection?

Not sure.  That's handled by apci, not the video driver.  You can
check it the lid is producing proper events by running:
cat /proc/acpi/button/lid/LID/state
with the lid open and closed.  The desktop manager decides what the
policy is for the lid (blank display, suspend, turn off the connector,
etc.).  It should also take into account other connected outputs, but
I don't think it handles that too well at the moment.

Alex

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 12, 2010 at 01:37:28PM -0400, Alex Deucher wrote:
> >> >>
> >> >
> >> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
> >> > my system mostly works now, but here's a summary about the problem I still have
> >> > with the lid detection:
> >> >
> >> > - I boot up the laptop with lid closed (LVDS inactive) so there's only external
> >> > DVI display connected. Kernel boot messages show up on the external DVI display,
> >> > and GDM login prompt appears on the external DVI display. All fine so far.
> >> >
> >> > - The actual problem: when X starts gnome panel etc show up on the internal LVDS
> >> > display, which I can't see at all since the lid is closed! So those should go to the
> >> > external DVI display only.. LVDS should be disconnected or inactive or something..
> >> >
> >> > Any pointers appreciated where to look at in the source.. I can do some debugging.
> >>
> >> Your desktop session manager should check the lid status when it loads
> >> and attempt to do the right thing if there is an external monitor
> >> detected.
> >>
> >
> > Ok.
> > So you think it's not a bug in the lid detection?
> 
> Not sure.  That's handled by apci, not the video driver.  You can
> check it the lid is producing proper events by running:
> cat /proc/acpi/button/lid/LID/state
> with the lid open and closed.  The desktop manager decides what the
> policy is for the lid (blank display, suspend, turn off the connector,
> etc.).  It should also take into account other connected outputs, but
> I don't think it handles that too well at the moment.
> 

Yes, the lid acpi stuff seems to work:

lid closed:
$ cat /proc/acpi/button/lid/LID/state 
state:      closed

lid open:
$ cat /proc/acpi/button/lid/LID/state 
state:      open

I also verified that the initial lid state is "closed" when 
the lid has been closed all the time during system startup 
and only external DVI display is in use. 

(I modified /etc/rc5.d/S01sysstat to sleep+print+sleep 
so I can check it during system startup before X starts).

When the lid is closed xrandr says "LVDS connected", is that correct? 

I think LVDS actually is ON when lid is closed, since I can immediately 
see everything when I open the lid.. correct colors etc.

So what's the component I should start looking at.. gnome-power-manager? 
or something else? 

Actually.. I just noticed that already in GDM prompt the internal LVDS
gets enabled/turned on, even when the lid is closed.. I think.

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Alex Deucher]

On Mon, Jul 26, 2010 at 3:42 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Mon, Jul 12, 2010 at 01:37:28PM -0400, Alex Deucher wrote:
>> >> >>
>> >> >
>> >> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
>> >> > my system mostly works now, but here's a summary about the problem I still have
>> >> > with the lid detection:
>> >> >
>> >> > - I boot up the laptop with lid closed (LVDS inactive) so there's only external
>> >> > DVI display connected. Kernel boot messages show up on the external DVI display,
>> >> > and GDM login prompt appears on the external DVI display. All fine so far.
>> >> >
>> >> > - The actual problem: when X starts gnome panel etc show up on the internal LVDS
>> >> > display, which I can't see at all since the lid is closed! So those should go to the
>> >> > external DVI display only.. LVDS should be disconnected or inactive or something..
>> >> >
>> >> > Any pointers appreciated where to look at in the source.. I can do some debugging.
>> >>
>> >> Your desktop session manager should check the lid status when it loads
>> >> and attempt to do the right thing if there is an external monitor
>> >> detected.
>> >>
>> >
>> > Ok.
>> > So you think it's not a bug in the lid detection?
>>
>> Not sure.  That's handled by apci, not the video driver.  You can
>> check it the lid is producing proper events by running:
>> cat /proc/acpi/button/lid/LID/state
>> with the lid open and closed.  The desktop manager decides what the
>> policy is for the lid (blank display, suspend, turn off the connector,
>> etc.).  It should also take into account other connected outputs, but
>> I don't think it handles that too well at the moment.
>>
>
> Yes, the lid acpi stuff seems to work:
>
> lid closed:
> $ cat /proc/acpi/button/lid/LID/state
> state:      closed
>
> lid open:
> $ cat /proc/acpi/button/lid/LID/state
> state:      open
>
> I also verified that the initial lid state is "closed" when
> the lid has been closed all the time during system startup
> and only external DVI display is in use.
>
> (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> so I can check it during system startup before X starts).
>
> When the lid is closed xrandr says "LVDS connected", is that correct?

Yes.  The LVDS is connected, even if you don't necessarily want to use it.

>
> I think LVDS actually is ON when lid is closed, since I can immediately
> see everything when I open the lid.. correct colors etc.
>
> So what's the component I should start looking at.. gnome-power-manager?
> or something else?
>
> Actually.. I just noticed that already in GDM prompt the internal LVDS
> gets enabled/turned on, even when the lid is closed.. I think.

Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
display policy based on the lid state.

Alex

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 26, 2010 at 05:13:30PM -0400, Alex Deucher wrote:
> On Mon, Jul 26, 2010 at 3:42 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Mon, Jul 12, 2010 at 01:37:28PM -0400, Alex Deucher wrote:
> >> >> >>
> >> >> >
> >> >> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
> >> >> > my system mostly works now, but here's a summary about the problem I still have
> >> >> > with the lid detection:
> >> >> >
> >> >> > - I boot up the laptop with lid closed (LVDS inactive) so there's only external
> >> >> > DVI display connected. Kernel boot messages show up on the external DVI display,
> >> >> > and GDM login prompt appears on the external DVI display. All fine so far.
> >> >> >
> >> >> > - The actual problem: when X starts gnome panel etc show up on the internal LVDS
> >> >> > display, which I can't see at all since the lid is closed! So those should go to the
> >> >> > external DVI display only.. LVDS should be disconnected or inactive or something..
> >> >> >
> >> >> > Any pointers appreciated where to look at in the source.. I can do some debugging.
> >> >>
> >> >> Your desktop session manager should check the lid status when it loads
> >> >> and attempt to do the right thing if there is an external monitor
> >> >> detected.
> >> >>
> >> >
> >> > Ok.
> >> > So you think it's not a bug in the lid detection?
> >>
> >> Not sure.  That's handled by apci, not the video driver.  You can
> >> check it the lid is producing proper events by running:
> >> cat /proc/acpi/button/lid/LID/state
> >> with the lid open and closed.  The desktop manager decides what the
> >> policy is for the lid (blank display, suspend, turn off the connector,
> >> etc.).  It should also take into account other connected outputs, but
> >> I don't think it handles that too well at the moment.
> >>
> >
> > Yes, the lid acpi stuff seems to work:
> >
> > lid closed:
> > $ cat /proc/acpi/button/lid/LID/state
> > state:      closed
> >
> > lid open:
> > $ cat /proc/acpi/button/lid/LID/state
> > state:      open
> >
> > I also verified that the initial lid state is "closed" when
> > the lid has been closed all the time during system startup
> > and only external DVI display is in use.
> >
> > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > so I can check it during system startup before X starts).
> >
> > When the lid is closed xrandr says "LVDS connected", is that correct?
> 
> Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> 

That's what I was thinking of. But good to get confirmation :)

> >
> > I think LVDS actually is ON when lid is closed, since I can immediately
> > see everything when I open the lid.. correct colors etc.
> >
> > So what's the component I should start looking at.. gnome-power-manager?
> > or something else?
> >
> > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > gets enabled/turned on, even when the lid is closed.. I think.
> 
> Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> display policy based on the lid state.
> 

Ok. Is there a way to monitor the status of drm from /proc or /sys or from somewhere? 

I guess I'll have to start reading GDM code to check what it does..

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi Kärkkäinen wrote:
> > >>
> > >
> > > Yes, the lid acpi stuff seems to work:
> > >
> > > lid closed:
> > > $ cat /proc/acpi/button/lid/LID/state
> > > state:      closed
> > >
> > > lid open:
> > > $ cat /proc/acpi/button/lid/LID/state
> > > state:      open
> > >
> > > I also verified that the initial lid state is "closed" when
> > > the lid has been closed all the time during system startup
> > > and only external DVI display is in use.
> > >
> > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > so I can check it during system startup before X starts).
> > >
> > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > 
> > Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> > 
> 
> That's what I was thinking of. But good to get confirmation :)
> 
> > >
> > > I think LVDS actually is ON when lid is closed, since I can immediately
> > > see everything when I open the lid.. correct colors etc.
> > >
> > > So what's the component I should start looking at.. gnome-power-manager?
> > > or something else?
> > >
> > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > gets enabled/turned on, even when the lid is closed.. I think.
> > 
> > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > display policy based on the lid state.
> > 
> 
> Ok. Is there a way to monitor the status of drm from /proc or /sys or from somewhere? 
> 

Back to this..

so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere? 

I'd like to see the state before X is started, and verify what happens when GDM is started etc.. 
(ie. if outputs are enabled/active or not).

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 02:18:34PM +0300, Pasi Kärkkäinen wrote:
> On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi Kärkkäinen wrote:
> > > >>
> > > >
> > > > Yes, the lid acpi stuff seems to work:
> > > >
> > > > lid closed:
> > > > $ cat /proc/acpi/button/lid/LID/state
> > > > state:      closed
> > > >
> > > > lid open:
> > > > $ cat /proc/acpi/button/lid/LID/state
> > > > state:      open
> > > >
> > > > I also verified that the initial lid state is "closed" when
> > > > the lid has been closed all the time during system startup
> > > > and only external DVI display is in use.
> > > >
> > > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > > so I can check it during system startup before X starts).
> > > >
> > > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > > 
> > > Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> > > 
> > 
> > That's what I was thinking of. But good to get confirmation :)
> > 
> > > >
> > > > I think LVDS actually is ON when lid is closed, since I can immediately
> > > > see everything when I open the lid.. correct colors etc.
> > > >
> > > > So what's the component I should start looking at.. gnome-power-manager?
> > > > or something else?
> > > >
> > > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > > gets enabled/turned on, even when the lid is closed.. I think.
> > > 
> > > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > > display policy based on the lid state.
> > > 
> > 
> > Ok. Is there a way to monitor the status of drm from /proc or /sys or from somewhere? 
> > 
> 
> Back to this..
> 
> so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere? 
> 
> I'd like to see the state before X is started, and verify what happens when GDM is started etc.. 
> (ie. if outputs are enabled/active or not).
> 

Ah, found it:

$ ls /sys/class/drm/card0
card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
card0-HDMI Type A-1  card0-VGA-1   device  subsystem

$ cat /sys/class/drm/card0/card0-LVDS-1/status 
connected

$ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
enabled

$ cat /sys/class/drm/card0/card0-LVDS-1/modes 
1680x1050
1400x1050
1280x1024
1440x900
1280x960
1280x854
1280x800
1280x720
1152x768
1024x768
800x600
848x480
720x480
640x480


-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 02:34:03PM +0300, Pasi Kärkkäinen wrote:
> On Sun, Sep 19, 2010 at 02:18:34PM +0300, Pasi Kärkkäinen wrote:
> > On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi Kärkkäinen wrote:
> > > > >>
> > > > >
> > > > > Yes, the lid acpi stuff seems to work:
> > > > >
> > > > > lid closed:
> > > > > $ cat /proc/acpi/button/lid/LID/state
> > > > > state:      closed
> > > > >
> > > > > lid open:
> > > > > $ cat /proc/acpi/button/lid/LID/state
> > > > > state:      open
> > > > >
> > > > > I also verified that the initial lid state is "closed" when
> > > > > the lid has been closed all the time during system startup
> > > > > and only external DVI display is in use.
> > > > >
> > > > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > > > so I can check it during system startup before X starts).
> > > > >
> > > > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > > > 
> > > > Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> > > > 
> > > 
> > > That's what I was thinking of. But good to get confirmation :)
> > > 
> > > > >
> > > > > I think LVDS actually is ON when lid is closed, since I can immediately
> > > > > see everything when I open the lid.. correct colors etc.
> > > > >
> > > > > So what's the component I should start looking at.. gnome-power-manager?
> > > > > or something else?
> > > > >
> > > > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > > > gets enabled/turned on, even when the lid is closed.. I think.
> > > > 
> > > > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > > > display policy based on the lid state.
> > > > 
> > > 
> > > Ok. Is there a way to monitor the status of drm from /proc or /sys or from somewhere? 
> > > 
> > 
> > Back to this..
> > 
> > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> > but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere? 
> > 
> > I'd like to see the state before X is started, and verify what happens when GDM is started etc.. 
> > (ie. if outputs are enabled/active or not).
> > 
> 
> Ah, found it:
> 
> $ ls /sys/class/drm/card0
> card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
> card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> 
> $ cat /sys/class/drm/card0/card0-LVDS-1/status 
> connected
> 
> $ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
> enabled
> 

So I added those to rc.local so that they get executed before GDM..
and I booted up the laptop with the lid closed..

And the result was: lid state "closed", lvds-status "connected" and lvds-enabled was "enabled"..

Does that mean Fedora plymouth is doing it wrong,
or is t possible the driver itself always enabled the lvds, even when the lid is closed? 

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
> > > 
> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> > > but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere? 
> > > 
> > > I'd like to see the state before X is started, and verify what happens when GDM is started etc.. 
> > > (ie. if outputs are enabled/active or not).
> > > 
> > 
> > Ah, found it:
> > 
> > $ ls /sys/class/drm/card0
> > card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> > 
> > $ cat /sys/class/drm/card0/card0-LVDS-1/status 
> > connected
> > 
> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
> > enabled
> > 
> 
> So I added those to rc.local so that they get executed before GDM..
> and I booted up the laptop with the lid closed..
> 
> And the result was: lid state "closed", lvds-status "connected" and lvds-enabled was "enabled"..
> 
> Does that mean Fedora plymouth is doing it wrong,
> or is t possible the driver itself always enabled the lvds, even when the lid is closed? 
> 

I did some more investigations. I'm currently using Fedora 13 Linux 2.6.34.6-47.fc13.x86_64 kernel.
I hacked the initrd image to echo debug stuff right after drm modules are loaded, 
and *before* plymouth is started (and then sleep for some time so that I have time to see the debug values.)

The result was this:

acpi lid/state: closed
lvds-1/status: connected
lvds-1/enabled: enabled

So to me it looks like the problem is in the driver itself..
lvds shouldn't get enabled (turned on) when the lid is closed..

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Alex Deucher]

On Sun, Sep 19, 2010 at 10:56 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
>> > >
>> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
>> > > but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere?
>> > >
>> > > I'd like to see the state before X is started, and verify what happens when GDM is started etc..
>> > > (ie. if outputs are enabled/active or not).
>> > >
>> >
>> > Ah, found it:
>> >
>> > $ ls /sys/class/drm/card0
>> > card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
>> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
>> >
>> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
>> > connected
>> >
>> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
>> > enabled
>> >
>>
>> So I added those to rc.local so that they get executed before GDM..
>> and I booted up the laptop with the lid closed..
>>
>> And the result was: lid state "closed", lvds-status "connected" and lvds-enabled was "enabled"..
>>
>> Does that mean Fedora plymouth is doing it wrong,
>> or is t possible the driver itself always enabled the lvds, even when the lid is closed?
>>
>
> I did some more investigations. I'm currently using Fedora 13 Linux 2.6.34.6-47.fc13.x86_64 kernel.
> I hacked the initrd image to echo debug stuff right after drm modules are loaded,
> and *before* plymouth is started (and then sleep for some time so that I have time to see the debug values.)
>
> The result was this:
>
> acpi lid/state: closed
> lvds-1/status: connected
> lvds-1/enabled: enabled
>
> So to me it looks like the problem is in the driver itself..
> lvds shouldn't get enabled (turned on) when the lid is closed..

As I've stated previously, the driver always reports LVDS as connected
because it is always connected.  It's up to userspace to decide on
what policy (enabled or disabled) to implement when the lid is open vs
closed.

Alex

>
> -- Pasi
>
>

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 11:56:27PM -0400, Alex Deucher wrote:
> On Sun, Sep 19, 2010 at 10:56 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
> >> > >
> >> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> >> > > but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere?
> >> > >
> >> > > I'd like to see the state before X is started, and verify what happens when GDM is started etc..
> >> > > (ie. if outputs are enabled/active or not).
> >> > >
> >> >
> >> > Ah, found it:
> >> >
> >> > $ ls /sys/class/drm/card0
> >> > card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
> >> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> >> >
> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
> >> > connected
> >> >
> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
> >> > enabled
> >> >
> >>
> >> So I added those to rc.local so that they get executed before GDM..
> >> and I booted up the laptop with the lid closed..
> >>
> >> And the result was: lid state "closed", lvds-status "connected" and lvds-enabled was "enabled"..
> >>
> >> Does that mean Fedora plymouth is doing it wrong,
> >> or is t possible the driver itself always enabled the lvds, even when the lid is closed?
> >>
> >
> > I did some more investigations. I'm currently using Fedora 13 Linux 2.6.34.6-47.fc13.x86_64 kernel.
> > I hacked the initrd image to echo debug stuff right after drm modules are loaded,
> > and *before* plymouth is started (and then sleep for some time so that I have time to see the debug values.)
> >
> > The result was this:
> >
> > acpi lid/state: closed
> > lvds-1/status: connected
> > lvds-1/enabled: enabled
> >
> > So to me it looks like the problem is in the driver itself..
> > lvds shouldn't get enabled (turned on) when the lid is closed..
> 
> As I've stated previously, the driver always reports LVDS as connected
> because it is always connected.  It's up to userspace to decide on
> what policy (enabled or disabled) to implement when the lid is open vs
> closed.
> 

Yep, I do realize it's always connected.

But the question was supposed to be more about the enabled/disabled part.. 
It isn't possible to check the acpi lid status from the driver? 

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Alex Deucher]

On Mon, Sep 20, 2010 at 1:53 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Sun, Sep 19, 2010 at 11:56:27PM -0400, Alex Deucher wrote:
>> On Sun, Sep 19, 2010 at 10:56 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>> > On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
>> >> > >
>> >> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
>> >> > > but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere?
>> >> > >
>> >> > > I'd like to see the state before X is started, and verify what happens when GDM is started etc..
>> >> > > (ie. if outputs are enabled/active or not).
>> >> > >
>> >> >
>> >> > Ah, found it:
>> >> >
>> >> > $ ls /sys/class/drm/card0
>> >> > card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
>> >> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
>> >> >
>> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
>> >> > connected
>> >> >
>> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
>> >> > enabled
>> >> >
>> >>
>> >> So I added those to rc.local so that they get executed before GDM..
>> >> and I booted up the laptop with the lid closed..
>> >>
>> >> And the result was: lid state "closed", lvds-status "connected" and lvds-enabled was "enabled"..
>> >>
>> >> Does that mean Fedora plymouth is doing it wrong,
>> >> or is t possible the driver itself always enabled the lvds, even when the lid is closed?
>> >>
>> >
>> > I did some more investigations. I'm currently using Fedora 13 Linux 2.6.34.6-47.fc13.x86_64 kernel.
>> > I hacked the initrd image to echo debug stuff right after drm modules are loaded,
>> > and *before* plymouth is started (and then sleep for some time so that I have time to see the debug values.)
>> >
>> > The result was this:
>> >
>> > acpi lid/state: closed
>> > lvds-1/status: connected
>> > lvds-1/enabled: enabled
>> >
>> > So to me it looks like the problem is in the driver itself..
>> > lvds shouldn't get enabled (turned on) when the lid is closed..
>>
>> As I've stated previously, the driver always reports LVDS as connected
>> because it is always connected.  It's up to userspace to decide on
>> what policy (enabled or disabled) to implement when the lid is open vs
>> closed.
>>
>
> Yep, I do realize it's always connected.
>
> But the question was supposed to be more about the enabled/disabled part..
> It isn't possible to check the acpi lid status from the driver?

It is possible but:

1. Acpi lid status is very unreliable on a lot of notebooks
2. Policy is set in userspace, so your desktop manager should decide
what to enable in what cases.

Also there are laptops with built in color management tools that
require the panel be on when the lid is closed to run.

Alex

>
> -- Pasi
>
>

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Tue, Sep 21, 2010 at 01:09:37AM -0400, Alex Deucher wrote:
> On Mon, Sep 20, 2010 at 1:53 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Sun, Sep 19, 2010 at 11:56:27PM -0400, Alex Deucher wrote:
> >> On Sun, Sep 19, 2010 at 10:56 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >> > On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
> >> >> > >
> >> >> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> >> >> > > but is there a way to monitor the state of the drm/kms outputs from /proc, /sys or from somewhere?
> >> >> > >
> >> >> > > I'd like to see the state before X is started, and verify what happens when GDM is started etc..
> >> >> > > (ie. if outputs are enabled/active or not).
> >> >> > >
> >> >> >
> >> >> > Ah, found it:
> >> >> >
> >> >> > $ ls /sys/class/drm/card0
> >> >> > card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
> >> >> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> >> >> >
> >> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
> >> >> > connected
> >> >> >
> >> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
> >> >> > enabled
> >> >> >
> >> >>
> >> >> So I added those to rc.local so that they get executed before GDM..
> >> >> and I booted up the laptop with the lid closed..
> >> >>
> >> >> And the result was: lid state "closed", lvds-status "connected" and lvds-enabled was "enabled"..
> >> >>
> >> >> Does that mean Fedora plymouth is doing it wrong,
> >> >> or is t possible the driver itself always enabled the lvds, even when the lid is closed?
> >> >>
> >> >
> >> > I did some more investigations. I'm currently using Fedora 13 Linux 2.6.34.6-47.fc13.x86_64 kernel.
> >> > I hacked the initrd image to echo debug stuff right after drm modules are loaded,
> >> > and *before* plymouth is started (and then sleep for some time so that I have time to see the debug values.)
> >> >
> >> > The result was this:
> >> >
> >> > acpi lid/state: closed
> >> > lvds-1/status: connected
> >> > lvds-1/enabled: enabled
> >> >
> >> > So to me it looks like the problem is in the driver itself..
> >> > lvds shouldn't get enabled (turned on) when the lid is closed..
> >>
> >> As I've stated previously, the driver always reports LVDS as connected
> >> because it is always connected.  It's up to userspace to decide on
> >> what policy (enabled or disabled) to implement when the lid is open vs
> >> closed.
> >>
> >
> > Yep, I do realize it's always connected.
> >
> > But the question was supposed to be more about the enabled/disabled part..
> > It isn't possible to check the acpi lid status from the driver?
> 
> It is possible but:
> 
> 1. Acpi lid status is very unreliable on a lot of notebooks
>

Yeah.. seems to work fine on mine though.

> 2. Policy is set in userspace, so your desktop manager should decide
> what to enable in what cases.
> 

Police in userspace makes sense..

> Also there are laptops with built in color management tools that
> require the panel be on when the lid is closed to run.
> 

Hmm.. ok.
So I guess I'll have to continue with plymouth/gdm/Xorg people..

Thanks!

-- Pasi