NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/49285 drmkms on pineview (intel)
The following reply was made to PR kern/49285; it has been noted by GNATS.
From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: kern/49285 drmkms on pineview (intel)
Date: Sun, 21 Jun 2015 17:47:23 +0000
This is a multi-part message in MIME format.
--=_mhnjjyDs2XN8L143ZHZeZQ7Cd5dNYPgR
Sent to netbsd-bugs.
--=_mhnjjyDs2XN8L143ZHZeZQ7Cd5dNYPgR
Content-Type: message/rfc822
Content-Disposition: inline
Date: Wed, 17 Jun 2015 17:26:30 +0100
From: Patrick Welche <prlw1%cam.ac.uk@localhost>
To: riastradh%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/49285 drmkms on pineview (intel)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I connected the "broken" monitor above, which is detected by the pineview
as having a broken 0x00ffffff... EDID into a -current/amd64 Sandy Bridge
laptop, and happily used it as a second high resolution screen.
The Sandy Bridge managed to read its EDID successfully (including no
mention of bit banging).
I applied the following kludge:
Index: sys/external/bsd/drm2/dist/drm/drm_edid.c
===================================================================
RCS file: /cvsroot/src/sys/external/bsd/drm2/dist/drm/drm_edid.c,v
retrieving revision 1.4
diff -u -r1.4 drm_edid.c
--- sys/external/bsd/drm2/dist/drm/drm_edid.c 16 Jul 2014 20:56:24 -0000 1.4
+++ sys/external/bsd/drm2/dist/drm/drm_edid.c 17 Jun 2015 16:03:43 -0000
EXPORT_SYMBOL(drm_edid_block_valid);
@@ -1282,10 +1284,28 @@
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
+ static const u8 rawedid[EDID_LENGTH] = {
+0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x26,0xcd,0x0d,0x56,0x01,0x01,0x01,0x01,
+0x32,0x13,0x01,0x03,0x68,0x34,0x1e,0x78,0x2a,0xee,0xd5,0xa5,0x55,0x48,0x9b,0x26,
+0x12,0x50,0x54,0xbf,0xef,0x80,0xb3,0x00,0xa9,0x40,0x95,0x00,0x81,0x8f,0x81,0x80,
+0x95,0x0f,0x71,0x4f,0x01,0x01,0x94,0x43,0x80,0x90,0x72,0x38,0x28,0x40,0x80,0xc8,
+0x35,0x00,0x09,0x25,0x21,0x00,0x00,0x1c,0x00,0x00,0x00,0xff,0x00,0x31,0x31,0x30,
+0x30,0x31,0x39,0x35,0x30,0x35,0x30,0x30,0x34,0x30,0x00,0x00,0x00,0xfd,0x00,0x37,
+0x4c,0x1d,0x51,0x12,0x00,0x0a,0x20,0x20,0x20,0x20,0x20,0x20,0x00,0x00,0x00,0xfc,
+0x00,0x50,0x4c,0x45,0x32,0x34,0x30,0x37,0x48,0x44,0x53,0x0a,0x20,0x20,0x00,0xae
+ };
+
+/*
struct edid *edid = NULL;
if (drm_probe_ddc(adapter))
edid = (struct edid *)drm_do_get_edid(connector, adapter);
+*/
+
+ struct edid *edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
+
+ if (edid != NULL)
+ memcpy(edid, rawedid, EDID_LENGTH);
return edid;
}
and said pineview now does 1366x768 pixels on the "broken" monitor, (without
trying to disable the spurious LVDS1 connector)...
Sounds like this all boils down to a gmbus problem...
--=_mhnjjyDs2XN8L143ZHZeZQ7Cd5dNYPgR--
Home |
Main Index |
Thread Index |
Old Index