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