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.
Slashdot is powered by your submissions, so send in your scoop
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."
An anonymous reader writes "One week ahead of the GNOME 3.10 release, all of the basic Wayland support for GNOME has been merged. With today's GNOME Shell 3.9.92 release the Wayland branch was merged and there was also an updated Mutter Wayland release, besides earlier GNOME 3.9.x packages fostering the Wayland support. Fedora 20 is expected to ship with GNOME on Wayland as a technology preview. Additional details about the current GNOME Wayland support are available from the GNOME Wiki."
An anonymous reader writes "Canonical has announced today that they intend to ship the Mir Display Server by default in Ubuntu 13.10, rather than Ubuntu 14.04 as originally planned. They moved ahead their Mir adoption since the code is materializing and they want Mir/XMir widely tested prior to the Ubuntu 14.04 Long-Term Support release. Mir in Ubuntu 13.10 will be using the XMir X11 compatibility layer to run the Unity 7 desktop and there will be fallback support for running an X.Org Server if the graphics drivers don't support Mir."
An anonymous reader writes "Through the use of XMir, a translation layer for running legacy X11 applications atop Ubuntu's forthcoming Mir display server, the GNOME Shell, Xfce, and LXDE desktops now run on this X.Org Server alternative. With XMir, the traditional window managers are still running while Mir treats these desktops as a single window."
An anonymous reader writes "With the upcoming KDE 4.11, there's an initial Wayland backend through the KWin manager. The author notes on his blog: 'Once the system is fully started you can just use it. If everything works fine, you should not even notice any difference, though there are still limitations, like only the three mouse buttons of my touchpad are supported ;-)'"
An anonymous reader writes "In clearing up common misconceptions about Wayland (e.g. it breaking compatibility with the Linux desktop and it not supporting remote desktops like X), Eric Griffith (a Linux developer) and Daniel Stone (a veteran X.Org developer) have written The Wayland Situation in which they clearly explain the facts about the shortcomings of X, the corrections made by Wayland, and the advantages to this alternative to Canonical's in-development Mir."
An anonymous reader writes "Six months after the release of Wayland 1.0, versions 1.1 of Wayland and Weston have been released. Wayland/Weston 1.1 brings new back-end support for the Raspberry Pi, Pixman renderer, Microsoft Remote Desktop Protocol (RDP), and FBDEV frame-buffer device. Wayland/Weston 1.1 also introduces a modules SDK, supports the EGL buffer-age extension, touch-screen calibration support, and numerous optimizations and bug-fixes."
An anonymous reader writes "Canonical Desktop and Mobile Engineer Christopher Halse Rogers explains in more detail the decision for Mir as apposed to Wayland. Although Halse Rogers 'was not involved in the original decision to create Mir,' he's had 'discussions with those who were.' 'We want something like Wayland, but different in almost all the details.' 'The upsides of doing our own thing — we can do exactly and only what we want, we can build an easily-testable codebase, we can use our own infrastructure, we don't have an additional layer of upstream review.' In a separate post Halse Rogers answer the question: Does this fragment the Linux graphics driver space?"
First time accepted submitter taikedz writes "Citrix Xenapp with Receiver/Metaframe allows publishing individual applications installed on a Windows server to users on remote machines. These applications open in their own windows, along side others as if they were installed locally. I am looking to do the same at home, with free software, publishing applications from Mac, Linux, and Windows machines (and yes, I've verified the license agreements for the apps I am going to do this with!). Up until now, the only alternatives I have found are full-on remote desktop login, not seamlessly-integrated. Can you recommend any tools that can achieve the goal of remote individual application access across platforms for free or at low-cost?"
jones_supa writes "The SDL developers Ryan Gordon and Sam Lantinga have proposed a window manager change to work out the full-screen X11 window mess, primarily for games. The proposal is to come up with a _NET_WM_STATE_FULLSCREEN_EXCLUSIVE window manager hint that works out the shortcomings of the full-screen hint used currently by most games, _NET_WM_STATE_FULLSCREEN. Ryan and Sam have already worked out an initial patch for SDL but they haven't tried hooking it to any window manager yet. Those interested in the details, information is available from this mailing list message. One of the key changes is that software would make the request to the window manager to change the resolution, rather than tapping RandR or XVidMode directly. Martin Gräßlin of KDE was rather wary about the patch and said that games changing the resolution just tend to mess up the desktop." Seems like a reasonable idea, given a bit of time to mature as a spec. In KDE's case, a separate daemon from the window manager handles resolution changes so going through the WM would add complexity, and the plasma shell still has no way to realize that it shouldn't reflow the desktop widgets. Setting window properties seems like a sensible IPC method for communicating intent though (without making yet another aspect of the X desktop reliant upon the not-very-network-transparent dbus): "hey, I need to resize, but just for me so don't reshuffle the desktop and docks."