"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
devel@lists.freedesktop.org
Subject: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM
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
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
Emil Velikov writes:
> A few top level comments:
Thanks much for looking over this code. I realize it's a large amount of
change and hence more work to review.
> - using card/primary node and (missing) authentication
> Current code opens the primary node when VK_KHR_display is available.
> Thu
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
Hi Keith,
A few top level comments:
- using card/primary node and (missing) authentication
Current code opens the primary node when VK_KHR_display is available.
Thus running a platform=drm,x11,wayland build will fail, as the client
is not authenticated with the X/WL server.
- reuse "drm" as a
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
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 necessary operations.
Signed-off-by: Keith Packard
---
configure.ac
12 matches
Mail list logo