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
next prev parent reply other threads:[~2012-10-14 16:54 UTC|newest]
Thread overview: 32+ 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 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 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:19 ` Bruno Prémont
2012-10-14 18:57 ` Mark Hounschell
2012-10-14 20:40 ` Bruno Prémont
2012-10-14 20:40 ` Bruno Prémont
2012-10-15 9:58 ` Mark Hounschell
2012-10-14 8:58 ` Daniel Vetter
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:26 ` [Intel-gfx] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.