* Re: [PATCH 0/5] Fixes and additions to EDID generation [not found] <20181113171053.is24iz65egl22aw7@xylophone.i.decadent.org.uk> @ 2018-11-14 10:49 ` Jani Nikula 2018-11-21 9:35 ` Daniel Vetter 0 siblings, 1 reply; 3+ messages in thread From: Jani Nikula @ 2018-11-14 10:49 UTC (permalink / raw) To: Ben Hutchings, dri-devel; +Cc: linux-doc, Jonathan Corbet, Dave Airlie, C.Emde On Tue, 13 Nov 2018, Ben Hutchings <ben.hutchings@codethink.co.uk> wrote: > This series adds two more EDIDs that I needed for a project some time ago, > and fixes some problems that I found along the way. See also [1]. The patches there have been applied via the linux-doc tree. > There isn't a listed maintainer for Documentation/EDID but it looks > like it falls under the DRM umbrella. Please let me know if this the > wrong place. Cc: linux-doc, Jon and Dave. The Documentation/EDID directory was merged by Dave along with the EDID firmware loader mechanism in da0df92b5731 ("drm: allow loading an EDID as firmware to override broken monitor"). I think it would be reasonable to handle the EDID stuff via dri-devel and the drm trees, and modify MAINTAINERS to reflect that. Thoughts? (And in the long run we should use or write a tool to generate EDIDs instead of using assembly with macros. And like Jon already mentioned in the other thread, even the assembly probably shouldn't be under Documentation. But I digress.) BR, Jani. [1] http://mid.mail-archive.com/1541407715-5417-1-git-send-email-cniedermaier@dh-electronics.de > > Ben. > > Ben Hutchings (5): > drm: EDID: Remove a mess involving the number 63 > drm: EDID: Fix bit masking of {X,Y}{OFFSET,PULSE} > drm: EDID: Don't force make to be silent > drm: EDID: Add a 1280x720 (720p) EDID > drm: EDID: Add a 1280x768 ("WXGA") EDID > > Documentation/EDID/1024x768.S | 4 ++-- > Documentation/EDID/1280x1024.S | 4 ++-- > Documentation/EDID/1280x720.S | 45 ++++++++++++++++++++++++++++++++++++++++++ > Documentation/EDID/1280x768.S | 45 ++++++++++++++++++++++++++++++++++++++++++ > Documentation/EDID/1600x1200.S | 4 ++-- > Documentation/EDID/1680x1050.S | 4 ++-- > Documentation/EDID/1920x1080.S | 4 ++-- > Documentation/EDID/800x600.S | 4 ++-- > Documentation/EDID/HOWTO.txt | 4 ++-- > Documentation/EDID/Makefile | 12 +++++------ > Documentation/EDID/edid.S | 10 ++++------ > 11 files changed, 114 insertions(+), 26 deletions(-) > create mode 100644 Documentation/EDID/1280x720.S > create mode 100644 Documentation/EDID/1280x768.S -- Jani Nikula, Intel Open Source Graphics Center ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/5] Fixes and additions to EDID generation 2018-11-14 10:49 ` [PATCH 0/5] Fixes and additions to EDID generation Jani Nikula @ 2018-11-21 9:35 ` Daniel Vetter 2018-11-21 13:36 ` Gerd Hoffmann 0 siblings, 1 reply; 3+ messages in thread From: Daniel Vetter @ 2018-11-21 9:35 UTC (permalink / raw) To: Jani Nikula Cc: Ben Hutchings, dri-devel, linux-doc, Jonathan Corbet, Dave Airlie, C.Emde On Wed, Nov 14, 2018 at 12:49:11PM +0200, Jani Nikula wrote: > On Tue, 13 Nov 2018, Ben Hutchings <ben.hutchings@codethink.co.uk> wrote: > > This series adds two more EDIDs that I needed for a project some time ago, > > and fixes some problems that I found along the way. > > See also [1]. The patches there have been applied via the linux-doc > tree. > > > There isn't a listed maintainer for Documentation/EDID but it looks > > like it falls under the DRM umbrella. Please let me know if this the > > wrong place. > > Cc: linux-doc, Jon and Dave. > > The Documentation/EDID directory was merged by Dave along with the EDID > firmware loader mechanism in da0df92b5731 ("drm: allow loading an EDID > as firmware to override broken monitor"). > > I think it would be reasonable to handle the EDID stuff via dri-devel > and the drm trees, and modify MAINTAINERS to reflect that. Thoughts? > > (And in the long run we should use or write a tool to generate EDIDs > instead of using assembly with macros. And like Jon already mentioned in > the other thread, even the assembly probably shouldn't be under > Documentation. But I digress.) If we do that, maybe stuff the EDID things into Documentation/gpu? Would need an ack from media folks I think, but imo would make sense. -Daniel > > > BR, > Jani. > > [1] http://mid.mail-archive.com/1541407715-5417-1-git-send-email-cniedermaier@dh-electronics.de > > > > > Ben. > > > > Ben Hutchings (5): > > drm: EDID: Remove a mess involving the number 63 > > drm: EDID: Fix bit masking of {X,Y}{OFFSET,PULSE} > > drm: EDID: Don't force make to be silent > > drm: EDID: Add a 1280x720 (720p) EDID > > drm: EDID: Add a 1280x768 ("WXGA") EDID > > > > Documentation/EDID/1024x768.S | 4 ++-- > > Documentation/EDID/1280x1024.S | 4 ++-- > > Documentation/EDID/1280x720.S | 45 ++++++++++++++++++++++++++++++++++++++++++ > > Documentation/EDID/1280x768.S | 45 ++++++++++++++++++++++++++++++++++++++++++ > > Documentation/EDID/1600x1200.S | 4 ++-- > > Documentation/EDID/1680x1050.S | 4 ++-- > > Documentation/EDID/1920x1080.S | 4 ++-- > > Documentation/EDID/800x600.S | 4 ++-- > > Documentation/EDID/HOWTO.txt | 4 ++-- > > Documentation/EDID/Makefile | 12 +++++------ > > Documentation/EDID/edid.S | 10 ++++------ > > 11 files changed, 114 insertions(+), 26 deletions(-) > > create mode 100644 Documentation/EDID/1280x720.S > > create mode 100644 Documentation/EDID/1280x768.S > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/5] Fixes and additions to EDID generation 2018-11-21 9:35 ` Daniel Vetter @ 2018-11-21 13:36 ` Gerd Hoffmann 0 siblings, 0 replies; 3+ messages in thread From: Gerd Hoffmann @ 2018-11-21 13:36 UTC (permalink / raw) To: Daniel Vetter Cc: Jani Nikula, Ben Hutchings, Jonathan Corbet, linux-doc, dri-devel, Dave Airlie Hi, > > (And in the long run we should use or write a tool to generate EDIDs > > instead of using assembly with macros. And like Jon already mentioned in > > the other thread, even the assembly probably shouldn't be under > > Documentation. But I digress.) > > If we do that, maybe stuff the EDID things into Documentation/gpu? Would > need an ack from media folks I think, but imo would make sense. Oh, btw: I've written a edid generator for qemu for the virtual display devices, and I've also added a small test tool so you don't have to boot a virtual machine to test the thing. Will ship with the upcoming qemu 3.1 release. You might find this useful ... cheers, Gerd ============================== cut here ============================== # qemu-edid -h This is a test tool for the qemu edid generator. Typically you'll pipe the output into edid-decode to check if the generator works correctly. usage: qemu-edid <options> options: -h print this text -o <file> set output file (stdout by default) -v <vendor> set monitor vendor (three letters) -n <name> set monitor name -s <serial> set monitor serial -d <dpi> set display resolution -x <prefx> set preferred width -y <prefy> set preferred height -X <maxx> set maximum width -Y <maxy> set maximum height # qemu-edid | edid-decode Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 49 14 34 12 00 00 00 00 2a 18 version: 01 04 basic params: a5 28 1e 78 06 chroma info: ee 91 a3 54 4c 99 26 0f 50 54 established: 21 08 00 standard: e1 c0 d1 c0 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 25 20 00 66 41 00 1a 30 00 1e 33 40 93 2e 11 00 00 18 descriptor 2: 00 00 00 fd 00 32 7d 1e a0 78 01 0a 20 20 20 20 20 20 descriptor 3: 00 00 00 fc 00 51 45 4d 55 20 4d 6f 6e 69 74 6f 72 0a descriptor 4: 00 00 00 f7 00 0a 00 4a a2 24 29 20 00 00 00 00 00 00 extensions: 01 checksum: 19 Manufacturer: RHT Model 1234 Serial Number 0 Made week 42 of 2014 EDID version: 1.4 Digital display 8 bits per primary color channel DisplayPort interface Maximum image size: 40 cm x 30 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 Default (sRGB) color space is primary color space First detailed timing is preferred timing Established timings supported: 640x480@60Hz 800x600@60Hz 1024x768@60Hz Standard timings supported: 2048x1152@60Hz 1920x1080@60Hz Detailed mode: Clock 82.290 MHz, 403 mm x 302 mm 1024 1280 1310 1382 hborder 0 768 771 774 794 vborder 0 -hsync -vsync Monitor ranges (bare limits): 50-125Hz V, 30-160kHz H, max dotclock 1200MHz Monitor name: QEMU Monitor Established timings III Has 1 extension blocks Checksum: 0x19 (valid) CEA extension block Extension version: 3 6 bytes of CEA data Video data block VIC 125 Unknown mode VIC 101 4096x2160@50Hz VIC 96 3840x2160@50Hz VIC 89 2560x1080@50Hz VIC 31 1920x1080@50Hz 0 native detailed modes Checksum: 0xf2 (valid) ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-11-21 13:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20181113171053.is24iz65egl22aw7@xylophone.i.decadent.org.uk>
2018-11-14 10:49 ` [PATCH 0/5] Fixes and additions to EDID generation Jani Nikula
2018-11-21 9:35 ` Daniel Vetter
2018-11-21 13:36 ` Gerd Hoffmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).