On Wed, Aug 11, 2010 at 2:22 AM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Tue, Aug 10, 2010 at 7:16 PM, Andrei Paskevich <andrei@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
