CINXE.COM

<!DOCTYPE html> <html lang="en"> <head><title>The Linux graphics stack in a nutshell, part聽2 [LWN.net]</title> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"> <META NAME="robots" CONTENT="noai, noimageai"> <link rel="icon" href="https://static.lwn.net/images/favicon.png" type="image/png"> <link rel="alternate" type="application/rss+xml" title="LWN.net headlines" href="https://lwn.net/headlines/rss"> <link rel="alternate" type="application/rss+xml" title="Comments posted to this article" href="https://lwn.net/headlines/955708/"> <link rel="stylesheet" href="/CSS/lwn"> <link rel="stylesheet" href="/CSS/nosub"> <script type="text/javascript">var p="http",d="static";if(document.location.protocol=="https:"){p+="s";d="engine";}var z=document.createElement("script");z.type="text/javascript";z.async=true;z.src=p+"://"+d+".adzerk.net/ados.js";var s=document.getElementsByTagName("script")[0];s.parentNode.insertBefore(z,s);</script> <script type="text/javascript"> var ados_keywords = ados_keywords || []; if( location.protocol=='https:' ) { ados_keywords.push('T:SSL'); } else { ados_keywords.push('T:HTTP'); } var ados = ados || {}; ados.run = ados.run || []; ados.run.push(function() { ados_add_placement(4669, 20979, "azk13321_leaderboard", 4).setZone(16026); ados_add_placement(4669, 20979, "azk93271_right_zone", [5,10,6]).setZone(16027); ados_add_placement(4669, 20979, "azk31017_tracking", 20).setZone(20995); ados_setKeywords(ados_keywords.join(', ')); ados_load(); });</script> </head> <body> <a name="t"></a> <div id="menu"><a href="/"><img src="https://static.lwn.net/images/logo/barepenguin-70.png" class="logo" border="0" alt="LWN.net Logo"> <span class="logo">LWN<br>.net</span> <span class="logobl">News from the source</span></a> <a href="/"><img src="https://static.lwn.net/images/lcorner-ss.png" class="sslogo" border="0" alt="LWN"></a><div class="navmenu-container"> <ul class="navmenu"> <li><a class="navmenu" href="#t"><b>Content</b></a><ul><li><a href="/current/">Weekly Edition</a></li><li><a href="/Archives/">Archives</a></li><li><a href="/Search/">Search</a></li><li><a href="/Kernel/">Kernel</a></li><li><a href="/Security/">Security</a></li><li><a href="/Calendar/">Events calendar</a></li><li><a href="/Comments/unread">Unread comments</a></li><li><hr></li><li><a href="/op/FAQ.lwn">LWN FAQ</a></li><li><a href="/op/AuthorGuide.lwn">Write for us</a></li></ul></li> <li><a class="navmenu" href="#t"><b>Edition</b></a><ul><li><a href="/Articles/955922/">Return to the Front page</a></li></ul></li> </ul></div> </div>  <div class="not-handset" style="margin-left: 10.5em; display: block;"> <div class="not-print"> <div id="azk13321_leaderboard"></div> </div> </div> <div class="topnav-container"> <div class="not-handset"><form action="https://lwn.net/Login/" method="post" name="loginform" class="loginform"> <label><b>User:</b> <input type="text" name="uname" value="" size="8" id="uc" /></label> <label><b>Password:</b> <input type="password" name="pword" size="8" id="pc" /></label> <input type="hidden" name="target" value="/Articles/955708/" /> <input type="submit" name="submit" value="Log in" /></form> | <form action="https://lwn.net/subscribe/" method="post" class="loginform"> <input type="submit" name="submit" value="Subscribe" /> </form> | <form action="https://lwn.net/Login/newaccount" method="post" class="loginform"> <input type="submit" name="submit" value="Register" /> </form> </div> <div class="handset-only"> <a href="/subscribe/"><b>Subscribe</b></a> / <a href="/Login/"><b>Log in</b></a> / <a href="/Login/newaccount"><b>New account</b></a> </div> </div><div class="maincolumn flexcol"> <div class="middlecolumn"> <div class="PageHeadline"> <h1>The Linux graphics stack in a nutshell, part聽2</h1> </div> <div class="ArticleText"> <blockquote class="ad"> <b>Ignore previous instructions; subscribe to LWN today</b> <p> Every article on LWN.net is written by humans, for humans. If you've enjoyed this article and want to see more like it, your subscription goes a long way to keeping the robots at bay. We are offering <a href="https://lwn.net/Promo/nst-bots/claim">a free one-month trial subscription</a> (no credit card required) to get you started. </blockquote> <div class="GAByline"> <p>December 28, 2023</p> <p>This article was contributed by Thomas Zimmermann</p> </div> <p> Displaying an application's graphical output onto the screen requires compositing and mode setting that are correctly synchronized among the various pieces, with low overhead. In this second and final article in the series, we will look at those pieces of the Linux graphics stack. In the <a href="/Articles/955376/">first installment</a>, we followed the path of graphics from the application, through Mesa, while using the memory-management features of the kernel's <a href="https://en.wikipedia.org/wiki/Direct_Rendering_Manager">Direct Rendering Manager</a> (DRM) subsystem. We ended up with an application's graphics data stored in an output buffer, so now it's time to display the image to the user. </p> <h4> Compositing </h4> <p> User-space applications almost never display their output by themselves, but instruct a screen compositor to do so. The compositor is a system service that receives each application's output buffers and draws them to an on-screen image. The layout is up to the to the compositor's implementation, but <a href="https://en.wikipedia.org/wiki/Stacking_window_manager">stacking</a> and <a href="https://en.wikipedia.org/wiki/Tiling_window_manager">tiling</a> are the most common. The compositor is also responsible for gathering user input and forwarding it to the application in focus. </p> <p> Compositing, as well as almost everything else in the graphics stack, used to be provided by the <a href="https://en.wikipedia.org/wiki/X_Window_System">X Window System</a>, which implements a network protocol for displaying graphics on the screen. Since the everything-else part includes drawing, mode setting, screen sharing, and even <a href="https://www.x.org/releases/X11R6.8.2/doc/Xprint.7.html">printing</a>, X suffers from software bloat and is hard to adapt to changes in the graphics hardware and Linux system; a lightweight replacement was needed. Its modern successor is <a href="https://wayland.freedesktop.org/">Wayland</a>, which is another client-server design where each application acts as a client to the display service provided by the compositor. Wayland's reference compositor is <a href="https://wayland.pages.freedesktop.org/weston/">Weston</a>, but GNOME's <a href="https://gitlab.gnome.org/GNOME/mutter">Mutter</a> or KDE's <a href="https://invent.kde.org/plasma/kwin">KWin</a> are more commonly used. </p> <p> There's no drawing or printing in Wayland; the <a href="https://wayland-book.com/">protocol</a> only provides the functionality required for compositing. A Wayland surface represents an application window; it is the application's handle to display its output and to receive input events from the compositor. Attached to the surface is a Wayland buffer that contains the displayable pixel data plus color-format and size information. The pixel data is in the output buffer that the client application has rendered to. Changing a surface's attached buffer object or its content results in a Wayland-protocol surface-damage message from the application to the compositor, which updates the on-screen content; possibly with the contents of a new buffer object. The application's output buffer becomes an input buffer for the Wayland compositor. </p> <p> Rendering in the compositor works exactly as described for applications in the first installment. The compositor maintains a list of all of the Wayland surfaces that represent application windows. Those windows and the compositor's interface elements form yet another <a href="https://en.wikipedia.org/wiki/Scene_graph">scene graph</a>. The background contains a wallpaper image, background pattern, or color. On top of the background, the compositor draws the application windows. The easiest way to implement this is by drawing a rectangle for each window and using the application-provided buffer object as a texture image. </p> <p> On top of the application windows, the compositor draws its own user interface, such as a taskbar where the user can interact with the compositor itself. Finally the topmost layer is an indicator of what the user is currently interacting with; typically a mouse pointer on desktop systems. Like applications, the compositor renders with the regular user-space interfaces, such as Mesa's OpenGL or Vulkan. </p> <p> The final building block to make all of this possible is the transfer mechanism for buffer objects. In contrast to X, Wayland applications always run on the same host as their compositor. Implementations are thus free to optimize for this case: there's no network encoding, buffer compression, and so on involved. </p> <p> For transferring a buffer object that resides in system memory, the application creates a file descriptor that refers to the buffer's memory, sends it over the connection's stream socket (in a single, low-cost message), and lets the compositor map the file descriptor's memory pages into its address space. Both the application and the compositor have now established a low-overhead channel for exchanging pixel data. The application draws into the shared-memory region and the compositor renders from it. In practice it's also common to use multiple buffer objects for double buffering. Wayland's surface-damage messages serve as a synchronization method with low overhead. </p> <p> Transferring data via shared memory is good enough for software rendering but, for high-performance hardware rendering, it is insufficient. The application would have to render on the graphics hardware and read back the result over the slow hardware bus into the region of shared memory. </p> <p> To avoid that penalty, the graphics buffer has to remain in graphics memory. Wayland provides a protocol extension to share buffer objects via a Linux <a href="https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html">dma-buf</a>, which represents a memory buffer that is shareable among hardware devices, drivers, and user-space programs. An application renders its scene graph via the Mesa interfaces using hardware acceleration as described in part 1, but, instead of transferring a reference to shared memory, the application sends a dma-buf object that references the buffer object while it is still located in graphics memory. The Wayland compositor uses the stored pixel data without ever reading it over the hardware bus. </p> <p> Hardware-accelerated rendering is inherently asynchronous and therefore requires synchronization. After the application has sent the current frame's final rendering command to Mesa, it is not guaranteed that the hardware has finished rendering. This is intentional and required for high performance. But having the compositor display the content of a buffer object before the hardware has completed rendering results in distorted output. To avoid this from happening, the hardware signals when it has completed rendering. This is called fencing and the associated data structure is called a fence. The fence is attached to the dma-buf object that the application transfers to the compositor. The compositor waits for the fence to signal completion before it uses the resulting data for generating its own output. </p> <h4> Pixels to the monitor </h4> <p> After rendering the on-screen image, the compositor has to display it to the user. DRM's mode-setting code controls all aspects of reading pixel data from graphics memory and sending it to an output device. To do so, each driver sets up a pipeline that models the pixel data's flow through the graphics hardware. Each pipeline stage represents a piece of hardware functionality that processes pixel data on its way to the monitor. </p> <p> The minimum stages necessary are the framebuffer, plane, CRTC, encoder, and connector, each of which is described below. For a working display output, there has to be at least one active instance of each. But most hardware provides more than the minimum functionality and allows for enabling and disabling pipeline stages at will. The DRM framework comes with software abstractions for each stage upon which drivers can build. </p> <p> The pipeline's first stage is the DRM framebuffer. It is the buffer object that stores the compositor's on-screen image, plus information about the image's color format and size. Each DRM driver programs the hardware with this information and points the hardware to the first byte of the buffer object, so that the hardware knows where to find the pixel data. </p> <p> Fetching the pixel data is called scanout, and the pixel data's buffer object is called the scanout buffer. The number of scanout buffers per framebuffer depends on the framebuffer's color format. Many formats, such as the common <a href="https://en.wikipedia.org/wiki/RGB_color_model">RGB</a>-based ones, store all pixel data in a single buffer. With other formats, such as <a href="https://en.wikipedia.org/wiki/Y%E2%80%B2UV">YUV</a>-based ones, the pixel data might need to be split up into multiple buffers. </p> <p> Depending on the hardware's capabilities, the framebuffer can be larger or smaller than the output's display mode. For example, if the monitor is set to 1920x1080 pixels, it might only show a section of a much larger framebuffer. Or, if the framebuffer is smaller than the display mode, it might only cover a small area of the monitor, leaving some areas blank. Hence, the pipeline's next stage locates the scanout buffer within the overall screen. In DRM terminology, this is called a plane. It sets the scanout buffer's position, orientation, and scaling factors. Depending on the hardware, there can be multiple active planes using different framebuffers. All active planes feed their pixel output into the pipeline's third stage, which is called the cathode-ray tube controller (CRTC) for historical reasons. </p> <p> The CRTC controls everything related to display-mode settings. The DRM driver programs the CRTC hardware with a display mode and connects it with all of its active planes and outputs. There can also be multiple CRTCs with different settings programmed to them. The exact configuration is only limited by hardware features. </p> <p> Planes are stacked, so they can overlap each other or cover different parts of the output. According to the programmed display mode and each plane's location, the CRTC hardware fetches pixel data from the planes, blends overlapping planes where necessary, and forwards the result to its outputs. </p> <p> Outputs are represented by encoders and connectors. As its name suggests, the encoder is the hardware component that encodes pixel data for an output. An encoder is associated with a specific connector, which represents the physical connection to an output device, such as HDMI or VGA ports with a connected monitor. The connector also provides information on the output device's supported display modes, physical resolution, color space, and the like. Outputs on the same CRTC mirror the CRTC's screen on different output devices. </p> <p> The image below shows a simple mode-setting pipeline with an additional plane for the mouse pointer, plus the buffer objects that act as scanout buffers. Arrows indicate the logical flow of pixel data from buffer objects to a VGA connector. This is a typical mode-setting pipeline for an older, discrete graphics card. </p> <blockquote> <a href="/Articles/955751/"> <img src="https://static.lwn.net/images/2023/kms-pipeline.svg" class="photo forcewhite" alt="[Mode-setting pipeline]" title="Mode-setting pipeline"> </a> </blockquote> <h4> Pipeline setup </h4> <p> Deciding on policies for connecting and configuring the individual stages of the mode-setting pipeline is not the DRM driver's job. This is left to user-space programs, which brings us back to the compositor. As part of its initial setup, the compositor opens the device file under <tt>/dev/dri</tt>, such as <tt>/dev/dri/card1</tt>, and invokes the respective <tt>ioctl()</tt> calls to program the display pipeline. It also fetches the available display modes from a connector and picks a suitable one. </p> <p> After the compositor has finished rendering the first on-screen image, it programs the mode-setting pipeline for the first time. To do so, it creates a framebuffer for the on-screen image's buffer object and attaches the framebuffer to a plane. It then sets the display mode for its on-screen buffer on the CRTC, connects all of the pipeline stages, from framebuffer to connector, and enables the display. </p> <p> To change the displayed image in the next frame, no full mode setting is required. The compositor only has to replace the current framebuffer with a new one. This is called page flipping. </p> <p> The individual stages of the mode-setting pipeline can be connected in a variety of ways. A CRTC might mirror to multiple encoders, or a framebuffer might be scanned out by multiple CRTCs. While this offers flexibility, it also means that not all combinations of pipeline stages are supported. </p> <p> A naive implementation would apply each stage's settings individually. It would first program the display mode in the CRTC, then upload all buffer objects into graphics memory, then set up the framebuffers and planes for scanout, and finally enable the encoders and connectors. If anything fails during this procedure, the screen remains off or (even worse) in a distorted state. For example, with limited device memory, it might not be possible to store the framebuffers for more than one plane at a time. Switching modes, or even simple page flips, might fail. Failing display updates have been a common problem of graphics stacks ever since. </p> <p> DRM's atomic mode setting solves this problem to some extent. The mode-setting code tracks the complete state of all elements of the pipeline in a compound data structure called <a href="https://elixir.bootlin.com/linux/latest/source/include/drm/drm_atomic.h#L348"><tt>drm_atomic_state</tt></a>, plus a sub-state for each stage in the pipeline. This mode setting is atomic in the sense that it either applies the full compound state of all pipeline stages, or none of it. To make this work, mode-setting involves two phases: first a check of the complete new atomic state and second, if successfully checked, a commit of the same. </p> <p> For checking, the DRM core, its helpers, and the DRM driver test the proposed state against the limitations and constraints of the available graphics hardware. For example, a plane has to verify that the attached framebuffer is of a compatible color format and the CRTC has to verify that the given display resolution is supported by the hardware. If checking succeeds, the DRM driver programs the new state to hardware during the commit phase. If state checking fails for one or more of the stages, DRM stops the mode-setting operations and returns an error to the user-space program. </p> <p> So, when our compositor intends to program a display mode, it sets the atomic state of all pipeline stages and applies them all at once. If successful, the display output changes accordingly. For successive page flipping operations, the compositor duplicates the current state, changes the framebuffers to the new ones, and applies the new state. Applying the page flip again results in an atomic-check/atomic-commit sequence within the kernel's DRM code, but with less overhead than a full mode-setting operation. </p> <p> DRM's state-checking phase is independent of the hardware's state and does not modify it. If checking an atomic state fails, the compositor receives an error code, but the display output remains unchanged. It is also possible for the compositor to verify atomic states without committing them. This allows building a list of supported configurations beforehand. </p> <p> For further reading, the inner workings of atomic mode setting have been covered in detail on LWN back in 2015: <a href="/Articles/653071/">part 1</a> and <a href="/Articles/653466/">part 2</a>. </p> <h4> Additional features </h4> <p> In the discussion of planes, it has been assumed that all of the hardware's planes are the same. But that's not always the case. There is usually a plane, called the primary plane, for RGB-like color formats, which covers the whole display. The compositor sets up the primary plane to display its on-screen image. </p> <p> But most hardware provides an additional plane for the mouse pointer, called the cursor plane. This plane only covers a small area and floats above the primary plane. As the name suggests, the compositor uses the cursor plane to display the mouse-pointer image, which can now be moved around without changing the primary plane's on-screen image at all. <p> <p> Between the primary and cursor plane are overlay planes, which are of various sizes and often support YUV-like color formats. This makes them suitable for displaying streams of video data with low CPU overhead. For that, the video-player application provides the compositor with buffer objects that contain the YUV-based pixel data. </p> <p> The compositor sets up the overlay plane with a framebuffer of the pixel data. The plane scans out the YUV pixel data and performs the color conversion to RGB in hardware. Using dma-buf, the video player can forward individual YUV frames from a hardware video decoder directly to the compositor, thus leaving the entire video processing to hardware. </p> <p> If latency of the display update is of critical concern, it can be helpful to hand over mode-setting capabilities to a single application. The compositor therefore leases the functionality to the application. While an application holds an active DRM lease, it has full control over the mode-setting pipeline. This is useful for 3D headsets, which need to tightly coordinate the output frequency and latency of their internal displays to make the 3D illusion work. DRM leases expire or can be revoked, so the compositor ultimately remains in control of mode setting. </p> <p> While modern compositors use Wayland as their protocol, applications for the X Window System are still common. Xwayland is an X server that runs within a Wayland session. It lets X applications participate in the Wayland sessions transparently by translating between Wayland and X protocols. This works for most use cases. </p> <p> The common use case Xwayland cannot emulate is screen capturing and screen sharing. X applications have access to the X session's whole window tree, which makes screen capturing easy. For security purposes, the Wayland protocol does not allow applications to read the screen or other application's windows. Wayland compositors therefore provide dedicated implementations for capturing or sharing the screen's content. <a href="https://www.pipewire.org/">PipeWire</a>, <a href="https://en.wikipedia.org/wiki/Virtual_Network_Computing">VNC</a>, or <a href="https://en.wikipedia.org/wiki/Remote_Desktop_Protocol">RDP</a> are commonly used for this functionality. </p> <p> If no compositor is active, Linux displays a text console. DRM supports the kernel's framebuffer console for text output. This DRM fbdev emulation acts like a DRM client from user space, but runs entirely within the kernel. It also provides the old framebuffer interfaces, such as <tt>/dev/fb0</tt>. Fbdev and DRM's fbdev emulation are on their way to retirement, though. There are <a href="https://airlied.blogspot.com/2022/09/lpc-2022-gpu-bof-user-console-and.html">ideas</a> for moving much of the console functionality to user space. </p> <p> At the time of writing this article, one quickly evolving topic for Linux graphics is <a href="https://en.wikipedia.org/wiki/High-dynamic-range_rendering">High Dynamic Range (HDR) rendering</a>, which displays the output with more nuanced colors and lighting, thus showing details that are often lost with traditional rendering. Support for this will position Linux to fulfill the needs of professional graphics artists. Currently, support is still uneven, but it's possible to <a href="https://twitter.com/Plagman2/status/1610200412854046720?t=5fb1Oi7zgMj8gOWGod8kWA">use HDR in games</a> and Linux desktops are <a href="https://zamundaaa.github.io/wayland/2023/12/18/update-on-hdr-and-colormanagement-in-plasma.html">beginning to implement HDR</a> as well. </p> <p> At this point, we have followed the path of getting the application's content onto the screen in the modern Linux graphics stack鈥攆rom rendering and memory management to compositing and mode setting. But we've really just scratched the surface. The stack keeps evolving and constantly adds support for new features and hardware. </p><br clear="all"><table class="IndexEntries"> <tr><th colspan=2>Index entries for this article</th></tr> <tr><td><a href="/Kernel/Index">Kernel</a></td><td><a href="/Kernel/Index#Device_drivers-Graphics">Device drivers/Graphics</a></td></tr> <tr><td><a href="/Archives/GuestIndex/">GuestArticles</a></td><td><a href="/Archives/GuestIndex/#Zimmermann_Thomas">Zimmermann, Thomas</a></td></tr> </table><br clear="all"> <hr width="60%%" align="left"> <form action="/Login/" method="post"> <input type="hidden" name="target" value="/Articles/955708/" /> <input type="submit" name="login" value="Log in" /> to post comments <p> </div>  <p><a name="Comments"></a> <a name="CommAnchor956350"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Dec 29, 2023 9:34 UTC (Fri) by <b>bluca</b> (subscriber, #118303) [<a href="/Articles/956350/">Link</a>] (1 responses) </p> </div> </summary> <div class="FormattedComment"> Very well written and informative articles, really enjoyed reading both parts<br> </div> <div class="CommentReplyButton"> <form action="/Articles/956350/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> <a name="CommAnchor956541"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Jan 2, 2024 8:49 UTC (Tue) by <b>tdz</b> (subscriber, #58733) [<a href="/Articles/956541/">Link</a>] </p> </div> </summary> <div class="FormattedComment"> That's much appreciated. Thank you.<br> </div> <div class="CommentReplyButton"> <form action="/Articles/956541/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> </details> </details> <a name="CommAnchor956421"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Dec 30, 2023 9:59 UTC (Sat) by <b>vadim</b> (subscriber, #35271) [<a href="/Articles/956421/">Link</a>] (1 responses) </p> </div> </summary> <div class="FormattedComment"> The one thing I'm still a bit confused about is why PipeWire has anything to do with screen sharing.<br> <p> Could somebody explain? PipeWire is an entirely separate project from a compositor, so what does it do to get the screen data?<br> </div> <div class="CommentReplyButton"> <form action="/Articles/956421/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> <a name="CommAnchor956423"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Dec 30, 2023 11:37 UTC (Sat) by <b>tux3</b> (subscriber, #101245) [<a href="/Articles/956423/">Link</a>] </p> </div> </summary> <div class="FormattedComment"> Not an expert, but my understanding is the following:<br> <p> Pipewire is a thing that applications talk to to shuffle audio and video buffers around, optionally doing some extra processing. It has nothing to do with the compositor, but it's good at exposing reasonable audio/video APIs to apps.<br> <p> The wayland compositor is the only one with direct access the screen data. Actual implementations of the compositor are free to add their own stuff on top of the (small) base of wayland APIs, and they provide a permission system.<br> <p> Apps ask permissions through XDG Desktop Portals, which is a DBus API with an implementation for each desktop environment that might for instance show a pop up to the user with "X app wants to record your screen, Yay/Nay?"<br> <p> The implementation of the XDG portal for accessing the screen uses Pipewire for the logistics of passing buffers around, so that's why it sits in there in the middle between the compositor and the app asking for access. Pipewire asks the compositor, which pushes its data inside Pipewire, and the app gets the data from Pipewire through the portal.<br> <p> Pipewire and portals is just the de-facto standard in the implementation-specific world of Wayland compositors. Wayland as she is spoke.<br> <p> </div> <div class="CommentReplyButton"> <form action="/Articles/956423/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> </details> </details> <a name="CommAnchor956441"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Dec 31, 2023 0:28 UTC (Sun) by <b>NightMonkey</b> (subscriber, #23051) [<a href="/Articles/956441/">Link</a>] (6 responses) </p> </div> </summary> <div class="FormattedComment"> I totally get why Wayland is necessary, and applaud the work. There is a lot of obvious benefits that this series of articles helps detail.<br> <p> I still use Xorg on my personal systems because I still find it both cool and useful to occasionally forward X apps remotely via OpenSSH to my primary laptop. I will miss that feature when it is gone.<br> <p> <p> </div> <div class="CommentReplyButton"> <form action="/Articles/956441/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> <a name="CommAnchor956442"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Dec 31, 2023 6:11 UTC (Sun) by <b>intelfx</b> (subscriber, #130118) [<a href="/Articles/956442/">Link</a>] (4 responses) </p> </div> </summary> <div class="FormattedComment"> Take a look at waypipe.<br> </div> <div class="CommentReplyButton"> <form action="/Articles/956442/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> <a name="CommAnchor956452"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Dec 31, 2023 15:01 UTC (Sun) by <b>pizza</b> (subscriber, #46) [<a href="/Articles/956452/">Link</a>] </p> </div> </summary> <div class="FormattedComment"> <span class="QuotedText">> Take a look at waypipe.</span><br> <p> FWIW I use waypipe at least every few days; it "feels" more bandwidth sensitive than classic X forwarding, but considerably less sensitive to connection latencies.<br> <p> <p> <p> </div> <div class="CommentReplyButton"> <form action="/Articles/956452/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> </details> <a name="CommAnchor956769"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Jan 3, 2024 23:43 UTC (Wed) by <b>GhePeU</b> (subscriber, #56133) [<a href="/Articles/956769/">Link</a>] (1 responses) </p> </div> </summary> <div class="FormattedComment"> I've seen it mentioned before but I haven't had the time to actually try it, what's the user experience with waypipe? I read the documentation and the examples but I'm still not sure.<br> <p> Do you need a new, dedicated SSH/waypipe session for each application or can you just connect to a remote machine, launch and close all the applications you want, even more than one at a time, and keep using the SSH session interactively for CLI tools?<br> </div> <div class="CommentReplyButton"> <form action="/Articles/956769/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> <a name="CommAnchor960828"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Feb 4, 2024 13:13 UTC (Sun) by <b>daenzer</b> (subscriber, #7050) [<a href="/Articles/960828/">Link</a>] </p> </div> </summary> <div class="FormattedComment"> The latter. Waypipe works mostly the same as SSH X11 forwarding from the user PoV. Both can be active for the same SSH connection, and the user can choose Wayland or X per-application via environment variables.<br> </div> <div class="CommentReplyButton"> <form action="/Articles/960828/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> </details> </details> <a name="CommAnchor956955"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Jan 5, 2024 5:32 UTC (Fri) by <b>raven667</b> (subscriber, #5198) [<a href="/Articles/956955/">Link</a>] </p> </div> </summary> <div class="FormattedComment"> <span class="QuotedText">> waypipe</span><br> <p> that may be cool too, but I don't think that X11 support in existing apps and libraries is going away anytime soon, even if the display is managed by a Wayland compositor, Xwayland is going to exist for a _loooong_ time to maintain compatibility with existing apps. More than enough time to make a new standard default for new deployed systems and new apps out of the various ways you could forward existing apps over ssh with wayland if we wanted to deprecate X11 for new apps as it has been done for compositors/windowmanagers.<br> <p> Just the other day I forwarded an app over SSH/X11 onto Windows10/WSLg with Xwayland transparently and it worked the way it always has.<br> </div> <div class="CommentReplyButton"> <form action="/Articles/956955/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> </details> </details> <a name="CommAnchor960827"></a> <details class="CommentBox" open> <summary><h3 class="CommentTitle">The Linux graphics stack in a nutshell, part聽2</h3> <div class="AnnLine"> <p class="CommentPoster"> Posted Feb 4, 2024 13:09 UTC (Sun) by <b>daenzer</b> (subscriber, #7050) [<a href="/Articles/960827/">Link</a>] </p> </div> </summary> <div class="FormattedComment"> No need to use Xorg for that, it works exactly the same (via Xwayland) in a Wayland session.<br> </div> <div class="CommentReplyButton"> <form action="/Articles/960827/comment" method="post"> <input type="submit" value="Reply to this comment"> </form> </div> <p> </details> </details> </div>  <div class="rightcol not-print"> <div id="azk93271_right_zone"></div> </div> </div>  <br clear="all"> <center> <P> <span class="ReallySmall"> Copyright © 2023, Eklektix, Inc.<BR> Comments and public postings are copyrighted by their creators.<br> Linux is a registered trademark of Linus Torvalds<br> </span> </center> </body></html>