There are a number of small form factor desktop systems with Intel mobile
graphics chips that lie and say they have an LVDS. With kernel mode-setting,
this becomes a problem, and makes native resolution boot go haywire -- for
example, my Dell Studio Hybrid, hooked to a 1920x1080 display claims to
have a 1024x768 LVDS, and the resulting graphical boot on the 1920x1080
display uses only the top left 1024x768, and auto-configured X will end
up only 1024x768 as well. With this change, graphical boot and X
both do 1920x1080 as expected.
Note that we're simply embracing and extending the early bail-out code
in place for the Mac Mini here. The xorg intel driver uses pci subsystem
device and vendor id for matching, while we're using dmi lookups here.
The MSI addition is courtesy of and tested by Bill Nottingham.
One minor issue... Current Fedora rawhide, video playback using Xv makes
X go off into the weeds with this patch added, but that's a bug elsewhere,
still confident this patch DTRT.
Signed-off-by: Jarod Wilson <[email protected]>
Tested-by: Bill Nottingham <[email protected]>
---
drivers/gpu/drm/i915/intel_lvds.c | 46 ++++++++++++++++++++++++++++++------
1 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index 6619f26..4d64686 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -384,7 +384,51 @@ static const struct drm_encoder_funcs intel_lvds_enc_funcs = {
.destroy = intel_lvds_enc_destroy,
};
+static int __init intel_no_lvds_dmi_callback(const struct dmi_system_id *id)
+{
+ DRM_DEBUG("Skipping LVDS initialization for %s\n", id->ident);
+ return 1;
+}
+/* These systems claim to have LVDS, but really don't */
+static const struct dmi_system_id __initdata intel_no_lvds[] = {
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Apple Mac Mini (Core series)",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Macmini1,1"),
+ },
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Apple Mac Mini (Core 2 series)",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Macmini2,1"),
+ },
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "MSI IM-945GSE-A",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "MSI"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "A9830IMS"),
+ },
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Dell Studio Hybrid",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Studio Hybrid 140g"),
+ },
+ },
+
+ /* FIXME: add a check for the Aopen Mini PC */
+
+ { } /* terminating entry */
+};
/**
* intel_lvds_init - setup LVDS connectors on this device
@@ -404,15 +440,9 @@ void intel_lvds_init(struct drm_device *dev)
u32 lvds;
int pipe;
- /* Blacklist machines that we know falsely report LVDS. */
- /* FIXME: add a check for the Aopen Mini PC */
-
- /* Apple Mac Mini Core Duo and Mac Mini Core 2 Duo */
- if(dmi_match(DMI_PRODUCT_NAME, "Macmini1,1") ||
- dmi_match(DMI_PRODUCT_NAME, "Macmini2,1")) {
- DRM_DEBUG("Skipping LVDS initialization for Apple Mac Mini\n");
+ /* Skip init on machines we know falsely report LVDS */
+ if (dmi_check_system(intel_no_lvds))
return;
- }
intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
if (!intel_output) {
--
Jarod Wilson
[email protected]
On Mon, 6 Apr 2009 10:11:25 -0400
Jarod Wilson <[email protected]> wrote:
> There are a number of small form factor desktop systems with Intel
> mobile graphics chips that lie and say they have an LVDS. With kernel
> mode-setting, this becomes a problem, and makes native resolution
> boot go haywire -- for example, my Dell Studio Hybrid, hooked to a
> 1920x1080 display claims to have a 1024x768 LVDS, and the resulting
> graphical boot on the 1920x1080 display uses only the top left
> 1024x768, and auto-configured X will end up only 1024x768 as well.
> With this change, graphical boot and X both do 1920x1080 as expected.
>
> Note that we're simply embracing and extending the early bail-out code
> in place for the Mac Mini here. The xorg intel driver uses pci
> subsystem device and vendor id for matching, while we're using dmi
> lookups here. The MSI addition is courtesy of and tested by Bill
> Nottingham.
>
> One minor issue... Current Fedora rawhide, video playback using Xv
> makes X go off into the weeds with this patch added, but that's a bug
> elsewhere, still confident this patch DTRT.
>
> Signed-off-by: Jarod Wilson <[email protected]>
> Tested-by: Bill Nottingham <[email protected]>
The 2D driver has a similar set of quirks, but since we started that
list we've found that the VBIOS should contain a pretty reliable table
indicating which outputs are available, including LVDS. I think if we
can figure out how to parse it reliably (accounting for VBIOS
versioning and structure size changes) we shouldn't need this patch.
If we can't get that done in time for 2.6.30 though I'm all for
including this.
Zhenyu and Michael does that sound doable?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Monday 06 April 2009 12:52:16 Jesse Barnes wrote:
> On Mon, 6 Apr 2009 10:11:25 -0400
> Jarod Wilson <[email protected]> wrote:
>
> > There are a number of small form factor desktop systems with Intel
> > mobile graphics chips that lie and say they have an LVDS. With kernel
> > mode-setting, this becomes a problem, and makes native resolution
> > boot go haywire -- for example, my Dell Studio Hybrid, hooked to a
> > 1920x1080 display claims to have a 1024x768 LVDS, and the resulting
> > graphical boot on the 1920x1080 display uses only the top left
> > 1024x768, and auto-configured X will end up only 1024x768 as well.
> > With this change, graphical boot and X both do 1920x1080 as expected.
> >
> > Note that we're simply embracing and extending the early bail-out code
> > in place for the Mac Mini here. The xorg intel driver uses pci
> > subsystem device and vendor id for matching, while we're using dmi
> > lookups here. The MSI addition is courtesy of and tested by Bill
> > Nottingham.
> >
> > One minor issue... Current Fedora rawhide, video playback using Xv
> > makes X go off into the weeds with this patch added, but that's a bug
> > elsewhere, still confident this patch DTRT.
> >
> > Signed-off-by: Jarod Wilson <[email protected]>
> > Tested-by: Bill Nottingham <[email protected]>
>
> The 2D driver has a similar set of quirks, but since we started that
> list we've found that the VBIOS should contain a pretty reliable table
> indicating which outputs are available, including LVDS. I think if we
> can figure out how to parse it reliably (accounting for VBIOS
> versioning and structure size changes) we shouldn't need this patch.
> If we can't get that done in time for 2.6.30 though I'm all for
> including this.
Sounds like a plan to me. Either way, would this patch still make sense
for submission to the 2.6.29.x stable series? I've already tacked it
onto the Fedora 2.6.29 kernel builds, fwiw.
--
Jarod Wilson
[email protected]
On Mon, 6 Apr 2009 13:29:53 -0400
Jarod Wilson <[email protected]> wrote:
> On Monday 06 April 2009 12:52:16 Jesse Barnes wrote:
> > On Mon, 6 Apr 2009 10:11:25 -0400
> > Jarod Wilson <[email protected]> wrote:
> >
> > > There are a number of small form factor desktop systems with Intel
> > > mobile graphics chips that lie and say they have an LVDS. With
> > > kernel mode-setting, this becomes a problem, and makes native
> > > resolution boot go haywire -- for example, my Dell Studio Hybrid,
> > > hooked to a 1920x1080 display claims to have a 1024x768 LVDS, and
> > > the resulting graphical boot on the 1920x1080 display uses only
> > > the top left 1024x768, and auto-configured X will end up only
> > > 1024x768 as well. With this change, graphical boot and X both do
> > > 1920x1080 as expected.
> > >
> > > Note that we're simply embracing and extending the early bail-out
> > > code in place for the Mac Mini here. The xorg intel driver uses
> > > pci subsystem device and vendor id for matching, while we're
> > > using dmi lookups here. The MSI addition is courtesy of and
> > > tested by Bill Nottingham.
> > >
> > > One minor issue... Current Fedora rawhide, video playback using Xv
> > > makes X go off into the weeds with this patch added, but that's a
> > > bug elsewhere, still confident this patch DTRT.
> > >
> > > Signed-off-by: Jarod Wilson <[email protected]>
> > > Tested-by: Bill Nottingham <[email protected]>
> >
> > The 2D driver has a similar set of quirks, but since we started that
> > list we've found that the VBIOS should contain a pretty reliable
> > table indicating which outputs are available, including LVDS. I
> > think if we can figure out how to parse it reliably (accounting for
> > VBIOS versioning and structure size changes) we shouldn't need this
> > patch. If we can't get that done in time for 2.6.30 though I'm all
> > for including this.
>
> Sounds like a plan to me. Either way, would this patch still make
> sense for submission to the 2.6.29.x stable series? I've already
> tacked it onto the Fedora 2.6.29 kernel builds, fwiw.
Yeah would be fine for 2.6.29 as far as I'm concerned, but there's an
"upstream first" policy for the stable series that might get in the
way...
--
Jesse Barnes, Intel Open Source Technology Center
On 2009.04.07 00:52:16 +0800, Jesse Barnes wrote:
> On Mon, 6 Apr 2009 10:11:25 -0400
> Jarod Wilson <[email protected]> wrote:
>
> > There are a number of small form factor desktop systems with Intel
> > mobile graphics chips that lie and say they have an LVDS. With kernel
> > mode-setting, this becomes a problem, and makes native resolution
> > boot go haywire -- for example, my Dell Studio Hybrid, hooked to a
> > 1920x1080 display claims to have a 1024x768 LVDS, and the resulting
> > graphical boot on the 1920x1080 display uses only the top left
> > 1024x768, and auto-configured X will end up only 1024x768 as well.
> > With this change, graphical boot and X both do 1920x1080 as expected.
> >
> > Note that we're simply embracing and extending the early bail-out code
> > in place for the Mac Mini here. The xorg intel driver uses pci
> > subsystem device and vendor id for matching, while we're using dmi
> > lookups here. The MSI addition is courtesy of and tested by Bill
> > Nottingham.
> >
> > One minor issue... Current Fedora rawhide, video playback using Xv
> > makes X go off into the weeds with this patch added, but that's a bug
> > elsewhere, still confident this patch DTRT.
> >
> > Signed-off-by: Jarod Wilson <[email protected]>
> > Tested-by: Bill Nottingham <[email protected]>
>
> The 2D driver has a similar set of quirks, but since we started that
> list we've found that the VBIOS should contain a pretty reliable table
> indicating which outputs are available, including LVDS. I think if we
> can figure out how to parse it reliably (accounting for VBIOS
> versioning and structure size changes) we shouldn't need this patch.
> If we can't get that done in time for 2.6.30 though I'm all for
> including this.
>
> Zhenyu and Michael does that sound doable?
>
yeah, that's what I tried to fix, instead of adding quirks in KMS,
we try to find a way to detect LVDS config based on VBIOS table.
But looks failed in first round as I haven't got full right info
on VBIOS LVDS config. Old machines might not have correct VBIOS setting,
and I'm not sure about those Intel Mac machines. So this one is fine to me too.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
On 04/06/2009 08:50 PM, Wang, Zhenyu Z wrote:
> On 2009.04.07 00:52:16 +0800, Jesse Barnes wrote:
>> On Mon, 6 Apr 2009 10:11:25 -0400
>> Jarod Wilson<[email protected]> wrote:
>>
>>> There are a number of small form factor desktop systems with Intel
>>> mobile graphics chips that lie and say they have an LVDS. With kernel
>>> mode-setting, this becomes a problem, and makes native resolution
>>> boot go haywire -- for example, my Dell Studio Hybrid, hooked to a
>>> 1920x1080 display claims to have a 1024x768 LVDS, and the resulting
>>> graphical boot on the 1920x1080 display uses only the top left
>>> 1024x768, and auto-configured X will end up only 1024x768 as well.
>>> With this change, graphical boot and X both do 1920x1080 as expected.
>>>
>>> Note that we're simply embracing and extending the early bail-out code
>>> in place for the Mac Mini here. The xorg intel driver uses pci
>>> subsystem device and vendor id for matching, while we're using dmi
>>> lookups here. The MSI addition is courtesy of and tested by Bill
>>> Nottingham.
>>>
>>> One minor issue... Current Fedora rawhide, video playback using Xv
>>> makes X go off into the weeds with this patch added, but that's a bug
>>> elsewhere, still confident this patch DTRT.
As it turns out, this part is resolution-specific and kms-specific...
When hooked up to a 1280x1024 monitor with or without kms enabled, no
problems at all. When hooked to my HDTV, outputting at 1920x1080 with
kms disabled, no problems. Only at 1920x1080 with kms enabled do things
go sideways. Not sure exactly what the resolution tipping point is.
>> The 2D driver has a similar set of quirks, but since we started that
>> list we've found that the VBIOS should contain a pretty reliable table
>> indicating which outputs are available, including LVDS. I think if we
>> can figure out how to parse it reliably (accounting for VBIOS
>> versioning and structure size changes) we shouldn't need this patch.
>> If we can't get that done in time for 2.6.30 though I'm all for
>> including this.
>>
>> Zhenyu and Michael does that sound doable?
>>
>
> yeah, that's what I tried to fix, instead of adding quirks in KMS,
> we try to find a way to detect LVDS config based on VBIOS table.
> But looks failed in first round as I haven't got full right info
> on VBIOS LVDS config. Old machines might not have correct VBIOS setting,
> and I'm not sure about those Intel Mac machines. So this one is fine to me too.
So is there still work being done to probe the VBIOS, or has that
already proven to be fraught with peril? (In which case, what say we
throw this in sooner than later?).
--
Jarod Wilson
[email protected]