17 ms·

Xorg-Server 21.1.0

154 points by Liskni_si 5y ago

Liskni_si 5y ago
Coincidentally, xmonad 0.17.0 was released today as well: https://xmonad.org/news/2021/10/27/xmonad-0-17-0.html https://xmonad.org/news/2021/10/27/xmonad-0-17-0.html :-)
- nextos 5y ago
  Yes, I've been using XMonad (and StumpWM) for many years and they are tightly coupled to Xorg. Moving to Wayland implies a complete rewrite of both is necessary.
  - jolmg 5y ago
    I imagine the same is true of all window managers.
woodruffw 5y ago
> The meson support is now fully mature. While autotools support will still be kept for this release series, it will be dropped afterwards. autotools delenda est.
- pantalaimon 5y ago
  Won't that annoy most distributions as they now have to update their package build script for X.org?
  - woodruffw 5y ago
    The life of a package distributor is one of constant build changes. Among them, the switch from autotools to meson is probably not an especially disruptive one. For the ecosystems I've helped maintain, it certainly wouldn't be.
    - wahern 5y ago
      Packaging frameworks like Debian and RPM coevolved with autotools, especially when it comes to things like cross-compilation, standard build flags, etc. Anything that moves away from autotools is, AFAIU, generally considered a PITA for maintainers of the big distributions. Modern build tools optimize for the problems of massive corporate centralized repositories and build pipelines, which often bundle dependencies and otherwise approach most problems from an entirely different angle. Nuances related to portability, cross-compilation, filesystem hierarchies, dynamic library versioning, etc, are typically afterthoughts if they're considered at all. OTOH, while it's a PITA it's certainly one to which package maintainers are accustomed. autotools began to lose mindshare among younger programmers and with younger projects many years ago.
      - sjcoles 5y ago
        Modern rpm spec has built in macros for meson making it less of an issue.
        wahern 5y ago
        IME as someone who has done alot of portability work, both for my own projects and others, and including writing more than my fair share of Debian and RPM builds (but not as an official package maintainer for a distro), boilerplate stuff is rarely the issue. It's all the random, niche problems that invariably crop up at least once or twice with every project, even smaller ones. Every build is broken somehow. Given that basic reality, what matters is how often you can route around brokenness without patching the upstream build, and when you must patch how easy it will be to implement and maintain those patches.
  - eddieh 5y ago
    Building X was already complex and annoying. While I hate autotools, I didn’t find Meson to be particularly better. If anything this is a lateral change. Instead of m4, shell, and makefiles, Meson has python, some python packages (managed with pip), and ninja. I guess Meson is faster, but I’m not convinced that justifies changing the build system especially since the speed up isn’t too significant.
    - bonzini 5y ago
      Meson doesn't depend on anything other than the Python standard library.
      - eddieh 5y ago
        Okay, but builds can require additional python modules. Mesa requires Mako and won’t build without it.
        bonzini 5y ago
        But that's not because of Meson. It's just because Mesa authors wrote a code generator in Python; you'd need Mako even if the build system used autotools or hand-written makefiles.
        eddieh 5y ago
        Okay, my bad. I just tried a pre-Meson version of Mesa and you're right. I thought that Mako was some Meson extension...I didn't really look into it much. I was just annoyed when the build broke and Meson printed a message that looked like it was missing a dependency. Then I was doubly annoyed when pip told me Homebrew (or Linuxbrew) would break in the future. It seemed like Meson was a PITA, but that was my first experience with it. I was wrong and I apologize.
    - p12tic 5y ago
      My own experience working on X server, clean ccache-based rebuild is a couple minutes faster on meson compared to autotools. These minutes add up quickly, switching my workflow to meson paid for itself the same day.
  - chousuke 5y ago
    If you're packaging RPMs, what you need is approximately to change a few %configure macros to the corresponding %meson macros. Though X.org is large enough that there will probably be some weirdness. If your software is distributed as a source tarball, the build system follows established conventions like honouring $DESTDIR and doesn't do anything weird like download extra stuff from the internet, creating packages is super easy, at least with RPM. Most of the time you just write out a bit of metadata, list your dependencies, use standard macros for your build system to do the actual building and then list the files that you want to use from the build (potentially putting them in subpackages), and that's it. RPM even supports specifying dependencies like pkgconfig(library) or perl(Thing) so that the actual package name that provides it does not matter. I haven't done Debian packaging in ages so I don't know how it compares.
    - p12tic 5y ago
      On Debian it's the same. I use Debian packages as the means to ship code to test devices and the most time consuming thing when converting X server from autotools to meson was the default configure flags (meson and autotools use different formats).
- bradfitz 5y ago
  While researching what Meson was after reading this, I was amused at this FAQ entry on their site: https://mesonbuild.com/howtox.html https://mesonbuild.com/howtox.html --- "How do I do X in Meson?" :)
- sprash 5y ago
  Rather bad news. Meson introduces a rat-tail of build dependencies.
  - doppioandante 5y ago
    You may be interested in muon: https://git.sr.ht/~lattis/muon/ https://git.sr.ht/~lattis/muon/
    - cozzyd 5y ago
      Terrible name. A muon is a lepton, not a meson. If it were a lighter replacement of electron, muon would be an appropriate (if counterintuitive) name. There are so many mesons (pion, kaon, \eta, \rho, J/\psi, D, B, \omega,\upsilon), why not pick one of those?
  - woodruffw 5y ago
    > Meson introduces a rat-tail of build dependencies. From the Ubuntu repos, it looks like the top-level dependencies are Ninja and Python 3[1]. That doesn't seem particularly bad to me? [1]: https://packages.ubuntu.com/focal/meson https://packages.ubuntu.com/focal/meson
    - eddieh 5y ago
      Had to deal with this recently, Homebrew on macOS though. Meson build failed. Had to manually install Mako with pip, which also installed MarkupSafe. Then bitched that Homebrew (or Linuxbrew) will break in the future for some reason. So next time I build X, I can look forward to that. :/
      - woodruffw 5y ago
        My understanding (which could be very wrong) is that Meson on its own has no external dependencies like Mako, but that (by virtue of being Python) anybody can write a terrible build that introduces additional dependencies. Is that correct? If so, that's unfortunate, but it isn't that different from what happens in autotools land -- I've had plenty of builds fail because the configure step fails to check for `$tool` and then expects it to be present at build-time.
marcodiego 5y ago
Xorg/Xfree86 served us very well for decades. Will still continue to do so as XWayland. It feels like saying goodbye to a good employer that is retiring but will be replaced by someone more adequate for the job. Thank you all, devs!
- sprash 5y ago
  So far there is no viable replacement around that is "more adequate for the job" (Wayland is fundamentally flawed at the concept level). So Xorg will stick around much longer probably decades.
  - kaba0 5y ago
    How would Wayland be fundamentally flawed?
    - sprash 5y ago
      Wayland makes the wrong abstractions and does not offer vital functionality usually needed on a Desktop system. As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.
      - xxpor 5y ago
        Why are objections like this not solved with things like wlroots?
        folmar 5y ago
        wlroots are not used by the two main desktops, so to get basic features like screenshots you need to support 3 different ways already.
        5y ago
jbverschoor 5y ago
Can we get an html implementation of X, in such a way that it doesn't require framebuffers, but just uses the the windowing and text primitives?
- cpach 5y ago
  Not sure but maybe this is similar to what you’re describing…? https://guacamole.apache.org/ https://guacamole.apache.org/
  - yjftsjthsd-h 5y ago
    You'd have to pair with xvnc or https://en.wikipedia.org/wiki/Xvfb https://en.wikipedia.org/wiki/Xvfb + x11vnc or so, but yeah
- pantalaimon 5y ago
  After a quick search I found https://github.com/Xpra-org/xpra-html5 https://github.com/Xpra-org/xpra-html5 and https://github.com/GothAck/javascript-x-server https://github.com/GothAck/javascript-x-server
p12tic 5y ago
Hi, I'm the release manager responsible for this X release seeing the light. This release would not have happened if an effort to improve touchpad support in Linux was not funded for the past year and half. X server 21.1 makes touchpad gesture functionality support universal so it's much easier to offer consistent user experience for everyone and downstream developers are less reluctant to accept contributions. Thanks a lot to all the sponsors: https://github.com/sponsors/gitclear https://github.com/sponsors/gitclear By the way, I wonder if there is demand for long-term maintenance of X server specifically. If you think you could contribute, maybe write here and if there's enough interest maybe it's possible to crowd fund something.
- yjftsjthsd-h 5y ago
  > By the way, I wonder if there is demand for long-term maintenance of X server specifically. If you think you could contribute, maybe write here and if there's enough interest maybe it's possible to crowd fund something. Are we talking money, time, tooling, etc.? I'm rather attached to Xorg and would like it to keep going; what would be the most helpful?
  - p12tic 5y ago
    All of these are great, but perhaps the most important would be money as it's the only thing that clearly indicates the level of community support. Once there's funding it's much easier to prioritize the work. I've setup Patreon page at https://www.patreon.com/p12tic https://www.patreon.com/p12tic
- mrweasel 5y ago
  So if the touchpad funding had failed there would have been no more Xorg release?
  - p12tic 5y ago
    At least I would not have been driving this release. Maybe someone else would have stepped up, it's hard to say. However there was no release manager for the last several years, so the likelihood of this outcome would have been small.
jmclnx 5y ago
As a BSD user, glad to see the release, but I am concerned about the future of X since Wayland has plenty of Linuxisms in it, making it very hard to port. https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-report/ https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-... https://undeadly.org/cgi?action=article;sid=20210124113220 https://undeadly.org/cgi?action=article;sid=20210124113220
dyingkneepad 5y ago
It's so nice to see this! As someone who is still not using Wayland by default (I tried, but it regresses my setup), I am thankful there are still people involved on this. Good job, guys, you are appreciated. It's not just because Wayland looks sexier [0] that your work on the thing most people actually use is appreciated. [0]: considering Wayland is more than a decade old by now and is still a huge mess, I guess I'll keep trusting old lady Xorg's experience to handle my workflow.
jancsika 5y ago
I found a neat tool recently called x2x. It lets me forward keyboard/mouse movement from my laptop to my rpi-connected tv over ssh. So my laptop ends up doubling as a very fancy remote control. :) E.g., I just mouse over to the right on my screen so I can move the mouse on my tv and then type in a search string to bring up a video to watch in the browser on the tv. 1. Can this be done with Wayland currently? (Currently = works in some lts version of a popular distro like Debian or Ubuntu). 2. Glad to see people still working on fixing bugs and making improvements in Xorg-Server!
- GekkePrutser 5y ago
  There's also synergy. Unfortunately it's commercial. I used it for a while. https://symless.com/synergy https://symless.com/synergy Not sure if it works with Wayland either though.
  - GekkePrutser 5y ago
    Actually, right now I'd recommend Barrier: https://github.com/debauchee/barrier https://github.com/debauchee/barrier
ncmncm 5y ago
For people convinced that X is irreparably insecure, I would direct you to the implementation in Qubes. On Qubes, a secure management environment runs as a VM called dom0 on Xen, a hypervisor. dom0 (or, on the upcoming 4.1 release, another VM) runs a Linux and manages the physical display and input devices, and an X server that only it connects to, for desktop operations. User-level applications are always run in other VMs that have no direct access to hardware. Each such appVM runs its own X server, headless. So, the only programs that talk to the physical X server are desktop widgets like the XFCE "panel". appVMs have no access to those. When an app opens a window in its X server, a memory mapping is provided shared with dom0. The app's X server writes its pixels into that shared memory, and dom0 copies from that shared memory to a corresponding window on the physical display. dom0 delivers input events to an appVM's X when they occur within a window the appVM controls. Importantly, each appVM has no access to any other appVM's X server, window contents, or the GPU, or input; everything it does other than making and deleting windows is via raw bits copied in memory without interpretation. Thus, appVMs are wholly isolated from one another except via (virtual) network routing. You may object that this would make interaction very slow and laggy. Perhaps surprisingly, it does not, at least on modern hardware, and when running non-time-critical programs. Certainly, browsers (including youtube pages) and similar programs -- wireshark, transmission-gtk, gitk, evince, system-config-printer -- work fine. Even mpv does fine with movies at 2880x1620 resolution. (4K is just out of reach, on my 5y-old laptop.) I don't know what the brave new world of Wayland will look like on Qubes. The same, I expect. Ways to securely virtualize access to the GPU are, to my knowledge, still a research topic. Maybe Vulkan operations can be forwarded safely? Each shader's memory would need to be protected from others', or operations sequenced with mappings swapped in and out.
- ncmncm 5y ago
  But see also https://spectrum-os.org/lists/hyperkitty/list/discuss@spectrum-os.org/thread/DAAFI4JGWSJZM7CCZIUH2QVW6PUCHNE4/ https://spectrum-os.org/lists/hyperkitty/list/discuss@spectr... Spectrum-OS is a re-imagining of Qubes with much lighter-weight app VMs that each host just one app, just while it is running, without each having a whole Linux kernel and systemd in it. Spectrum-OS is still under development.

154 points by Liskni_si 5y ago

Coincidentally, xmonad 0.17.0 was released today as well: https://xmonad.org/news/2021/10/27/xmonad-0-17-0.html https://xmonad.org/news/2021/10/27/xmonad-0-17-0.html :-)

nextos 5y ago
Yes, I've been using XMonad (and StumpWM) for many years and they are tightly coupled to Xorg. Moving to Wayland implies a complete rewrite of both is necessary.
- jolmg 5y ago
  I imagine the same is true of all window managers.

woodruffw 5y ago

> The meson support is now fully mature. While autotools support will still be kept for this release series, it will be dropped afterwards. autotools delenda est.

pantalaimon 5y ago
Won't that annoy most distributions as they now have to update their package build script for X.org?
- woodruffw 5y ago
  The life of a package distributor is one of constant build changes. Among them, the switch from autotools to meson is probably not an especially disruptive one. For the ecosystems I've helped maintain, it certainly wouldn't be.
  - wahern 5y ago
    Packaging frameworks like Debian and RPM coevolved with autotools, especially when it comes to things like cross-compilation, standard build flags, etc. Anything that moves away from autotools is, AFAIU, generally considered a PITA for maintainers of the big distributions. Modern build tools optimize for the problems of massive corporate centralized repositories and build pipelines, which often bundle dependencies and otherwise approach most problems from an entirely different angle. Nuances related to portability, cross-compilation, filesystem hierarchies, dynamic library versioning, etc, are typically afterthoughts if they're considered at all. OTOH, while it's a PITA it's certainly one to which package maintainers are accustomed. autotools began to lose mindshare among younger programmers and with younger projects many years ago.
    - sjcoles 5y ago
      Modern rpm spec has built in macros for meson making it less of an issue.
      - wahern 5y ago
        IME as someone who has done alot of portability work, both for my own projects and others, and including writing more than my fair share of Debian and RPM builds (but not as an official package maintainer for a distro), boilerplate stuff is rarely the issue. It's all the random, niche problems that invariably crop up at least once or twice with every project, even smaller ones. Every build is broken somehow. Given that basic reality, what matters is how often you can route around brokenness without patching the upstream build, and when you must patch how easy it will be to implement and maintain those patches.
- eddieh 5y ago
  Building X was already complex and annoying. While I hate autotools, I didn’t find Meson to be particularly better. If anything this is a lateral change. Instead of m4, shell, and makefiles, Meson has python, some python packages (managed with pip), and ninja. I guess Meson is faster, but I’m not convinced that justifies changing the build system especially since the speed up isn’t too significant.
  - bonzini 5y ago
    Meson doesn't depend on anything other than the Python standard library.
    - eddieh 5y ago
      Okay, but builds can require additional python modules. Mesa requires Mako and won’t build without it.
      - bonzini 5y ago
        But that's not because of Meson. It's just because Mesa authors wrote a code generator in Python; you'd need Mako even if the build system used autotools or hand-written makefiles.
        eddieh 5y ago
        Okay, my bad. I just tried a pre-Meson version of Mesa and you're right. I thought that Mako was some Meson extension...I didn't really look into it much. I was just annoyed when the build broke and Meson printed a message that looked like it was missing a dependency. Then I was doubly annoyed when pip told me Homebrew (or Linuxbrew) would break in the future. It seemed like Meson was a PITA, but that was my first experience with it. I was wrong and I apologize.
  - p12tic 5y ago
    My own experience working on X server, clean ccache-based rebuild is a couple minutes faster on meson compared to autotools. These minutes add up quickly, switching my workflow to meson paid for itself the same day.
- chousuke 5y ago
  If you're packaging RPMs, what you need is approximately to change a few %configure macros to the corresponding %meson macros. Though X.org is large enough that there will probably be some weirdness. If your software is distributed as a source tarball, the build system follows established conventions like honouring $DESTDIR and doesn't do anything weird like download extra stuff from the internet, creating packages is super easy, at least with RPM. Most of the time you just write out a bit of metadata, list your dependencies, use standard macros for your build system to do the actual building and then list the files that you want to use from the build (potentially putting them in subpackages), and that's it. RPM even supports specifying dependencies like pkgconfig(library) or perl(Thing) so that the actual package name that provides it does not matter. I haven't done Debian packaging in ages so I don't know how it compares.
  - p12tic 5y ago
    On Debian it's the same. I use Debian packages as the means to ship code to test devices and the most time consuming thing when converting X server from autotools to meson was the default configure flags (meson and autotools use different formats).
bradfitz 5y ago
While researching what Meson was after reading this, I was amused at this FAQ entry on their site: https://mesonbuild.com/howtox.html https://mesonbuild.com/howtox.html --- "How do I do X in Meson?" :)
sprash 5y ago
Rather bad news. Meson introduces a rat-tail of build dependencies.
- doppioandante 5y ago
  You may be interested in muon: https://git.sr.ht/~lattis/muon/ https://git.sr.ht/~lattis/muon/
  - cozzyd 5y ago
    Terrible name. A muon is a lepton, not a meson. If it were a lighter replacement of electron, muon would be an appropriate (if counterintuitive) name. There are so many mesons (pion, kaon, \eta, \rho, J/\psi, D, B, \omega,\upsilon), why not pick one of those?
- woodruffw 5y ago
  > Meson introduces a rat-tail of build dependencies. From the Ubuntu repos, it looks like the top-level dependencies are Ninja and Python 3[1]. That doesn't seem particularly bad to me? [1]: https://packages.ubuntu.com/focal/meson https://packages.ubuntu.com/focal/meson
  - eddieh 5y ago
    Had to deal with this recently, Homebrew on macOS though. Meson build failed. Had to manually install Mako with pip, which also installed MarkupSafe. Then bitched that Homebrew (or Linuxbrew) will break in the future for some reason. So next time I build X, I can look forward to that. :/
    - woodruffw 5y ago
      My understanding (which could be very wrong) is that Meson on its own has no external dependencies like Mako, but that (by virtue of being Python) anybody can write a terrible build that introduces additional dependencies. Is that correct? If so, that's unfortunate, but it isn't that different from what happens in autotools land -- I've had plenty of builds fail because the configure step fails to check for `$tool` and then expects it to be present at build-time.

marcodiego 5y ago

Xorg/Xfree86 served us very well for decades. Will still continue to do so as XWayland. It feels like saying goodbye to a good employer that is retiring but will be replaced by someone more adequate for the job. Thank you all, devs!

sprash 5y ago
So far there is no viable replacement around that is "more adequate for the job" (Wayland is fundamentally flawed at the concept level). So Xorg will stick around much longer probably decades.
- kaba0 5y ago
  How would Wayland be fundamentally flawed?
  - sprash 5y ago
    Wayland makes the wrong abstractions and does not offer vital functionality usually needed on a Desktop system. As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.
    - xxpor 5y ago
      Why are objections like this not solved with things like wlroots?
      - folmar 5y ago
        wlroots are not used by the two main desktops, so to get basic features like screenshots you need to support 3 different ways already.
        5y ago

jbverschoor 5y ago

Can we get an html implementation of X, in such a way that it doesn't require framebuffers, but just uses the the windowing and text primitives?

cpach 5y ago
Not sure but maybe this is similar to what you’re describing…? https://guacamole.apache.org/ https://guacamole.apache.org/
- yjftsjthsd-h 5y ago
  You'd have to pair with xvnc or https://en.wikipedia.org/wiki/Xvfb https://en.wikipedia.org/wiki/Xvfb + x11vnc or so, but yeah
pantalaimon 5y ago
After a quick search I found https://github.com/Xpra-org/xpra-html5 https://github.com/Xpra-org/xpra-html5 and https://github.com/GothAck/javascript-x-server https://github.com/GothAck/javascript-x-server

p12tic 5y ago

Hi, I'm the release manager responsible for this X release seeing the light. This release would not have happened if an effort to improve touchpad support in Linux was not funded for the past year and half. X server 21.1 makes touchpad gesture functionality support universal so it's much easier to offer consistent user experience for everyone and downstream developers are less reluctant to accept contributions. Thanks a lot to all the sponsors: https://github.com/sponsors/gitclear https://github.com/sponsors/gitclear By the way, I wonder if there is demand for long-term maintenance of X server specifically. If you think you could contribute, maybe write here and if there's enough interest maybe it's possible to crowd fund something.

yjftsjthsd-h 5y ago
> By the way, I wonder if there is demand for long-term maintenance of X server specifically. If you think you could contribute, maybe write here and if there's enough interest maybe it's possible to crowd fund something. Are we talking money, time, tooling, etc.? I'm rather attached to Xorg and would like it to keep going; what would be the most helpful?
- p12tic 5y ago
  All of these are great, but perhaps the most important would be money as it's the only thing that clearly indicates the level of community support. Once there's funding it's much easier to prioritize the work. I've setup Patreon page at https://www.patreon.com/p12tic https://www.patreon.com/p12tic
mrweasel 5y ago
So if the touchpad funding had failed there would have been no more Xorg release?
- p12tic 5y ago
  At least I would not have been driving this release. Maybe someone else would have stepped up, it's hard to say. However there was no release manager for the last several years, so the likelihood of this outcome would have been small.

jmclnx 5y ago

As a BSD user, glad to see the release, but I am concerned about the future of X since Wayland has plenty of Linuxisms in it, making it very hard to port. https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-report/ https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-... https://undeadly.org/cgi?action=article;sid=20210124113220 https://undeadly.org/cgi?action=article;sid=20210124113220

dyingkneepad 5y ago

It's so nice to see this! As someone who is still not using Wayland by default (I tried, but it regresses my setup), I am thankful there are still people involved on this. Good job, guys, you are appreciated. It's not just because Wayland looks sexier [0] that your work on the thing most people actually use is appreciated. [0]: considering Wayland is more than a decade old by now and is still a huge mess, I guess I'll keep trusting old lady Xorg's experience to handle my workflow.

jancsika 5y ago

I found a neat tool recently called x2x. It lets me forward keyboard/mouse movement from my laptop to my rpi-connected tv over ssh. So my laptop ends up doubling as a very fancy remote control. :) E.g., I just mouse over to the right on my screen so I can move the mouse on my tv and then type in a search string to bring up a video to watch in the browser on the tv. 1. Can this be done with Wayland currently? (Currently = works in some lts version of a popular distro like Debian or Ubuntu). 2. Glad to see people still working on fixing bugs and making improvements in Xorg-Server!

GekkePrutser 5y ago
There's also synergy. Unfortunately it's commercial. I used it for a while. https://symless.com/synergy https://symless.com/synergy Not sure if it works with Wayland either though.
- GekkePrutser 5y ago
  Actually, right now I'd recommend Barrier: https://github.com/debauchee/barrier https://github.com/debauchee/barrier

ncmncm 5y ago

For people convinced that X is irreparably insecure, I would direct you to the implementation in Qubes. On Qubes, a secure management environment runs as a VM called dom0 on Xen, a hypervisor. dom0 (or, on the upcoming 4.1 release, another VM) runs a Linux and manages the physical display and input devices, and an X server that only it connects to, for desktop operations. User-level applications are always run in other VMs that have no direct access to hardware. Each such appVM runs its own X server, headless. So, the only programs that talk to the physical X server are desktop widgets like the XFCE "panel". appVMs have no access to those. When an app opens a window in its X server, a memory mapping is provided shared with dom0. The app's X server writes its pixels into that shared memory, and dom0 copies from that shared memory to a corresponding window on the physical display. dom0 delivers input events to an appVM's X when they occur within a window the appVM controls. Importantly, each appVM has no access to any other appVM's X server, window contents, or the GPU, or input; everything it does other than making and deleting windows is via raw bits copied in memory without interpretation. Thus, appVMs are wholly isolated from one another except via (virtual) network routing. You may object that this would make interaction very slow and laggy. Perhaps surprisingly, it does not, at least on modern hardware, and when running non-time-critical programs. Certainly, browsers (including youtube pages) and similar programs -- wireshark, transmission-gtk, gitk, evince, system-config-printer -- work fine. Even mpv does fine with movies at 2880x1620 resolution. (4K is just out of reach, on my 5y-old laptop.) I don't know what the brave new world of Wayland will look like on Qubes. The same, I expect. Ways to securely virtualize access to the GPU are, to my knowledge, still a research topic. Maybe Vulkan operations can be forwarded safely? Each shader's memory would need to be protected from others', or operations sequenced with mappings swapped in and out.

ncmncm 5y ago
But see also https://spectrum-os.org/lists/hyperkitty/list/discuss@spectrum-os.org/thread/DAAFI4JGWSJZM7CCZIUH2QVW6PUCHNE4/ https://spectrum-os.org/lists/hyperkitty/list/discuss@spectr... Spectrum-OS is a re-imagining of Qubes with much lighter-weight app VMs that each host just one app, just while it is running, without each having a whole Linux kernel and systemd in it. Spectrum-OS is still under development.