dri-devel October 2018

dri-devel@lists.freedesktop.org

277 participants
1898 discussions

[Bug 108110] hades canyon can not wake from dpms on mDP
by bugzilla-daemon＠freedesktop.org 03 Oct '18

03 Oct '18

1 0

[PULL] drm-intel-fixes
by Rodrigo Vivi 03 Oct '18

03 Oct '18

Hi Dave, Here goes drm-intel-fixes-2018-10-03: There's one fix for our zlib incomlete Z_FINISH on our error state handling, plus a compilation warning fix and a tiny code clean up. Thanks, Rodrigo. The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-10-03 for you to fetch changes up to 4c9613ce556fdeb671e779668b627ea3a2b61728: drm/i915: Handle incomplete Z_FINISH for compressed error states (2018-10-03 08:02:42 -0700) ---------------------------------------------------------------- There's one fix for our zlib incomlete Z_FINISH on our error state handling , plus a compilation warning fix and a tiny code clean up. ---------------------------------------------------------------- Anusha Srivatsa (1): drm/i915: Do not redefine the has_csr parameter. Chris Wilson (2): drm/i915: Avoid compiler warning for maybe unused gu_misc_iir drm/i915: Handle incomplete Z_FINISH for compressed error states drivers/gpu/drm/i915/i915_gpu_error.c | 88 +++++++++++++++++++++++++---------- drivers/gpu/drm/i915/i915_gpu_error.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 33 +++++-------- drivers/gpu/drm/i915/i915_pci.c | 1 - 4 files changed, 76 insertions(+), 47 deletions(-)

1 0

[PULL] drm-misc-next-fixes for 4.20
by Sean Paul 03 Oct '18

03 Oct '18

Hi Dave, We've cut over to misc-next-fixes for 4.20, so just one patch this week. It's Neil's fix for mali binary driver. drm-misc-next-fixes-2018-10-03: - Add EXPERT config option to allow phys mem leak from fbdev for blob drivers (Neil) Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cheers, Sean The following changes since commit 87c2ee740c07f1edae9eec8bc45cb9b32a68f323: Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-09-28 09:48:40 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-10-03 for you to fetch changes up to 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a: drm/fb_helper: Allow leaking fbdev smem_start (2018-10-03 21:08:21 +0200) ---------------------------------------------------------------- - Add EXPERT config option to allow phys mem leak from fbdev for blob drivers (Neil) Cc: Neil Armstrong <narmstrong(a)baylibre.com> ---------------------------------------------------------------- Neil Armstrong (1): drm/fb_helper: Allow leaking fbdev smem_start drivers/gpu/drm/Kconfig | 20 ++++++++++++++++++++ drivers/gpu/drm/drm_fb_helper.c | 33 +++++++++++++++++++++++++++++++-- 2 files changed, 51 insertions(+), 2 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS

1 0

[PATCH v2] drm/fb_helper: Allow leaking fbdev smem_start
by Neil Armstrong 03 Oct '18

03 Oct '18

Since "drm/fb: Stop leaking physical address", the default behaviour of the DRM fbdev emulation is to set the smem_base to 0 and pass the new FBINFO_HIDE_SMEM_START flag. The main reason is to avoid leaking physical addresse to user-space, and it follows a general move over the kernel code to avoid user-space to manipulate physical addresses and then use some other mechanisms like dma-buf to transfer physical buffer handles over multiple subsystems. But, a lot of devices depends on closed sources binaries to enable OpenGL hardware acceleration that uses this smem_start value to pass physical addresses to out-of-tree modules in order to render into these physical adresses. These should use dma-buf buffers allocated from the DRM display device instead and stop relying on fbdev overallocation to gather DMA memory (some HW vendors delivers GBM and Wayland capable binaries, but older unsupported devices won't have these new binaries and are doomed until an Open Source solution like Lima finalizes). Since these devices heavily depends on this kind of software and because the smem_start population was available for years, it's a breakage to stop leaking smem_start without any alternative solutions. This patch adds a Kconfig depending on the EXPERT config and an unsafe kernel module parameter tainting the kernel when enabled. A clear comment and Kconfig help text was added to clarify why and when this patch should be reverted, but in the meantime it's a necessary feature to keep. Cc: Dave Airlie <airlied(a)gmail.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Cc: Noralf Trønnes <noralf(a)tronnes.org> Cc: Maxime Ripard <maxime.ripard(a)bootlin.com> Cc: Eric Anholt <eric(a)anholt.net> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Ben Skeggs <skeggsb(a)gmail.com> Cc: Christian König <christian.koenig(a)amd.com> Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> Reviewed-by: Maxime Ripard <maxime.ripard(a)bootlin.com> Tested-by: Maxime Ripard <maxime.ripard(a)bootlin.com> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/Kconfig | 20 ++++++++++++++++++++ drivers/gpu/drm/drm_fb_helper.c | 33 +++++++++++++++++++++++++++++++-- 2 files changed, 51 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 8871b3f..0b4067f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -110,6 +110,26 @@ config DRM_FBDEV_OVERALLOC is 100. Typical values for double buffering will be 200, triple buffering 300. +config DRM_FBDEV_LEAK_PHYS_SMEM + bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)" + depends on DRM_FBDEV_EMULATION && EXPERT + default n + help + In order to keep user-space compatibility, we want in certain + use-cases to keep leaking the fbdev physical address to the + user-space program handling the fbdev buffer. + This affects, not only, Amlogic, Allwinner or Rockchip devices + with ARM Mali GPUs using an userspace Blob. + This option is not supported by upstream developers and should be + removed as soon as possible and be considered as a broken and + legacy behaviour from a modern fbdev device driver. + + Please send any bug reports when using this to your proprietary + software vendor that requires this. + + If in doubt, say "N" or spread the word to your closed source + library vendor. + config DRM_LOAD_EDID_FIRMWARE bool "Allow to specify an EDID data set instead of probing for it" depends on DRM diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index bf2190c..61a0d2b 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -56,6 +56,25 @@ MODULE_PARM_DESC(drm_fbdev_overalloc, "Overallocation of the fbdev buffer (%) [default=" __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]"); +/* + * In order to keep user-space compatibility, we want in certain use-cases + * to keep leaking the fbdev physical address to the user-space program + * handling the fbdev buffer. + * This is a bad habit essentially kept into closed source opengl driver + * that should really be moved into open-source upstream projects instead + * of using legacy physical addresses in user space to communicate with + * other out-of-tree kernel modules. + * + * This module_param *should* be removed as soon as possible and be + * considered as a broken and legacy behaviour from a modern fbdev device. + */ +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) +static bool drm_leak_fbdev_smem = false; +module_param_unsafe(drm_leak_fbdev_smem, bool, 0600); +MODULE_PARM_DESC(fbdev_emulation, + "Allow unsafe leaking fbdev physical smem address [default=false]"); +#endif + static LIST_HEAD(kernel_fb_helper_list); static DEFINE_MUTEX(kernel_fb_helper_lock); @@ -2673,8 +2692,12 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper, info = fb_helper->fbdev; info->var.pixclock = 0; - /* don't leak any physical addresses to userspace */ - info->flags |= FBINFO_HIDE_SMEM_START; + /* Shamelessly allow physical address leaking to userspace */ +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) + if (!drm_leak_fbdev_smem) +#endif + /* don't leak any physical addresses to userspace */ + info->flags |= FBINFO_HIDE_SMEM_START; /* Need to drop locks to avoid recursive deadlock in * register_framebuffer. This is ok because the only thing left to do is @@ -3084,6 +3107,12 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper, fbi->screen_size = fb->height * fb->pitches[0]; fbi->fix.smem_len = fbi->screen_size; fbi->screen_buffer = buffer->vaddr; + /* Shamelessly leak the physical address to user-space */ +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) + if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0) + fbi->fix.smem_start = + page_to_phys(virt_to_page(fbi->screen_buffer)); +#endif strcpy(fbi->fix.id, "DRM emulated"); drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth); -- 2.7.4

1 1

[PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
by Juha-Pekka Heikkila 03 Oct '18

03 Oct '18

Add P010 definition, semi-planar yuv format where each component is 16 bits 10 msb containing color value. First come Y plane [10:6] followed by 2x2 subsampled Cr:Cb plane [10:6:10:6] Add P012 definition, semi-planar yuv format where each component is 16 bits 12 msb containing color value. First come Y plane [12:4] followed by 2x2 subsampled Cr:Cb plane [12:4:12:4] Add P016 definition, semi-planar yuv format where each component is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb plane [16:16] Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila(a)gmail.com> --- drivers/gpu/drm/drm_fourcc.c | 3 +++ include/uapi/drm/drm_fourcc.h | 10 ++++++++++ 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 35c1e27..32e07a2 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32 format) { .format = DRM_FORMAT_UYVY, .depth = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true }, { .format = DRM_FORMAT_VYUY, .depth = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true }, { .format = DRM_FORMAT_AYUV, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, .is_yuv = true }, + { .format = DRM_FORMAT_P010, .depth = 0, .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true }, + { .format = DRM_FORMAT_P012, .depth = 0, .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true }, + { .format = DRM_FORMAT_P016, .depth = 0, .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true }, }; unsigned int i; diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 2ed46e9..daaabb1 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -178,6 +178,16 @@ extern "C" { #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */ /* + * 2 plane YCbCr + * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate + * component xxx msb Y [xxx:16-xxx] + * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian [xxx:16-xxx:xxx:16-xxx] + */ +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane, 10 bit per channel */ +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2 subsampled Cr:Cb plane, 12 bit per channel */ +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2 subsampled Cr:Cb plane, 16 bit per channel */ + +/* * 3 plane YCbCr * index 0: Y plane, [7:0] Y * index 1: Cb plane, [7:0] Cb -- 2.7.4

5 10

[PATCH] drm/vkms: Extend todo
by Daniel Vetter 03 Oct '18

03 Oct '18

Typed up all the items Rodrigo capture at the vkms workshop at xdc2018: https://etherpad.net/p/vkms_todo v2: Review from Rodrigo. - Add eBPF for atomic check, I forgot it. - Improve spelling. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Sean Paul <sean(a)poorly.run> Cc: Haneen Mohammed <hamohammed.sa(a)gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> --- Documentation/gpu/vkms.rst | 101 ++++++++++++++++++++++++++++++++++++- 1 file changed, 99 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..7dfc349a4508 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO ==== -CRC API -------- +CRC API Improvements +-------------------- - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` @@ -22,3 +22,100 @@ CRC API - Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes). + +Vblank issues +------------- + +Some IGT test cases are failing. Need to analyze why and fix the issues: + +- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible + +Runtime Configuration +--------------------- + +We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases: + +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of + compositors). + +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of + them first). + +- Change output configuration: Plug/unplug screens, change EDID, allow changing + the refresh rate. + +The currently proposed solution is to expose vkms configuration through +configfs. All existing module options should be supported through configfs too. + +Add Plane Features +------------------ + +There's lots of plane features we could add support for: + +- Real overlay planes, not just cursor. + +- Full alpha blending on all planes. + +- Rotation, scaling. + +- Additional buffer formats, especially YUV formats for video like NV12. + Low/high bpp RGB formats would also be interesting. + +- Async updates (currently only possible on cursor plane using the legacy cursor + api). + +For all of these, we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms. + +Writeback support +----------------- + +Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as: + +- Writeback connector. This is useful for testing compositors if you don't have + hardware with writeback support. + +- As a v4l device. This is useful for debugging compositors on special vkms + configurations, so that developers see what's really going on. + +Prime Buffer Sharing +-------------------- + +We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers. + +Output Features +--------------- + +- Variable refresh rate/freesync support. This probably needs prime buffer + sharing support, so that we can use vgem fences to simulate rendering in + testing. Also needs support to specify the EDID. + +- Add support for link status, so that compositors can validate their runtime + fallbacks when e.g. a Display Port link goes bad. + +- All the hotplug handling describe under "Runtime Configuration". + +Atomic Check using eBPF +----------------------- + +Atomic drivers have lots of restrictions which are not exposed to userspace in +any explicit form through e.g. possible property values. Userspace can only +inquiry about these limits through the atomic IOCTL, possibly using the +TEST_ONLY flag. Trying to add configurable code for all these limits, to allow +compositors to be tested against them, would be rather futile exercise. Instead +we could add support for eBPF to validate any kind of atomic state, and +implement a library of different restrictions. + +This needs a bunch of features (plane compositing, multiple outputs, ...) +enabled already to make sense. -- 2.19.0.rc2

3 2

[Bug 201163] New: amdgpu: carrizo: Stalls using vaapi encoder
by bugzilla-daemon＠bugzilla.kernel.org 03 Oct '18

03 Oct '18

https://bugzilla.kernel.org/show_bug.cgi?id=201163 Bug ID: 201163 Summary: amdgpu: carrizo: Stalls using vaapi encoder Product: Drivers Version: 2.5 Kernel Version: 4.18.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: ricardo.ribalda(a)gmail.com Regression: No Created attachment 278595 --> https://bugzilla.kernel.org/attachment.cgi?id=278595&action=edit glxinfo This command: gst-launch-1.0 v4l2src io-mode=4 ! vaapih264enc ! fakesink dump=1 results in a stall non recoverable using ctrl+c and the following kernel message [ 1617.944590] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vce0 timeout, last signaled seq=4, last emitted seq=6 [ 1617.944628] [drm] IP block:vce_v3_0 is hung! [ 1617.944632] [drm] GPU recovery disabled. -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[PATCH] drm: fb-helper: Validate requested pixel format against bpp
by Eugeniy Paltsev 03 Oct '18

03 Oct '18

Validate requested pixel format against bits_per_pixel to reject invalid formats with subcomponents length sum is greater than requested bits_per_pixel. weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel format without bits_per_pixel updating. So it can request x8r8g8b8 with 16 bpp which is obviously incorrect and should be rejected. Cc: stable(a)vger.kernel.org Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> --- drivers/gpu/drm/drm_fb_helper.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 16ec93b75dbf..4f39da07f053 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1610,6 +1610,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var, return -EINVAL; } + if ((var->green.length + var->blue.length + var->red.length + + var->transp.length) > var->bits_per_pixel) { + DRM_DEBUG("fb requested pixel format can't fit in %d bpp\n", + var->bits_per_pixel); + return -EINVAL; + } + switch (var->bits_per_pixel) { case 16: depth = (var->green.length == 6) ? 16 : 15; -- 2.14.4

4 5

PCIe P2P access to GPU memory
by Dirk Eibach 03 Oct '18

03 Oct '18

I want to access GPU VRAM via PCIe P2P access, like DirectGMA but with mainline drivers. I can acquire a dmabuf from the GPU and pass it to my PCIe framegrabber. But I don't see a way to get the PCIe bus address of the video memory which I need for the P2P transfer. Is there already any infrastructure in place for doing this? If not, what would be the right way to implement this? Add another callback to the dmabuf struct? Cheers Dirk

6 10

[PATCH] drm/vkms: Extend todo
by Daniel Vetter 03 Oct '18

03 Oct '18

Typed up all the items Rodrigo capture at the vkms workshop at xdc2018: https://etherpad.net/p/vkms_todo Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Sean Paul <sean(a)poorly.run> Cc: Haneen Mohammed <hamohammed.sa(a)gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> --- Documentation/gpu/vkms.rst | 87 +++++++++++++++++++++++++++++++++++++- 1 file changed, 85 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..80cbe0759d3c 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO ==== -CRC API -------- +CRC API Improvements +-------------------- - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` @@ -22,3 +22,86 @@ CRC API - Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes). + +Vblank issues +------------- + +Some IGT testcases are failing. Need to analyze why and fix the issues: + +- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible + +Runtime Configuration +--------------------- + +We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases: + +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of + compositors). + +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of + them first). + +- Change output configuration: Plug/unplug screens, change EDID, allow changing + the refresh rate. + +Currently proposed solution is to expose vkms configuration through configfs. +All existing module options should be supported through configfs too. + +Add Plane Features +------------------ + +There's lots of plane features we could add support fort: + +- Real overlay planes, not just cursor. + +- Full alpha blending on all planes. + +- Rotation, scaling. + +- Additional buffer formats, especially YUV formats for video like NV12. + Low/high bpp RGB formats would also be interesting. + +- Async updates (currently only possible on cursor plane using the legacy cursor + api). + +For all of these we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms. + +Writeback support +----------------- + +Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as: + +- Writeback connector. This is useful for testing compositors if you don't have + hardware with writeback support. + +- As a v4l device. This is useful for debugging compositors on special vkms + configurations, so that developers see what's really going on. + +Prime Buffer Sharing +-------------------- + +We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers. + +Output Features +--------------- + +- Variable refresh rate/freesync support. This probably needs prime buffer + sharing support, so that we can use vgem fences to simulate rendering in + testing. Also needs support to specify the EDID. + +- Add support for link status, so that compositors can validate their runtime + fallbacks when e.g. a Display Port link goes bad. + +- All the hotplug handling describe under "Runtime Configuration". -- 2.19.0.rc2

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2018