Slashdot Mirror

"There is no reason for the open-source community to worry..." writes Daniel Stone, who heads the graphics team at open-source consultancy Collabora. mfilion quotes Collabora.com: Recently, Sean Paul from Google's ChromeOS team, submitted a patch series to enable HDCP support for the Intel display driver. HDCP is used to encrypt content over HDMI and DisplayPort links, which can only be decoded by trusted devices... However, if you already run your own code on a free device, HDCP is an irrelevance and does not reduce freedom in any way....

HDCP support is implemented almost entirely in the hardware. Rather than adding a mandatory encryption layer for content, the HDCP kernel support is dormant unless userspace explicitly requests an encrypted link. It then attempts to enable encryption in the hardware and informs userspace of the result. So there's the first out: if you don't want to use HDCP, then don't enable it! The kernel doesn't force anything on an unwilling userspace.... HDCP is only downstream facing: it allows your computer to trust that the device it has been plugged into is trusted by the HDCP certification authority, and nothing more. It does not reduce user freedom, or impose any additional limitations on device usage.

An anonymous reader writes: While many of you have likely heard of the "RADV" open-source Vulkan driver, it's been a community-written driver up to this point in the absence of AMD's official, cross-platform Vulkan driver being open-source. That's now changed with AMD now open-sourcing their official Vulkan driver. The code drop is imminent and they are encouraging the use of it for quick support of new AMD hardware, access to the Radeon GPU Profiler, easy integration of AMD Vulkan extensions, and enabling third-party extensions. For now at least it does provide better Vulkan performance than RADV but the RADV developers have indicated they plan to continue development of their Mesa-based Vulkan driver.

An anonymous reader writes: Mesa3D developers have announced the release of Mesa 12.0. Mesa 12 notably adds open-source OpenGL 4.3 drivers for Intel, Radeon, and NVIDIA on Linux, and it also integrates the previously open-sourced Intel Vulkan graphics API driver. From the Phoronix analysis, "Mesa 12.0 is easily one of the biggest updates to this important open-source user-space OpenGL driver stack in quite some time and will offer much better support and features especially for Intel, Radeon, and NVIDIA open-source Linux desktop users/gamers." You can download Mesa 3D Graphics Library 12.0.0 here.

An anonymous reader writes: Mesa3D developers have announced the release of Mesa 12.0. Mesa 12 notably adds open-source OpenGL 4.3 drivers for Intel, Radeon, and NVIDIA on Linux, and it also integrates the previously open-sourced Intel Vulkan graphics API driver. From the Phoronix analysis, "Mesa 12.0 is easily one of the biggest updates to this important open-source user-space OpenGL driver stack in quite some time and will offer much better support and features especially for Intel, Radeon, and NVIDIA open-source Linux desktop users/gamers." You can download Mesa 3D Graphics Library 12.0.0 here.

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: Intel is open-sourcing their work on creating a high-performance graphics software rasterizer that originally was developed for scientific visualizations. Intel is planning to integrate this new OpenSWR project with Mesa to deploy it on the Linux desktop as a faster software rasterizer than what's currently available (LLVMpipe). OpenSWR should be ideal for cases where there isn't a discrete GPU available or the drivers fail to function. This software rasterizer implements OpenGL 3.2 on Intel/AMD CPUs supporting AVX(2) (Sandy Bridge / Bulldozer and newer) while being 29~51x faster than LLVMpipe and the code is MIT licensed. The code prior to being integrated in Mesa is offered on GitHub.

An anonymous reader writes: Wayland 1.9 and the reference Weston compositor have been ported to DragonFlyBSD. Significant changes were made to get Wayland/Weston running, and you must either already be running an X.Org Server or be using the Linux-ported Radeon and Intel kernel mode-setting drivers, plus jump through a few setup steps.

jj110888 writes: Mesa, the open source implementation of OpenGL, has just announced version 11.0. This adds support for the amdgpu driver, fixes for non-Windows platforms, new OpenGL ES extensions supported, and more. Most notable is the support for all extensions in OpenGL 4.1 by the radeonsi and nvc0 drivers, and support for extensions added in OpenGL 4.2 by the i965 driver. This brings the OpenGL version supported by core Mesa from 3.3 to 4.2, five and a half years after OpenGL 4 was released. Mesamatrix gives the status of which OpenGL extensions are supported by which open source driver. Vulkan, on the otherhand, will have an open source driver once the spec is released.

jones_supa writes: Lennart Poettering, the creator of the controversial init system and service manager for Linux-based operating systems has announced the first systemd conference. The systemd.conf will take place November 5-7, in Berlin, Germany. systemd developers and hackers, DevOps professionals, and Linux distribution packagers will be able to attend various workshops, as well as to collaborate with their fellow developers and plan the future of the project. Attendees will also be able to participate in an extended hackfest event, as well as numerous presentations held by important names in the systemd project, including Poettering himself.

An anonymous reader writes: The Mesa 3D project that is the basis of the open-source Linux/BSD graphics drivers now supports OpenGL 4.0 and most of OpenGL 4.1~4.2. The OpenGL 4.0 enablement code landed in Mesa Git yesterday/today and more GL 4.1/4.2 patches are currently being reviewed for the Intel, Radeon, and Nouveau open-source GPU drivers.

An anonymous reader writes: NVIDIA's latest mark of their newly discovered open-source kindness is beginning to provide open-source hardware reference headers for their latest GK20A/GM20B Tegra GPUs while they are working to also provide hardware header files on their older GPUs. These programming header files in turn will help the development of the open-source Nouveau driver as up to this point they have had to do much of the development via reverse-engineering. Perhaps most interesting is that moving forward they would like to use the Nouveau kernel driver code-base as the primary development environment for new hardware.

An anonymous reader writes: The Nouveau driver developers working on open-source support for the GeForce 900 Maxwell graphics cards have found this new generation to be "very open-source unfriendly" and restricting. NVIDIA began requiring signed firmware images, which they have yet to provide to Nouveau developers, contrary to their earlier statements. The open-source developers have also found their firmware signing to go beyond just simple security precautions. For now the open-source NVIDIA driver can only enable displays with the GTX 900 series without any hardware acceleration.

jones_supa writes: The 1.7.0 release of Wayland is now available for download. The project thanks all who have contributed, and especially the desktop environments and client applications that now converse using Wayland. In an official announcement from Bryce Harrington of Samsung, he says the Wayland protocol may be considered 'done' but that doesn't mean there's not work to be done. A bigger importance is now given to testing, documentation, and bugfixing. As Wayland is maturing, we are also getting closer to the point where the big Linux distros will eventually start integrating it to their operating system.

jones_supa writes: The 1.7.0 release of Wayland is now available for download. The project thanks all who have contributed, and especially the desktop environments and client applications that now converse using Wayland. In an official announcement from Bryce Harrington of Samsung, he says the Wayland protocol may be considered 'done' but that doesn't mean there's not work to be done. A bigger importance is now given to testing, documentation, and bugfixing. As Wayland is maturing, we are also getting closer to the point where the big Linux distros will eventually start integrating it to their operating system.

New submitter mrons writes: Many new features are coming for systemd. This includes the ability to do a full secure boot. As Lennart Poettering mentions in a Google+ comment: "This is really just about providing the tools to implement the full trust chain from the firmware to the host OS, if SecureBoot is available. ... Of course, if you don't have EFI SecureBoot, than nothing changes. Also if you turn it off, than nothing changes either. [sic]" Phoronix notes, "Gummiboot is a simple UEFI boot manager that's been around for a few years but only receives new work from time-to-time. Lennart and Kay Sievers are looking at adding Gummiboot to systemd to complete the safety chain of the boot process with UEFI Secure Boot. Systemd will communicate with this UEFI boot loader to ensure the system didn't boot into a compromised state."

jones_supa writes A lot of development work is happening on systemd with just the recent couple of weeks seeing over 200 commits. With the most recent work that has landed, the networkd component has been improved with new features. Among the additions are IP forwarding and masquerading support (patch). This is the minimal support needed and these settings get turned on by default for container network interfaces. Also added was minimal firewall manipulation helpers for systemd's networkd. The firewall manipulation helpers (patch) are used for establishing NAT rules. This support in systemd is provided by libiptc, the library used for communicating with the Linux kernel's Netfilter and changing iptables firewall rulesets. Those wishing to follow systemd development on a daily basis and see what is actually happening under the hood, can keep tabs via the systemd Git viewer.

jones_supa writes A lot of development work is happening on systemd with just the recent couple of weeks seeing over 200 commits. With the most recent work that has landed, the networkd component has been improved with new features. Among the additions are IP forwarding and masquerading support (patch). This is the minimal support needed and these settings get turned on by default for container network interfaces. Also added was minimal firewall manipulation helpers for systemd's networkd. The firewall manipulation helpers (patch) are used for establishing NAT rules. This support in systemd is provided by libiptc, the library used for communicating with the Linux kernel's Netfilter and changing iptables firewall rulesets. Those wishing to follow systemd development on a daily basis and see what is actually happening under the hood, can keep tabs via the systemd Git viewer.

jones_supa writes A lot of development work is happening on systemd with just the recent couple of weeks seeing over 200 commits. With the most recent work that has landed, the networkd component has been improved with new features. Among the additions are IP forwarding and masquerading support (patch). This is the minimal support needed and these settings get turned on by default for container network interfaces. Also added was minimal firewall manipulation helpers for systemd's networkd. The firewall manipulation helpers (patch) are used for establishing NAT rules. This support in systemd is provided by libiptc, the library used for communicating with the Linux kernel's Netfilter and changing iptables firewall rulesets. Those wishing to follow systemd development on a daily basis and see what is actually happening under the hood, can keep tabs via the systemd Git viewer.

An anonymous reader writes Some of the worst X.Org security issues were just publicized in an X.Org security advisory. The vulnerabilities deal with protocol handling issues and led to 12 CVEs published and code dating back to 1987 is affected within X11. Fixes for the X Server are temporarily available via this Git repository.

An anonymous reader writes: For over two years there's been a Freedreno driver project that's been reverse-engineering Qualcomm's Adreno graphics hardware. Freedreno consists of both a user-space Gallium3D driver providing OpenGL / OpenGL ES support and a DRM/KMS kernel driver to replace Qualcomm's open-source kernel driver designed just around Android's needs. The community-based, reverse-engineering Freedreno driver project is finally paying off and gaining critical momentum with Qualcomm now contributing to the driver. QuIC through the Aurora Forum provided Adreno A4xx hardware support to the Freedreno MSM kernel driver.

An anonymous reader writes: In a blow to those working on open-source drivers, soft-mods for enhancing graphics cards, and the Chinese knock-offs of graphics cards, NVIDIA has begun signing and validating GPU firmware images. With the latest-generation Maxwell GPUs, not all engine functionality is being exposed unless the hardware detects the firmware image was signed by NVIDIA. This is a setback to the open-source Nouveau Linux graphics driver but they're working towards a solution where NVIDIA can provide signed, closed-source firmware images to the driver project for redistribution. Initially the lack of a signed firmware image will prevent some thermal-related bits from being programmed but with future hardware the list of requirements is expected to rise.

An anonymous reader writes: In a blow to those working on open-source drivers, soft-mods for enhancing graphics cards, and the Chinese knock-offs of graphics cards, NVIDIA has begun signing and validating GPU firmware images. With the latest-generation Maxwell GPUs, not all engine functionality is being exposed unless the hardware detects the firmware image was signed by NVIDIA. This is a setback to the open-source Nouveau Linux graphics driver but they're working towards a solution where NVIDIA can provide signed, closed-source firmware images to the driver project for redistribution. Initially the lack of a signed firmware image will prevent some thermal-related bits from being programmed but with future hardware the list of requirements is expected to rise.

An anonymous reader writes Through a Google Summer of Code project this year was work to emulate systemd on OpenBSD. Upstream systemd remains uninterested in supporting non-Linux platforms so a student developer has taken to implementing the APIs of important systemd components so that they translate into native systemd calls. The work achieved this summer was developing replacements for the systemd-hostnamed, systemd-localed, systemd-timedated, and systemd-logind utilities. The hope is to allow for systemd-dependent components like more recent versions of GNOME to now run on OpenBSD.

An anonymous reader writes "NVIDIA's latest rare open-source contribution is adding Gallium3D support for the Tegra K1 SoC to the Nouveau Mesa driver. After they added support for the Tegra K1's 'GK20A' Kepler GPU to the Nouveau DRM kernel driver, it was just a small step to get it working with the Gallium3D user-space code as it builds upon work done by the Nouveau developers earlier with reverse-engineering the existing Kepler GeForce graphics cards. When it comes to desktop graphics, NVIDIA is still predominantly pushing their proprietary Linux driver but they have begun contributing hardware and information to Nouveau developers."

An anonymous reader writes "Wayland 1.5 has been released, along with Weston Compositor 1.5. Wayland/Weston 1.5 carry many new user features, with a new libinput back-end, XWayland support, a full-screen shell, and many other changes. This release is particularly important as Fedora 21 will run on GNOME Wayland and X.Org Server 1.16 will be released this summer with integrated XWayland support."

dotancohen (1015143) writes "It is commonly said that open source software is preferable because if you need something changed, you can change it yourself. Well, I am not an Xorg developer and I cannot maintain a separate Xorg fork. Xorg version 1.13.1 introduced a bug which breaks the "Sticky Keys" accessibility option. Thus, handicapped users who rely on the feature cannot use Xorg-based systems with the affected versions and are stuck on older software versions. Though all pre-bug Linux distros are soon scheduled for retirement, there seems to be no fix in sight. Should disabled users stick with outdated, vulnerable, and unsupported Linux distros or should we move to OS-X / Windows?

The prospect of changing my OS, applications, and practices due to such an ostensibly small issue is frightening. Note that we are not discussing 'I don't like change' but rather 'this unintentional change is incompatible with my physical disability.' Thus this is not a case of every change breaks someone's workflow."

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.

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.

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 "AMD's latest feature added to their open-source Radeon DRM graphics driver is VCE video encoding via a large code drop that happened this morning. A patched kernel and Mesa will now allow the Radeon driver with their latest-generation hardware to provide low-latency H.264 video encoding on the GPU rather than CPU. The support is still being tuned and it only supports the VCE2 engine but the patches can be found on the mailing list until they land in the trunk in the coming months."

An anonymous reader writes "NVIDIA's next-generation Tegra K1 ARM processor now has open-source support for its Kepler-based graphics. NVIDIA decided to submit a large queue of patches to the open-source, reverse-engineered Nouveau project for supporting their ARM Kepler graphics with the open-source driver. The patches are still experimental but this is the first time NVIDIA has contributed open-source code to Nouveau."

An anonymous reader writes "NVIDIA's next-generation Tegra K1 ARM processor now has open-source support for its Kepler-based graphics. NVIDIA decided to submit a large queue of patches to the open-source, reverse-engineered Nouveau project for supporting their ARM Kepler graphics with the open-source driver. The patches are still experimental but this is the first time NVIDIA has contributed open-source code to Nouveau."

An anonymous reader writes "With the latest open source Linux code published today the AMD RadeonSI Gallium3D driver supports OpenGL 3.3 and GLSL 1.50; this is the open source Linux graphics driver used for Radeon HD 7000 series and newer, including the new Hawaii GPUs. The OpenGL 3.3 support appeared in patches spread across Mesa and LLVM that should appear in their next releases. It was also found that the RadeonSI driver is becoming a lot faster and starting to compete with Catalyst, AMD's notorious Linux binary driver."

An anonymous reader writes "Version 1.4 of the Wayland protocol and Weston reference compositor have been released. The Wayland/Weston 1.4 release delivers on many features and includes promoting the sub-surface protocol to official Wayland, improved touch screen support, a crop/scale protocol within Weston, security improvements, and other fixes."

An anonymous reader writes "Version 1.4 of the Wayland protocol and Weston reference compositor have been released. The Wayland/Weston 1.4 release delivers on many features and includes promoting the sub-surface protocol to official Wayland, improved touch screen support, a crop/scale protocol within Weston, security improvements, and other fixes."

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."

Via Phoronix comes news that the new DRM driver for the Freedreno driver for Qualcomm Snapdragon Adreno graphics is gaining a few new features in Linux 3.13: "After a year of working on the 'Freedreno' Gallium3D user-space driver and getting that up to speed for Qualcomm Adreno/Snapdragon support, for the past few months he's been working on a complementary kernel driver rather than relying upon Qualcomm's Android-focused kernel layer. ... The work that Rob has ready for Linux 3.13 with this Qualcomm DRM graphics driver is DRI PRIME support, support for render nodes, updated header files, plane support, and a couple of other changes."

An anonymous reader writes "NVIDIA was caught removing features from their Linux driver and days later Linux developers have caught and confirmed AMD imposing artificial limitations on their graphics cards in the DVI-to-HDMI adapters that their driver will support. Over years AMD has quietly been adding an extra EEPROM chip to their DVI-to-HDMI adapters that are bundled with Radeon HD graphics cards. Only when these identified adapters are detected via checks in their Windows and Linux Catalyst driver is HDMI audio enabled. If using a third-party DVI-to-HDMI adapter, HDMI audio support is disabled by the Catalyst driver. Open-source Linux developers have found this to be a self-imposed limitation and that the open-source AMD Linux driver will work fine with any DVI-to-HDMI adapter."

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.'"

sl4shd0rk writes "Nvidia, perhaps inspired by the infamous Torvalds Salute, has decided to do something about its crummy image with Open Source developers. The company has begun to release public documentation on certain aspects of its GPUs. Reactions from developers have been mixed; much of what's already been released wasn't a big mystery, but Nvidia says more is coming and they will also provide guidance in needed areas as well. Linus said, 'I'm cautiously optimistic that this is a real shift in how Nvidia perceives Linux. The actual docs released so far are fairly limited, and in themselves they wouldn't be a big thing, but if Nvidia really does follow up and start opening up more, that would certainly be great. They've already been much better in the ARM SoC space than they were on the more traditional GPU side, and I really hope that some day I can just apologize for ever giving them the finger.'"

An anonymous reader writes "Just days after Intel added XMir support to their Linux graphics driver so it would work with the in-development the X11 compatibility layer to the Mir display server premiering with Ubuntu 13.10, Intel management has rejected the action and had the XMir patch reverted. There's been controversy surrounding Mir with it competing with Wayland and the state of the display server being rather immature and its performance coming up short while it will still debut in Ubuntu 13.10. Intel management had to say, "We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream." As a result, Canonical will need to ship their own packaged version of the Intel (and AMD and Nouveau drivers) with out-of-tree patches."

An anonymous reader writes "Wayland 1.2 & Weston 1.2 have been released. Features of this quarterly update to the X.Org/Mir display competitor is support for color management, a new input method framework, a Raspberry Pi renderer/back-end, HiDPI output scaling, multi-seat improvements, and various other changes for this next-generation Linux desktop display protocol and compositor."

An anonymous reader writes "AMD's open-source developer has posted an incredible set of 165 patches against the Linux kernel that provide support for a few major features to their Linux graphics driver. Namely, the open-source Radeon Linux driver now supports dynamic power management on hardware going back to the Radeon HD 2000 (R600) generation. The inability to re-clock the GPU frequencies and voltages dynamically based upon load has been a major limiting factor for open-source AMD users where laptops have been warm and there is diminished battery power. The patches also provide basic support for the AMD Radeon HD 8000 'Sea Islands' graphics processors on their open-source Linux driver."

DeviceGuru writes "BeagleBoard.org has begun shipping its faster, cheaper BeagleBone Black SBC with a new Linux 3.8 kernel, supporting Device Tree technology for more streamlined ARM development. The $45 BeagleBone Black runs Linux or Android on a 1GHz TI Sitara AM3359 SOC, doubles the RAM to 512MB of its predecessor, and adds a micro-HDMI port. The updated kernel gives the BeagleBone Black access to a new Direct Rendering Manager (DRM) display driver architecture, as well as full support for the Device Tree data structure introduced to streamline ARM development in Linux 3.7. The project was hesitant to move up to such a recent kernel, but decided it was time to bite the bullet and support the Device Tree. By doing the hard work of switching to Device Tree now, BeagleBoard.org and its developer community can save a lot of configuration and maintenance headaches down the line, says BeagleBoard.org co-founder Jason Kridner. Fortunately, a modified 3.2 kernel 'coming soon' should provide the necessary bridge from the old cape driver architecture to the new one."

An anonymous reader writes "Intel has released its first version of Beignet, an open-source OpenCL run-time and LLVM back-end for Linux that uses LLVM/Clang and is compatible with Ivy Bridge processors. Right now there's partial support for OpenCL 1.0 and 1.1 along with other basic functionality." This is not using Gallium 3D, and at least David Arlie thinks it should not be an fd.o project because it duplicates functionality already present in Mesa.

An anonymous reader writes "Intel has released its first version of Beignet, an open-source OpenCL run-time and LLVM back-end for Linux that uses LLVM/Clang and is compatible with Ivy Bridge processors. Right now there's partial support for OpenCL 1.0 and 1.1 along with other basic functionality." This is not using Gallium 3D, and at least David Arlie thinks it should not be an fd.o project because it duplicates functionality already present in Mesa.

An anonymous reader writes "Intel has released its first version of Beignet, an open-source OpenCL run-time and LLVM back-end for Linux that uses LLVM/Clang and is compatible with Ivy Bridge processors. Right now there's partial support for OpenCL 1.0 and 1.1 along with other basic functionality." This is not using Gallium 3D, and at least David Arlie thinks it should not be an fd.o project because it duplicates functionality already present in Mesa.

New submitter Skrapion writes "One month ago, an independent developer submitted patches to the Wayland's Weston compositor which adds support for FreeRDP, an open-source remote desktop protocol. Now, after six revisions, the remote desktop code has been merged into the trunk. While remote desktop has been prototyped in Weston once before by Wayland developer Kristian Høgsberg, this is the first time Wayland/Weston has officially supported the feature. For a summary of why we can expect Wayland's remote desktop to surpass X.Org's network transparency, see Daniel Stone's excellent talk from Linux.conf.au."

In his typical fashion of replacing perfectly working software with useless broken-by-design crap, our dearest Lennart has decided that the time has come for systemd to gain an email program. He determined that the GNU libc was insufficient for the task of a dbus-enabled cpu hogging email client, leading to the new systemd libc: " Technically, this move makes perfectly sense, too. We are sick of supporting unstable glibc APIs and ABIs, and we believe that we greatly benefit from the fact that we now finally have everything the OS userspace consists of in one single repository. Of course, this new libc is not available to Ubuntu and other Linux distributions that have not yet adopted systemd. However, after deliberately choosing a home-grown display server (Wayland) over the generally accepted one (Mir) we decided creating an incompatible libc would be the best approach to create a strong platform following a strict release cadence."

On the bright side "We also renamed the API call creat() to create()..."