From: Daniel Vetter <daniel@ffwll.ch>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>,
dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org,
Jonathan Corbet <corbet@lwn.net>,
Dave Airlie <airlied@redhat.com>,
C.Emde@osadl.org
Subject: Re: [PATCH 0/5] Fixes and additions to EDID generation
Date: Wed, 21 Nov 2018 10:35:30 +0100 [thread overview]
Message-ID: <20181121093530.GL4266@phenom.ffwll.local> (raw)
In-Reply-To: <8736s4j5nc.fsf@intel.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, dri-devel@lists.freedesktop.org,
Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH 0/5] Fixes and additions to EDID generation
Date: Wed, 21 Nov 2018 10:35:30 +0100 [thread overview]
Message-ID: <20181121093530.GL4266@phenom.ffwll.local> (raw)
In-Reply-To: <8736s4j5nc.fsf@intel.com>
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-11-21 9:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 17:10 [PATCH 0/5] Fixes and additions to EDID generation Ben Hutchings
2018-11-13 17:11 ` [PATCH 1/5] drm: EDID: Remove a mess involving the number 63 Ben Hutchings
2018-11-13 17:12 ` [PATCH 2/5] drm: EDID: Fix bit masking of {X,Y}{OFFSET,PULSE} Ben Hutchings
2018-11-13 17:12 ` [PATCH 3/5] drm: EDID: Don't force make to be silent Ben Hutchings
2018-11-13 17:12 ` [PATCH 4/5] drm: EDID: Add a 1280x720 (720p) EDID Ben Hutchings
2018-11-13 17:12 ` [PATCH 5/5] drm: EDID: Add a 1280x768 ("WXGA") EDID Ben Hutchings
2018-11-14 10:49 ` [PATCH 0/5] Fixes and additions to EDID generation Jani Nikula
2018-11-14 10:49 ` Jani Nikula
2018-11-21 9:35 ` Daniel Vetter [this message]
2018-11-21 9:35 ` Daniel Vetter
2018-11-21 13:36 ` Gerd Hoffmann
2018-11-21 13:36 ` Gerd Hoffmann
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=20181121093530.GL4266@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=C.Emde@osadl.org \
--cc=airlied@redhat.com \
--cc=ben.hutchings@codethink.co.uk \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
/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.