RE: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

"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

RE: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

;; dri-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 reques

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [Mesa-dev] [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [Mesa-dev] [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

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

[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 code can perform the necessary operations. Signed-off-by: Keith Packard