"Mao, David" writes:
> Hi Keith,
> If I read the patch correctly, the plane has been interpreted as the same as
> connector, and the stackIndex is the index of connector of current device.
> Is it by intentional?
> If the hardware don't have underlay/overlay supported, is it better to
> always r
Hi Keith,
If I read the patch correctly, the plane has been interpreted as the same as
connector, and the stackIndex is the index of connector of current device.
Is it by intentional?
If the hardware don't have underlay/overlay supported, is it better to always
report plane 0 rather than pretend
Jason Ekstrand writes:
> On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard wrote:
>
> Once we're sure that's what we want, create an MR against the spec that
> just adds enough to the XML to reserve your extension number. That will
> get merged almost immediately. Then make a second one with the
On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > I think I like option 1 (KEITHP_kms_display). If the client knows the
> > difference between render and primary for 2, then they are most likely
> > already opening the master node themselves or at least have a
Jason Ekstrand writes:
> I think I like option 1 (KEITHP_kms_display). If the client knows the
> difference between render and primary for 2, then they are most likely
> already opening the master node themselves or at least have access to
> the FD.
Ok, I'll work on cleaning up that extension a
On Thu, Feb 15, 2018 at 9:46 AM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > It seems a little odd to me to default to opening the master node and
> then
> > fall back to the render node if it doesn't work. I suppose that's
> probably
> > ok so long as we ensure that vkGetPhysicalDevice
Jason Ekstrand writes:
> It seems a little odd to me to default to opening the master node and then
> fall back to the render node if it doesn't work. I suppose that's probably
> ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR
> returns no displays if we're on the render nod
Eric Engestrom writes:
> copy/paste error: s/drm/display/
That's actually intentional -- any system which supports 'drm' can
support the display backend as it's based on that. Maybe it should use a
different test? (note that I haven't been using the autotools backend
recently, so it may not be g
On Friday, 2018-02-09 20:45:10 -0800, Keith Packard wrote:
> This adds support for the KHR_display extension to the anv and radv
> Vulkan drivers. The drivers now attempt to open the master DRM node
> when the KHR_display extension is requested so that the common winsys
> code can perform the neces
