BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CERN//INDICO//EN
BEGIN:VEVENT
SUMMARY:Handling XR Displays in the Linux Graphics Stack
DTSTART;VALUE=DATE-TIME:20260928T140500Z
DTEND;VALUE=DATE-TIME:20260928T142500Z
DTSTAMP;VALUE=DATE-TIME:20260904T181329Z
UID:indico-contribution-534@indico.freedesktop.org
DESCRIPTION:Speakers: Neil Armstrong (Linaro)\, Nie Jun (Linaro)\nIn the L
 inux DRM subsystem\, an XR device display is currently exposed as a single
 \, aggregated display. However\, treating an XR device like a traditional 
 flat monitor completely breaks the human experience.\n\nPhysically\, an XR
  device consists of two distinct displays (one for each eye). Simply pushi
 ng standard 2D desktop frames to this aggregated screen results in an unvi
 ewable\, disorienting output. To produce an image that a human eye can act
 ually process through the headset's optics\, the output requires heavy GL/
 Vulkan-based transformations. These transformations must account for stere
 oscopic rendering\, lens distortion correction (barrel distortion\, chroma
 tic aberration)\, and the physical focal planes of the hardware.\n\nThis s
 hort talk will outline the disconnect between how DRM sees an XR display a
 nd what the human eye physically needs. The primary goal is to trigger an 
 open discussion on the architectural path forward:\n\n- Should we add spec
 ial properties to such display so traditional DRM clients (fb emulation\, 
 compositor\, ...) avoids considering them as an output ?\n- How should we 
 properly expose the physical lens and plane characteristics of XR hardware
  through DRM?\n- Should the compositor bear the full weight of these rende
 ring transformations\, or is there a better abstraction?\n- How do we stan
 dardize the handling of XR displays across the Linux graphics stack to mak
 e native XR a reality?\n\nhttps://indico.freedesktop.org/event/12/contribu
 tions/534/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/534/
END:VEVENT
END:VCALENDAR