Re: Expose more EDID fields to userspace

2019-01-17 Thread Keith Packard
Stéphane Marchesin writes: > I don't have strong feelings for against this approach, but if we do this, > I think we should ensure we keep providing the original EDID to user space. > The contents of EDIDs have so many implications that even the kernel isn't > always in the best position to decid

Re: Expose more EDID fields to userspace

2019-01-17 Thread Stéphane Marchesin
On Mon, Jan 7, 2019, 09:07 Brian Starkey On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > > Daniel Vetter writes: > > > > > Best to pull in some other compositor people and get them to agree. > From a > > > kernel pov I'm fine with whatever userspace preferes. > > > > Hrm. It woul

Re: Expose more EDID fields to userspace

2019-01-17 Thread Daniel Vetter
On Thu, Jan 17, 2019 at 8:59 PM Alex Deucher wrote: > > On Wed, Jan 16, 2019 at 1:35 PM Pekka Paalanen wrote: > > > > On Mon, 7 Jan 2019 17:07:09 + > > Brian Starkey wrote: > > > > > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > > > > Daniel Vetter writes: > > > > > > > >

Re: Expose more EDID fields to userspace

2019-01-17 Thread Alex Deucher
On Wed, Jan 16, 2019 at 1:35 PM Pekka Paalanen wrote: > > On Mon, 7 Jan 2019 17:07:09 + > Brian Starkey wrote: > > > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > > > Daniel Vetter writes: > > > > > > > Best to pull in some other compositor people and get them to agree. >

Re: Expose more EDID fields to userspace

2019-01-17 Thread Keith Packard
Daniel Vetter writes: > Connector properties are documented here: > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties Cool. Seems like we might want a bit more organization here to make it clear which of these are derived from the connected monitor. It would

Re: Expose more EDID fields to userspace

2019-01-17 Thread Daniel Vetter
On Wed, Jan 16, 2019 at 12:32:58PM -0800, Keith Packard wrote: > Adam Jackson writes: > > > If the kernel wanted to expose its quirks db somehow the library could > > certainly be taught to use it. However there are likely to be quirks > > relevant only to userspace (see below), making the kernel

Re: Expose more EDID fields to userspace

2019-01-16 Thread Keith Packard
Adam Jackson writes: > If the kernel wanted to expose its quirks db somehow the library could > certainly be taught to use it. However there are likely to be quirks > relevant only to userspace (see below), making the kernel carry that > doesn't make a ton of sense. We do expose some of the quir

Re: Expose more EDID fields to userspace

2019-01-16 Thread Adam Jackson
On Wed, 2019-01-16 at 20:35 +0200, Pekka Paalanen wrote: > I would agree with an effort to establish a userspace EDID parsing > library in any case. As mentioned above, there will probably be too > much to expose via kernel UABI, or it will become just another > encoded format that again should ha

Re: Expose more EDID fields to userspace

2019-01-16 Thread Ville Syrjälä
On Wed, Jan 16, 2019 at 08:35:26PM +0200, Pekka Paalanen wrote: > On Mon, 7 Jan 2019 17:07:09 + > Brian Starkey wrote: > > > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > > > Daniel Vetter writes: > > > > > > > Best to pull in some other compositor people and get them t

Re: Expose more EDID fields to userspace

2019-01-16 Thread Pekka Paalanen
On Mon, 7 Jan 2019 17:07:09 + Brian Starkey wrote: > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > > Daniel Vetter writes: > > > > > Best to pull in some other compositor people and get them to agree. From a > > > kernel pov I'm fine with whatever userspace preferes.

Re: Expose more EDID fields to userspace

2019-01-07 Thread Brian Starkey
On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > Daniel Vetter writes: > > > Best to pull in some other compositor people and get them to agree. From a > > kernel pov I'm fine with whatever userspace preferes. > > Hrm. It would be good to have everyone using the same interpretati

Re: Expose more EDID fields to userspace

2019-01-07 Thread Keith Packard
Daniel Vetter writes: > Best to pull in some other compositor people and get them to agree. From a > kernel pov I'm fine with whatever userspace preferes. Hrm. It would be good to have everyone using the same interpretation of EDID data; in particular, where the kernel has quirks that change the

Re: Expose more EDID fields to userspace

2019-01-07 Thread Daniel Vetter
On Mon, Dec 31, 2018 at 12:57:24PM +, Simon Ser wrote: > On Monday, December 24, 2018 11:23 AM, Daniel Vetter wrote: > > On Sun, Dec 23, 2018 at 09:16:13AM +, Simon Ser wrote: > > > > > Hi all, > > > Right now, the kernel parses EDIDs and exposes some of the data to > > > userspace. For in

Re: Expose more EDID fields to userspace

2018-12-31 Thread Simon Ser
On Monday, December 24, 2018 11:23 AM, Daniel Vetter wrote: > On Sun, Dec 23, 2018 at 09:16:13AM +, Simon Ser wrote: > > > Hi all, > > Right now, the kernel parses EDIDs and exposes some of the data to > > userspace. For instance, drmModeConnector has mm{Width,Height} and > > subpixel. > > Gen

Re: Expose more EDID fields to userspace

2018-12-24 Thread Daniel Vetter
On Sun, Dec 23, 2018 at 09:16:13AM +, Simon Ser wrote: > Hi all, > > Right now, the kernel parses EDIDs and exposes some of the data to > userspace. For instance, drmModeConnector has mm{Width,Height} and > subpixel. > > Generally, userspace also has another EDID parser. For instance, > wlroo

Expose more EDID fields to userspace

2018-12-23 Thread Simon Ser
Hi all, Right now, the kernel parses EDIDs and exposes some of the data to userspace. For instance, drmModeConnector has mm{Width,Height} and subpixel. Generally, userspace also has another EDID parser. For instance, wlroots uses it just to get the make/model/serial. I've talked about this at XDC