On Wed, Aug 11, 2010 at 2:22 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Tue, Aug 10, 2010 at 7:16 PM, Andrei Paskevich <andrei at tertium.org> 
> wrote:
>> Currently, the LVDS connector on i915-equipped laptops
>> is always reported as connected, regardless of the lid
>> state and presence of external monitors. This was done
>> because of too many BIOSes reporting lid status in
>> an unreliable way. However, in a quite usual setup of
>> a laptop attached to an external monitor, the only way
>> to obtain the monitor's resolution on boot is to disable
>> the LVDS via the boot command line, which is unfortunate
>> as one have to reboot to get the internal screen back.
>>
>
> This sounds like policy that should be handled in userspace. ?One
> could argue that the LVDS panel is always connected so it should
> always report as connected. ?Your desktop manager or whatever can
> decide what to light up based on what's connected and the current lid
> status.
This can certainly be handled in a desktop manager, as you propose.
The problem is that KMS code will choose the undesired resolution for
the console, well before a desktop manager is started.

I also agree that the LVDS panel is always connected in the proper
sense of the word. What I don't agree with is that every connected
output must be always turned on and configured for some common
resolution, which is almost never what I want (*). Yet the current DRM
implementation does exactly this, and Nouveau provides at least
a good workaround.

Andrei

(*) Except maybe for the case of laptop+beamer, but it is this case
that can and should be treated by one's desktop environment.

>
> Alex
>
>> The following patch implements the same scheme as in
>> the Nouveau driver: if the lid is reported as closed,
>> the LVDS connector status is set to unknown, and the
>> internal screen will be turned on only if there are
>> no other connected monitors. The ACPI lid status is
>> not checked if the "i915.ignorelid" parameter is set
>> to zero (to account for the buggy BIOSes), which is
>> the default value, so that the current behavior does
>> not change.
>>
>> The patch applies to the 2.6.35 kernel.
>>
>> Best regards,
>> Andrei
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 423dc90..5206136 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -45,6 +45,9 @@ module_param_named(fbpercrtc, i915_fbpercrtc, int, 0400);
>> ?unsigned int i915_powersave = 1;
>> ?module_param_named(powersave, i915_powersave, int, 0400);
>>
>> +unsigned int i915_ignorelid = 1;
>> +module_param_named(ignorelid, i915_ignorelid, int, 0400);
>> +
>> ?unsigned int i915_lvds_downclock = 0;
>> ?module_param_named(lvds_downclock, i915_lvds_downclock, int, 0400);
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 2e1744d..a03d344 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -815,6 +815,7 @@ extern struct drm_ioctl_desc i915_ioctls[];
>> ?extern int i915_max_ioctl;
>> ?extern unsigned int i915_fbpercrtc;
>> ?extern unsigned int i915_powersave;
>> +extern unsigned int i915_ignorelid;
>> ?extern unsigned int i915_lvds_downclock;
>>
>> ?extern int i915_suspend(struct drm_device *dev, pm_message_t state);
>> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
>> b/drivers/gpu/drm/i915/intel_lvds.c
>> index 0eab8df..85a09c9 100644
>> --- a/drivers/gpu/drm/i915/intel_lvds.c
>> +++ b/drivers/gpu/drm/i915/intel_lvds.c
>> @@ -551,11 +551,8 @@ static enum drm_connector_status 
>> intel_lvds_detect(struct drm_connector *connect
>> ? ? ? ?struct drm_device *dev = connector->dev;
>> ? ? ? ?enum drm_connector_status status = connector_status_connected;
>>
>> - ? ? ? /* ACPI lid methods were generally unreliable in this generation, so
>> - ? ? ? ?* don't even bother.
>> - ? ? ? ?*/
>> - ? ? ? if (IS_GEN2(dev) || IS_GEN3(dev))
>> - ? ? ? ? ? ? ? return connector_status_connected;
>> + ? ? ? if (!i915_ignorelid && !acpi_lid_open())
>> + ? ? ? ? ? ? ? status = connector_status_unknown;
>>
>> ? ? ? ?return status;
>> ?}
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

Reply via email to