Present extension changes needed for GL/Vulkan vblank modes

I know, Present was supposed to support all of the GL vblank modes, and it mostly does, except for the most common case... In any case, here's a summary of four presentation modes from Vulkan, how you'd get that with GL and Present and what they mean: Vulkan GL

Re: VK_EXT_aquire_xlib_display and kernel security concerns

Andy Ritger writes: > If the NVIDIA X driver finds an HMD display, it: > > (a) Marks it as disconnected. > (b) Does not make its EDID available to RandR clients. > > So, unless I'm mistaken, RandR clients will see the HMD as an RandR > output. But, perhaps the problem is

Re: VK_EXT_aquire_xlib_display and kernel security concerns

James Jones writes: > However, I think direct enumeration is generally useful functionality, > if nothing else just for things like vkinfo or DRM equivalents. Sure, I've enabled direct enumeration when the process has access to that information from the kernel. Right now,

Re: VK_EXT_aquire_xlib_display and kernel security concerns

On Mon, Oct 16, 2017 at 02:17:27PM -0700, Keith Packard wrote: > > Dave Airlie writes: > > > If they use acquire extensions they get display enumeration, the > > problem is display enumeration before the acquire would need special > > permission elevation. > > And the

Re: VK_EXT_aquire_xlib_display and kernel security concerns

On 10/16/2017 01:33 PM, Dave Airlie wrote: On 17 October 2017 at 06:01, James Jones wrote: On 10/16/2017 12:28 PM, Keith Packard wrote: James Jones writes: I think at a lower level, we have different views of how

Re: VK_EXT_aquire_xlib_display and kernel security concerns

Dave Airlie writes: > If they use acquire extensions they get display enumeration, the > problem is display enumeration before the acquire would need special > permission elevation. And the problem here is that the nVidia driver hides the HMD displays from X, forcing the

Re: VK_EXT_aquire_xlib_display and kernel security concerns

James Jones writes: > Understood. In that case, no displays should be enumerated on the > "rendering hardware" device in Vulkan, unless the driver vendor opts for > heroics. We try to avoid software heroics where possible. > Right, but normal processes don't need the

Re: VK_EXT_aquire_xlib_display and kernel security concerns

On 17 October 2017 at 06:01, James Jones wrote: > On 10/16/2017 12:28 PM, Keith Packard wrote: >> >> James Jones writes: >> >>> I think at a lower level, we have different views of how >>> vkGetPhysicalDeviceDisplayPropertiesKHR/VK_KHR_display works. >>>

Re: VK_EXT_aquire_xlib_display and kernel security concerns

On 10/16/2017 12:28 PM, Keith Packard wrote: James Jones writes: I think at a lower level, we have different views of how vkGetPhysicalDeviceDisplayPropertiesKHR/VK_KHR_display works. vkGetPhysicalDeviceDisplayPropertiesKHR() is suppose to enumerate all the displays on a

Re: VK_EXT_aquire_xlib_display and kernel security concerns

James Jones writes: > I think at a lower level, we have different views of how > vkGetPhysicalDeviceDisplayPropertiesKHR/VK_KHR_display works. > vkGetPhysicalDeviceDisplayPropertiesKHR() is suppose to enumerate all > the displays on a given device. In many devices, the

Re: VK_EXT_aquire_xlib_display and kernel security concerns

On 10/14/2017 02:00 AM, "Keith Packard" wrote: I've implemented this extension in DRM and have run into a conflict between the spec and the Linux architecture. The VkDisplayKHR parameter for VK_EXT_acquire_xlib_display can be found in two different ways: 1) Enumerate displays using

[RFC xserver v4 12/14] glamor: Implement GetSupportedModifiers

Implement function added in DRI3 v1.1. A newest version of libepoxy (>= 1.4.4) is required as earlier versions use a problematic version of Khronos EXT_image_dma_buf_import_modifiers spec. v4: Only send scanout-supported modifiers if flipping is possible Signed-off-by: Louis-Francis

[RFC xserver v4 10/14] modesetting: Check if buffer format is supported when flipping

Add support for 'check_flip2' so that the present core can know why it is impossible to flip in that scenario. The core can then let know the client that the buffer format/modifier is suboptimal. Signed-off-by: Louis-Francis Ratté-Boulianne ---

[RFC presentproto v4 02/14] Add PresentCompleteModeSuboptimalCopy flag for Complete event

If the Complete event has this mode, the client is not using the more optimal format/modifier for the buffer allocation. Its main usage as of now is to allow clients to re-fetch DRI3 format modifiers as some modifiers might allow direct scanout. Signed-off-by: Louis-Francis Ratté-Boulianne

[RFC xserver v4 11/14] glamor: Implement PixmapFromBuffers and BuffersFromPixmap

It relies on GBM >= 17.1.0 where we can import BO with multiple planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER). Signed-off-by: Louis-Francis Ratté-Boulianne --- configure.ac | 4 + glamor/glamor.c | 34 --- glamor/glamor.h

[RFC xserver v4 04/14] present: Send PresentCompleteModeSuboptimalCopy appropriately

Add 'check_flip2' hook for driver to let know the core about why flipping is not possible ('reason'). If it is because of unsupported buffer format/modifier, a PresentCompleteNotify event is sent to the client with the PresentCompleteModeSuboptimalCopy mode. v4: It replaces the old mechanism for

[RFC xserver v4 13/14] glamor: Use gbm_bo_create_with_modifiers for internal pixmap allocation

Using modifier might allow the driver to use a more optimal format (e.g. tiled/compressed). Let's try to use those if possible. Signed-off-by: Louis-Francis Ratté-Boulianne --- glamor/glamor_egl.c | 44 ++-

Re: [RFC v2 08/12] present: Allow present implementations to wait on fences

On Fri, 2017-09-29 at 18:24 +0200, Michel Dänzer wrote: > On 27/09/17 07:19 AM, Louis-Francis Ratté-Boulianne wrote: > > Instead of relying on the present module to wait on in-fences, > > we added some hooks to allow the drivers/hardware to do the work. > > Drivers need to implement can_wait, wait

[RFC xserver v4 09/14] modesetting: Create scanout buffers using supported modifiers

Use most optimal buffer format (e.g. tiled/compressed) available for scanout. v3: Don't use multi-plane modifier to create scanout buffer v4: Add flag to retrieve modifiers set from enabled CRTCs only Signed-off-by: Louis-Francis Ratté-Boulianne ---

[RFC xserver v4 07/14] modesetting: Use atomic modesetting to configure output/CRTCs

To make sure we also use the same primary plane and to avoid mixing uses of two APIs, it is better to always use the atomic modesetting API when possible. Signed-off-by: Louis-Francis Ratté-Boulianne --- hw/xfree86/drivers/modesetting/drmmode_display.c | 402

[RFC xserver v4 05/14] modesetting: Use atomic modesetting API for pageflip if available

In order to flip between compressed and uncompressed buffers - something drmModePageFlip explicitly bans us from doing - we need to port use the atomic modesetting API. It's only 'fake' atomic though given we still commit for each CRTC separately and CRTC and connector properties are not set with

Re: [RFC xserver v3 13/14] present: Send a PresentWindowCrtcNotify event appropriately

Hi, On Fri, 2017-09-29 at 18:45 +0200, Michel Dänzer wrote: > On 27/09/17 07:19 AM, Louis-Francis Ratté-Boulianne wrote: > > When the window has changed CRTC, send the event. > > This doesn't make sense to me I'm afraid. > With the current present implementation, which CRTC is used for >

[RFC xserver v4 00/14] DRI3 v1.1: modifiers and multi-plane

Hello, This is the RFC v4 for DRI3 v1.1 (X11 modifiers and multi-plane). For context, please check previous submissions: https://lists.x.org/archives/xorg-devel/2017-June/053854.html https://lists.x.org/archives/xorg-devel/2017-August/054436.html

[RFC xserver v4 03/14] dri3: Add multi-planar/modifier buffer requests

Initial implementation for DRI3 v1.1. Only the DRI3 implementation is there, backends need to implement the proper hooks. Version is still set to 1.0 so clients shouldn't use the new requests yet. v2: Use depth/bpp instead of DRM formats in requests v3: Remove DMA fence requests from v1.1

[RFC xserver v4 08/14] modesetting: Get supported formats/modifiers for scanout

Retrieve IN_FORMATS property from the plane. It gives the allowed formats and modifiers for BO allocation. Signed-off-by: Louis-Francis Ratté-Boulianne --- configure.ac | 4 + hw/xfree86/drivers/modesetting/drmmode_display.c | 114

[RFC xserver v4 06/14] modesetting: Add support for multi-plane pixmaps when page-flipping

This allows the uses of CCS compressed or tiled pixmaps as BOs when page-flipping. Signed-off-by: Louis-Francis Ratté-Boulianne --- hw/xfree86/drivers/modesetting/drmmode_display.c | 46 hw/xfree86/drivers/modesetting/drmmode_display.h | 4 +++

[RFC dri3proto v4 01/14] Add modifier/multi-plane requests, bump to v1.1

DRI3 version 1.1 adds support for explicit format modifiers, including multi-planar buffers. Signed-off-by: Daniel Stone Signed-off-by: Louis-Francis Ratté-Boulianne --- configure.ac | 2 +- dri3proto.h | 86 -

[RFC xserver v4 14/14] dri3: Enable DRI3 version 1.1

Enable DRI3 v1.1 now that all functions have been implemented and that there is at least one backend implementing the driver hooks (modesetting/glamor). Signed-off-by: Louis-Francis Ratté-Boulianne --- include/protocol-versions.h | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH mga] Fix mga_device_attributes of mgag200eH3.

It was missing value for HAL_chipset. All the following values got shifted by one and so the whole record was garbage. --- Alternatively HAL_chipset could be dropped from everywhere because it does not seem to be used. src/mga_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)