This week saw the release of the LXQt 2.0 desktop environment, reports 9to5Linux. And besides bringing Qt 6 support (and a new default application menu), it also brings support for the Wayland display protocol to more components: The LXQt development is confident that the next major release, LXQt 2.1, will be fully Wayland compatible. The components that need to be ported to Wayland include ScreenGrab, LXQt Global Shortcuts, LXQt Panel's task-bar and keyboard indicator, some input settings, and settings of monitor, power button, and screen locker.

"Wayland will be the main target for LXQt 2.1.0, as Qt6 was for LXQt 2.0.0" said the devs. "Most Wayland compositors have tools that can be used instead of them, such that an LXQt-Wayland session is already possible for advanced users."
The lightweight Linux distro Lubuntu uses LXQtplace in place of GNOME — and Lubuntu 24.04 LTS will include an optional Wayland session alongside its default Xorg one, according to 9to5Linux:

I said it before and I'll say it again, 2024 is the year of the Wayland desktop... The Lubuntu team plans to support the Xorg session until 2026 to aid users with older GPUs... However, the tables will be turned next year with the Lubuntu 24.10 release, which will be shipping with Wayland by default.

Back in 2006 Slashdot reported on a 50-megabyte "micro" distro called Damn Small Linux. (And in 2012 we wrote that it "rose from the dead" with a new release candidate.)

Now Damn Small Linux has been reborn again, according to its developer's web site: Creating the original DSL, a versatile 50MB distribution, was a lot of fun and one of the things I am most proud of as a personal accomplishment. However, as a concept, it was in the right place at the right time, and the computer industry has changed a lot since then. While it would be possible to make a bootable Xwindows 50MB distribution today, it would be missing many drivers and have only a handful of very rudimentary applications. People would find such a distribution a fun toy or something to build upon, but it would not be usable for the average computer user out of the gate....

The new goal of DSL is to pack as much usable desktop distribution into an image small enough to fit on a single CD, or a hard limit of 700MB. This project is meant to service older computers and have them continue to be useful far into the future. Such a notion sits well with my values. I think of this project as my way of keeping otherwise usable hardware out of landfills.

As with most things in the GNU/Linux community, this project continues to stand on the shoulders of giants. I am just one guy without a CS degree, so for now, this project is based on antiX 23 i386... a fantastic distribution that I think shares much of the same spirit as the original DSL project. AntiX shares pedigree with MEPIS and also leans heavily on the geniuses at Debian.
The blog It's FOSS News describes it as "a unique experience in a sea of Debian-based and Fedora-based distros." It is offered with two window managers, Fluxbox and JWM, with apt being fully enabled by default for easy package installations... At the time of writing, only the Alpha ISOs were made available on the official downloads page. It is only a matter of time before we get a stable release.

Legendary programmer Jamie Zawinski has worked on everything from the earliest releases of the Netscape Navigator browser to XEmacs, Mozilla, and, of course, the XScreenSaver project.

Now Slashdot reader e432776 writes: JWZ continues to track issues with screensavers on Linux (since 2004!), and discusses a new bug in cinnamon-screensaver. Long-standing topics like X11, developer interaction, and code licensing all feature. Solutions to these long-standing issues remain elusive.
Jamie titled his blog post "I told you so, 2021 edition": You will recall that in 2004 , which is now seventeen years ago, I wrote a document explaining why I made the design trade-offs that I did in XScreenSaver, and in that document I predicted this exact bug as my example of, "this is what will happen if you don't do it this way."

And they went and made that happen.

Repeatedly.

Every time this bug is re-introduced, someone pipes up and says something like, "So what, it was a bug, they've fixed it." That's really missing the point. The point is not that such a bug existed, but that such a bug was even possible. The real bug here is that the design of the system even permits this class of bug. It is unconscionable that someone designing a critical piece of security infrastructure would design the system in such a way that it does not fail safe .

Especially when I have given them nearly 30 years of prior art demonstrating how to do it right, and a two-decades-old document clearly explaining What Not To Do that coincidentally used this very bug as its illustrative strawman!

These bugs are a shameful embarrassment of design -- as opposed to merely bad code...
ZDNet reports that Linux Mint has issued a patch for Cinnamon that fixes the screensaver bug. But HotHardware notes that it was discovered when "one Dad let the kids play with the keyboard. This button-mashing actually crashed the machine's screensaver by sheer luck, allowing them onto the desktop, ultimately leading to the discovery of a high priority security vulnerability for the Linux Mint team."

But that's not the only thing bothering Jamie Zawinski: Just to add insult to injury, it has recently come to my attention that not only are Gnome-screensaver, Mint-screensaver and Cinnamon-screensaver buggy and insecure dumpster fires, but they are also in violation of my license and infringing my copyright.

XScreenSaver was released under the BSD license, one of the oldest and most permissive of the free software licenses. It turns out, the Gnome-screensaver authors copied large parts of XScreenSaver into their program, removed the BSD license and slapped a GPL license on my code instead -- and also removed my name. Rude...

Mint-screensaver and Cinnamon-screensaver, being forks and descendants of Gnome-screensaver, have inherited this license violation and continue to perpetuate it. Every Linux distro is shipping this copyright- and license-infringing code.

I eagerly await hearing how they're going to make this right.

ZDNet reports: At the Microsoft Build 2020 virtual developers' conference, CEO Satya Nadella announced that Windows Subsystem for Linux (WSL) 2.0 would soon support Linux GUIs and applications. That day is closer now than ever before. At the recent X.Org Developers Conference, Microsoft partner developer lead Steve Pronovost revealed that Microsoft has made it possible to run graphical Linux applications within WSL.

It's always been possible to run Linux graphical programs such as the GIMP graphics editor, Evolution e-mail client, and LibreOffice on WSL. But it wasn't easy. You had to install a third-party X Window display server, such as the VcXsrv Windows X Server in Windows 10, and then do some tuning with both Windows and Linux to get them to work together smoothly. The X Window System underlies almost all Linux graphical user interfaces. Now, Microsoft has ported a Wayland display server to WSL. Wayland is the most popular X Window compatible server. In WSL2, it connects the graphical Linux applications via a Remote Desktop Protocol (RDP) connection to the main Windows display. This means you can run Linux and Windows GUI applications simultaneously on the same desktop screen....

Craig Loewen, Microsoft WSL Program Manager, added in a Twitter thread that the key differences between using a third-party X server and the built-in Wayland server is that: "You don't need to start up or start the server, we'll handle that for you." In addition, it comes with "Lovely integration with Windows," such as drop shadows and Linux icon support. Loewen also said you can run a Linux web browser in it. "We haven't tested it extensively with a full desktop environment yet, as we want to focus on running often asked for apps first, and primarily IDEs [integrated development environment] so you can run those in a full Linux environment," he said.

Don't get too excited about it just yet, though. Loewen continued, "We don't yet have an ETA for the beta channel, however, this work will be available in general for Insiders to try within the next couple of months."

An anonymous reader writes: After being desired by NVIDIA Linux users for years, the proprietary GeForce graphics driver natively supports Wayland and Mir as an alternative to an X.Org Server. It's been a long time coming for the proprietary GPU driver stacks to support Wayland/Mir, but with today's 364.12 beta driver there is now the necessary DRM KMS kernel support and EGL extensions for being able to handle these next-generation display solutions. The new NVIDIA Linux driver also provides integrated Vulkan support, PRIME rendering support, and other additions.

An anonymous reader writes: The xf86-video-intel 3.0 DDX driver has been in development the past two and a half years without seeing an official release. The last development release even of xf86-video-intel 3.0 Git was 13 months ago with the xf86-video-intel 2.99.917 release. At that time it was said by Intel's lead DDX developer, "3 months have passed, we should make one more snapshot before an imminent release." Since then, there's been no communications about a stable release of this DDX driver that makes SNA the default acceleration architecture over UXA. Over on the intel-gfx mailing list users are bringing up again the state of xf86-video-intel 3.0 and why it isn't released yet, questioning if Intel is "able to maintain its own device driver in a usable way?"

An anonymous reader writes: The X.Org domain predates the X.Org Foundation. It was used in the '90s as a destination by The Open Group around the X Window System. While many are expecting Mir and Wayland to eventually succeed the X.Org Server, it seems the X.Org/X11 Server may outlive the valuable domain. Thanks to poor management by the X.Org Foundation, they risk losing access to their one-letter domain. Procrastination, paired with not transferring the domain when forming the non-profit foundation, has led to a last-minute mess. They left the domain registered for years to a person who is no longer involved with X.Org — and doesn't want to relinquish it. In the few days until the domain expires, they are hoping for a "Hail Mary." Let this be a lesson for open-source projects to better manage their assets.

An anonymous reader writes: AMD has made available its new AMDGPU Linux graphics driver comprised of a brand new DRM/KMS kernel driver, a new xf86-video-amdgpu X11 driver, and modifications to libdrm and Gallium3D. This new AMDGPU driver is designed for supporting AMD's next-generation hardware with no support differences for currently supported Radeon GPUs. While yet to be released, this new AMDGPU driver is the critical piece to the new unified driver strategy with Catalyst where their high performance proprietary driver will now become limited to being a user-space binary component that uses this open-source kernel driver.

jones_supa writes: One thing we all remember from Windows NT is the security feature requiring the user to press CTRL-ALT-DEL to unlock the workstation (this can still be enabled with a policy setting). The motivation was to make it impossible for other programs to mimic a lock screen, as they couldn't react to the special key combination. Martin Gräßlin from the KDE team takes a look at the lock screen security on X11. On a protocol level, X11 doesn't know anything of screen lockers. Also the X server doesn't know that the screen is locked as it doesn't understand the concept. This means the screen locker can only use the core functionality available to emulate screen locking. That in turn also means that any other client can do the same and prevent the screen locker from working (for example opening a context menu on any window prevents the screen locker from activating). That's quite a bummer: any process connected to the X server can block the screen locker, and even more it could fake your screen locker.

An anonymous reader writes The much anticipated Xorg Server 1.16 release is now available. The X.Org "Marionberry Pie" release features XWayland integration, GLAMOR support, systemd support, and many other features. XWayland support allows for legacy X11 support in Wayland environments via GL acceleration, GLAMOR provides generic 2D acceleration, non-PCI GPU device improvements, and countless other changes. The systemd integration finally allows the X server to run without root privileges, something in the works for a very long time. The non-PCI device improvements mean System-on-a-Chip graphics will work more smoothly, auto-enumerating just like PCI graphics devices do. As covered previously, GLAMOR (the pure OpenGL acceleration backend) has seen quite a bit of improvement, and now works with Xephyr and XWayland.

An anonymous reader writes "One of the oldest pieces of the Linux desktop stack still widely in use today is the X Window System that today is commonly referred to as X11 or in recent years the X.Org Server. The X Window System predates the Linux kernel, the Free Software Foundation, GCC, and other key pieces of the Linux infrastructure — or most software widely-used in general. Today marks 30 years since the announcement of X at MIT when it was introduced to Project Athena." X wasn't new when I first saw it, on Sun workstations the summer before I started college. When did you first encounter it?

An anonymous reader writes that XWayland is nearly ready to be merged into the main X.org tree "X.Org Server 1.16 this summer should support XWayland, the means of allowing X11 applications to run atop Wayland-based compositors without the need for any application/game changes. With the revised design, XWayland has generic 2D acceleration over OpenGL and a cleaner design compared to earlier revisions. With GNOME 3.12 having better Wayland support and Plasma Next around the corner, it looks like 2014 could be the year of Wayland's take-off!" The patch series emails have more details. The big news here is that XWayland is ditching its old DDX model for one based on Glamor. eliminating the need for any X.org drivers to be written to support X11 on Wayland: "Finally, the last patch adds the Xwayland DDX. Initially Xwayland was an Xorg module that exposed an API for Xorg video drivers to hook into so that we could reuse the native 2D acceleration. Now that glamor is credible and still improving, a much better approach is to make Xwayland its own DDX and use glamor for acceleration. A lot of the code in the Xorg approach was busy preventing Xorg being Xorg, eg, preventing VT access, preventing input driver loading, preventing drivers doing modesetting. The new DDX in contrast is straight-forward, clean code, only 2500 lines of code and neatly self-contained." It does not yet have direct rendering or any acceleration, but those patches should come soon.

The Glamor driver for X11 has sought for years to replace all of the GPU-specific 2D rendering acceleration code in X.org with portable, high performance OpenGL. Unfortunately, that goal was hampered by the project starting in the awkward time when folks thought fixed-function hardware was still worth supporting. But, according to Keith Packard, the last few months have seen the code modernized and finally maturing as a credible replacement for many of the hardware-specific 2D acceleration backends. From his weblog: "Fast forward to the last six months. Eric has spent a bunch of time cleaning up Glamor internals, and in fact he’s had it merged into the core X server for version 1.16 which will be coming up this July. Within the Glamor code base, he's been cleaning some internal structures up and making life more tolerable for Glamor developers. ... A big part of the cleanup was a transition all of the extension function calls to use his other new project, libepoxy, which provides a sane, consistent and performant API to OpenGL extensions for Linux, Mac OS and Windows." Keith Packard dove in and replaced the Glamor acceleration for core text and points (points in X11 are particularly difficult to accelerate quickly) in just a few days. Text performance is now significantly faster than the software version (not that anyone is using core text any more, but "they’re often one of the hardest things to do efficiently with a heavy weight GPU interface, and OpenGL can be amazingly heavy weight if you let it."). For points, he moved vertex transformation to the GPU getting it up to the same speed as the software implementation. Looking forward, he wrote "Having managed to accelerate 17 of the 392 operations in x11perf, it’s pretty clear that I could spend a bunch of time just stepping through each of the remaining ones and working on them. Before doing that, we want to try and work out some general principles about how to handle core X fill styles. Moving all of the stipple and tile computation to the GPU will help reduce the amount of code necessary to fill rectangles and spans, along with improving performance, assuming the above exercise generalizes to other primitives." Code is available in anholt's and keithp's xserver branches.

An anonymous reader writes "The recent report of X11/X.Org security in bad shape rings more truth today. The X.Org Foundation announced today that they've found a X11 security issue that dates back to 1991. The issue is a possible stack buffer overflow that could lead to privilege escalation to root and affects all versions of the X Server back to X11R5. After the vulnerability being in the code-base for 23 years, it was finally uncovered via the automated cppcheck static analysis utility." There's a scanf used when loading BDF fonts that can overflow using a carefully crafted font. Watch out for those obsolete early-90s bitmap fonts.

An anonymous reader writes "A belated holiday gift for Linux users is the X.Org Server 1.15 'Egg Nog' release. X.Org Server 1.15 presents new features including DRI3 — a big update to their rendering model — a rewrite of the GLX windowing system code, support for Mesa Mega Drivers, and many bug fixes plus polishing. The release, though, goes without any mainline support for XWayland to ease the adoption of the Wayland Display Server while maintaining legacy X11 application support."

jones_supa writes "As can be recalled, Mir didn't make it to the Ubuntu 13.10 release to replace X.org as the display server. Back then it suffered of problems in multi-monitor support, along with other issues. Now it turns out that Canonical's product will not make it even into the next LTS version (14.04) of the Ubuntu desktop. Mir itself would be ready for showtime in the schedule, but there are problems with XMir, which is the X11 compatibility layer that ensures Mir can work with applications built for X. The comments came at the Ubuntu Developer Summit: in an online event Mark Shuttleworth stressed that the 14.04 desktop has to be rock-solid for customers with large-scale deployments, such as educational institutions. In the meantime, you can already try out Mir in your Ubuntu system."

Riskable writes "Ever seen a remote desktop tool that's fast/efficient enough to play back video? Gate One will soon have that capability via the forthcoming X11 support (as demonstrated in the video). I am posting this to Slashdot looking for suggestions and feedback as to how I should move forward with it before I solidify the architecture, API, and even the business end of it (making money). I'll be watching the thread and replying to comments (as I have time). Also, if you're interested you can sign up to be notified when it's available." We've posted a few stories about Gate One previously.

sfcrazy writes "Chromium developers have started porting Chromium to X11 alternatives such as Wayland. Tiago Vignatti sent a message to the freedesktop mailing list, 'Today we are launching publicly Ozone-Wayland, which is the implementation of Chromium's Ozone for supporting Wayland graphics system. Different projects based on Chromium/Blink like the Chrome browser, ChromeOS, among others can be enabled now using Wayland.'"

jones_supa writes "Things are starting to look even better for the status of open specifications for AMD Radeon HD hardware. AMD's Alex Deucher announced via his personal blog that programming guides and register specifications on the 3D engines for the Evergreen, Northern Islands, Southern Islands, and Sea Islands GPUs are now in the NDA-free public domain. These parts represent the 3D engines on the Radeon HD 5000 through Radeon HD 8000 series graphics processors."

An anonymous reader writes "Ubuntu 13.10 is due for release later this month, and the Ubuntu developers were planning to replace the native X Server with Mir/XMir as Canonical's next-generation Ubuntu display server. However, they have now decided Mir will not be the Ubuntu 13.10 default on the desktop over the XMir X11 compatibility layer suffering multi-monitor issues and other problems. Canonical still says they will use Mir for Ubuntu Touch 13.10 images and remain committed to the Mir project."