public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Hounschell <dmarkh@cfl.rr.com>
To: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: markh@compro.net, linux-kernel@vger.kernel.org,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: Intel graphics drm issue?
Date: Sun, 14 Oct 2012 12:54:34 -0400	[thread overview]
Message-ID: <507AEE4A.1000907@cfl.rr.com> (raw)
In-Reply-To: <20121014130323.06f0225d@neptune.home>

On 10/14/2012 07:03 AM, Bruno Prémont wrote:
> On Sun, 14 October 2012 Mark Hounschell <dmarkh@cfl.rr.com> wrote:
>> On 10/14/2012 04:41 AM, Bruno Prémont wrote:
>>> Your best solution is probably to write an EDID blob (or reuse one you find
>>> somewhere) that provides at least one mode matching your TV's native mode
>>> (probably full-HD).
>>>
>>> Google suggested the following document:
>>> http://www.jordansmanuals.com/ServiceManuals%5CLG%5CTV%5CLCD%5C42LB9DF%5C42LB9DF%20Service%20Manual.pdf
>>> which on page 13/14 shows the full EDID blob for the various HDMI outputs of the
>>> TV. You may want to read that document, convert the EDID blobs to 512 bytes binary
>>> files and hell DRM core to use the right one via module/kernel cmdline option:
>>>
>>>    drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
>>> or
>>>    modprobe drm-kms-helper edid_firmware=edid/lg42lb9df.edid
>>>
>>> where
>>>    /lib/firmware/edid/lg42lb9df.edid
>>> is the 512-bytes EDID blob created according to data from above manual.
>>> (note, that will only work for intel, radeon and nouveau drivers but will
>>>    not work for closed drivers of AMD/nVidia)
>>>
>>
>> This certainly looks doable. That firmware file, should it contain all 4
>> tables or just the one for the port I'm connected to? Will it matter what
>> order they were in?
>
> It should contain just the table for the port you're connected to.
> For the HDMI ports the tables are 1024 bytes (e.g. two 512 bytes blocks,
> not just one as I incorrectly wrote above). For the VGA port it's just one
> 512 bytes block.
>
> Oh, and check the exact documentation of edid_firmware parameter as you can
> adjust its value to tell kernel to which connector exactly it applies
> (otherwise it will overwrite the EDID on other ports with working displays!).
>

Hi Bruno,

I've taken the EDID data from that service manual. I've looked at the 
EDID-Howto for how to specify the connector but all I see is:

"An EDID data set will only be used for a particular connector,
  if its name and a colon are prepended to the EDID name."

Where can I find the connector names?

And could I ask if this simple pgm might work to build the file I need?

int32_t main(int argc, char **argv)
{
         FILE *fd;
         const char *path = "/lib/firmware/edid/lg42lb9df.edid";
         const char *mode = "w+";
         uint8_t firmware[1024] = {

                 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x1E, 
0x6D, 0x01, 0x00, 0x01, 0x01, 0x01, 0x01,
                 0x0E, 0x10, 0x01, 0x03, 0x80, 0x73, 0x41, 0x96, 0x0A, 
0xCF, 0x74, 0xA3, 0x57, 0x4C, 0xB0, 0x23,
                 0x09, 0x48, 0x4C, 0xAF, 0xCF, 0x00, 0x31, 0x40, 0x45, 
0x40, 0x61, 0x40, 0x81, 0x80, 0xA9, 0x40,
                 0xD1, 0xC0, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3A, 0x80, 
0x18, 0x71, 0x38, 0x2D, 0x40, 0x58, 0x2C,
                 0x45, 0x00, 0xC4, 0x8E, 0x21, 0x00, 0x00, 0x1E, 0x66, 
0x21, 0x50, 0xB0, 0x51, 0x00, 0x1B, 0x30,
                 0x40, 0x70, 0x36, 0x00, 0xC4, 0x8E, 0x21, 0x00, 0x00, 
0x1E, 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38,
                 0x4B, 0x1F, 0x44, 0x0F, 0x00, 0x0A, 0x20, 0x20, 0x20, 
0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xFC,
                 0x00, 0x4C, 0x47, 0x20, 0x54, 0x56, 0x0A, 0x20, 0x20, 
0x20, 0x20, 0x20, 0x20, 0x20, 0x01, 0x15,

                 0x02, 0x03, 0x1B, 0xF1, 0x4C, 0x20, 0x22, 0x10, 0x1F, 
0x01, 0x02, 0x03, 0x04, 0x05, 0x12, 0x93,
                 0x14, 0x23, 0x15, 0x07, 0x50, 0x65, 0x03, 0x0C, 0x00, 
0x10, 0x00, 0x01, 0x1D, 0x00, 0x72, 0x51,
                 0xD0, 0x1E, 0x20, 0x6E, 0x28, 0x55, 0x00, 0xC4, 0x8E, 
0x21, 0x00, 0x00, 0x1E, 0x01, 0x1D, 0x80,
                 0x18, 0x71, 0x1C, 0x16, 0x20, 0x58, 0x2C, 0x25, 0x00, 
0xC4, 0x8E, 0x21, 0x00, 0x00, 0x9E, 0x8C,
                 0x0A, 0xD0, 0x90, 0x20, 0x40, 0x31, 0x20, 0x0C, 0x40, 
0x55, 0x00, 0x4C, 0x6C, 0x42, 0x00, 0x00,
                 0x18, 0x01, 0x1D, 0x00, 0xBC, 0x52, 0xD0, 0x1E, 0x20, 
0xB8, 0x28, 0x55, 0x40, 0x4C, 0x6C, 0x42,
                 0x00, 0x00, 0x1E, 0x01, 0x1D, 0x80, 0xD0, 0x72, 0x1C, 
0x16, 0x20, 0x10, 0x2C, 0x25, 0x80, 0x4C,
                 0x6C, 0x42, 0x00, 0x00, 0x9E, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xED
         };

         fd = fopen(path, mode);
         if (fd == NULL) {
                 perror("/lib/firmware/edid/lg42lb9df.edid failed: ");
                 return 1;
         }

         fwrite(&firmware, 1024, 1, fd);

         fclose(fd);

         printf("Wrote 1024 bytes of edid data to %s\n", path);

         return 0;
}

Thanks very much
Mark


  reply	other threads:[~2012-10-14 16:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-12 12:54 Intel graphics drm issue? Mark Hounschell
2012-10-12 21:14 ` Bruno Prémont
2012-10-13 18:57   ` Mark Hounschell
2012-10-13 19:17     ` Mark Hounschell
2012-10-14  8:41       ` Bruno Prémont
2012-10-14 10:34         ` Mark Hounschell
2012-10-14 10:52         ` Mark Hounschell
2012-10-14 11:03           ` Bruno Prémont
2012-10-14 16:54             ` Mark Hounschell [this message]
2012-10-14 17:22               ` Bruno Prémont
2012-10-14 18:03                 ` Mark Hounschell
2012-10-14 18:19                   ` Bruno Prémont
2012-10-14 18:57                     ` Mark Hounschell
2012-10-14 20:40                       ` Bruno Prémont
2012-10-15  9:58                         ` Mark Hounschell
2012-10-14  8:58       ` [Intel-gfx] " Daniel Vetter
2012-10-14 10:20         ` Mark Hounschell
2012-10-14 11:26           ` Daniel Vetter
2012-10-14 11:39             ` Mark Hounschell
2012-10-14 14:19             ` Mark Hounschell
2012-10-14 14:40               ` Daniel Vetter
2012-10-14 15:41                 ` Mark Hounschell
2012-10-14 15:53                   ` Daniel Vetter
2012-10-14 15:55                     ` Bruno Prémont
2012-10-14 16:09                       ` Mark Hounschell
2012-10-14 16:13                         ` Mark Hounschell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=507AEE4A.1000907@cfl.rr.com \
    --to=dmarkh@cfl.rr.com \
    --cc=bonbons@linux-vserver.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markh@compro.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox