Language Selection

English French German Italian Portuguese Spanish

Kernel: Linux 4.20 (or 5.0) Changes and Graphics

Filed under
  • Lots Of USB & Char/Misc Driver Churn For The Linux 4.20/5.0 Kernel Cycle

    Greg Kroah-Hartman began sending in his feature pull requests this morning for the newly-started Linux 4.20~5.0 kernel cycle.

  • Linux 4.20 Scheduler To Better Deal With "Misfit" Tasks On ARM big.LITTLE Systems

    The next Linux kernel has scheduler improvements that will benefit some tasks when running on ARM big.LITTLE type systems where select CPU cores are more much more powerful than the other cores.

    With the scheduler updates for the Linux 4.20~5.0 kernel, the kernel will now better migrate CPU-intense tasks on asymmetric CPU capacity systems. In particular, for most modern/high-end ARM SoCs with a "big.LITTLE" design where some of the ARM cores are much faster but consume more power and are complemented by lower-power cores like the ARM Cortex-A53.

  • AMDVLK Driver Still Being Fixed Up For Steam Play / Proton, Wayland Improvements

    The developers working on the official AMD Vulkan Windows/Linux driver have done their weekly push of the latest code to the open-source AMDVLK repositories. 

    AMDVLK remains close to the upstream, internal state of the official AMD Vulkan driver but with continuing to use its LLVM-based compiler back-end while the Windows/Linux official Vulkan driver builds continue using the internal AMD proprietary compiler back-end. There continues to be work in the direction of switching over the LLVM back-end everywhere, but it doesn't appear to be ready yet.

  • QEMU Making Progress With Legacy-Free Display Support - Avoids Old VGA Code

    As part of QEMU's emulated display support they have long had a lot of old VGA/SVGA support code around. But as that code is overly complex, has been prone to security issues, and less used these days with modern interfaces, the developers behind this important piece of the open-source virtualization stack have been working on eliminating the legacy display support. 

    With the current QEMU 3.0 release they introduced the new Bochs-Display device that doesn't depend upon VGA compatibility, is implemented from scratch, OVMF supports it for UEFI support, is compatible with the Bochs DRM/KMS Linux driver, and is all around in good shape for UEFI guests compared to the standard VGA (stdvga) display code.

More in Tux Machines

Games: Don't Starve Together, Cthulhu Saves the World, EVERSPACE 2 and Stadia

  • Don't Starve Together has a big free update adding in boats and a strange island

    Klei Entertainment have given the gift of new features to their co-op survival game Don't Starve Together, with the Turn of Tides update now available. Taking a little inspiration from the Shipwrecked DLC available for the single-player version Don't Starve, this new free update enables you to build a boat to carry you and other survivors across the sea. Turn of Tides is the first part of a larger update chain they're calling Return of Them, so I'm excited to see what else is going to come to DST.

  • Cthulhu Saves the World has an unofficial Linux port available

    In response to an announcement to a sequel to Cthulhu Saves the World, Ethan Lee AKA flibitijibibo has made a unofficial port for the original and a few other previously Windows-only games. As a quick reminder FNA is a reimplementation of the proprietary XNA API created by Micrsosoft and quite a few games were made with that technology. We’ve gotten several ports thanks to FNA over the years though Ethan himself has mostly moved on to other projects like working on FAudio and Steam Play.

  • EVERSPACE 2 announced, with more of a focus on exploration and it will release for Linux

    EVERSPACE is probably one of my absolute favourite space shooters from the last few years, so I'm extremely excited to see EVERSPACE 2 be announced and confirmed for Linux. For the Linux confirmation, I reached out on Twitter where the developer replied with "#Linux support scheduled for full release in 2021!".

  • Google reveal more games with the latest Stadia Connect, including Cyberpunk 2077

    Today, Google went back to YouTube to show off an impressive list of games coming to their Stadia game streaming service, which we already know is powered by Debian Linux and Vulkan. As a reminder, Google said not to see Stadia as if it was the "Netflix of games", as it's clearly not. Stadia Base requires you to buy all your games as normal, with Stadia Pro ($9.99 monthly) giving you a trickle of free games to access on top of 4K and surround sound support.

Programming: WebAssembly, Mozilla GFX, Qt and Python

  • WebAssembly for speed and code reuse

    Imagine translating a non-web application, written in a high-level language, into a binary module ready for the web. This translation could be done without any change whatsoever to the non-web application's source code. A browser can download the newly translated module efficiently and execute the module in the sandbox. The executing web module can interact seamlessly with other web technologies—with JavaScript (JS) in particular. Welcome to WebAssembly. As befits a language with assembly in the name, WebAssembly is low-level. But this low-level character encourages optimization: the just-in-time (JIT) compiler of the browser's virtual machine can translate portable WebAssembly code into fast, platform-specific machine code. A WebAssembly module thereby becomes an executable suited for compute-bound tasks such as number crunching. Which high-level languages compile into WebAssembly? The list is growing, but the original candidates were C, C++, and Rust. Let's call these three the systems languages, as they are meant for systems programming and high-performance applications programming. The systems languages share two features that suit them for compilation into WebAssembly. The next section gets into the details, which sets up full code examples (in C and TypeScript) together with samples from WebAssembly's own text format language.

  • Mozilla GFX: moz://gfx newsletter #47

    Hi there! Time for another mozilla graphics newsletter. In the comments section of the previous newsletter, Michael asked about the relation between WebRender and WebGL, I’ll try give a short answer here. Both WebRender and WebGL need access to the GPU to do their work. At the moment both of them use the OpenGL API, either directly or through ANGLE which emulates OpenGL on top of D3D11. They, however, each work with their own OpenGL context. Frames produced with WebGL are sent to WebRender as texture handles. WebRender, at the API level, has a single entry point for images, video frames, canvases, in short for every grid of pixels in some flavor of RGB format, be them CPU-side buffers or already in GPU memory as is normally the case for WebGL. In order to share textures between separate OpenGL contexts we rely on platform-specific APIs such as EGLImage and DXGI. Beyond that there isn’t any fancy interaction between WebGL and WebRender. The latter sees the former as a image producer just like 2D canvases, video decoders and plain static images.

  • The Titler Revamp: QML Producer in the making

    At the beginning of this month, I started testing out the new producer as I had a good, rough structure for the producer code, and was only facing a few minor problems. Initially, I was unclear about how exactly the producer is going to be used by the titler so I took a small step back and spent some time figuring out how kdenlivetitle worked, which is the producer in use. Initially, I faced integration problems (which are the ones you’d normally expect) when I tried to make use of the QmlRenderer library for rendering and loading QML templates – and most of them were resolved by a simple refactoring of the QmlRenderer library source code. To give an example, the producer traditionally stores the QML template in global variables which is taken as a character pointer argument (which is, again, traditional C) The QmlRenderer lib takes a QUrl as its parameters for loading the Qml file, so to solve this problem all I had to do was to overload the loadQml() method with one which could accommodate the producer’s needs – which worked perfectly fine. As a consequence, I also had to compartmentalise (further) the rendering process so now we have 3 methods which go sequentially when we want to render something using the library ( initialiseRenderParams( ) -> prepareRenderer( ) -> renderQml( ) ) [...] The problem was resolved (thank you JB) finally and it was not due to OpenGL but it was simply because I hadn’t created an QApplication for the producer (which is necessary for qt producers). The whole month’s been a steep curve, definitely not easy, but, I enjoyed it! Right now, I have a producer which is, now, almost complete and with a little more tweaking, will be put to use, hopefully. I’m still facing a few minor issues which I hope to resolve soon and get a working producer. Once we get that, I can start work on the Kdenlive side. Let’s hope for the best!

  • How to Make a Discord Bot in Python

    In a world where video games are so important to so many people, communication and community around games are vital. Discord offers both of those and more in one well-designed package. In this tutorial, you’ll learn how to make a Discord bot in Python so that you can make the most of this fantastic platform.

  • Qt Visual Studio Tools 2.4 RC Released

    The Visual Studio Project System is widely used as the build system of choice for C++ projects in VS. Under the hood, MSBuild provides the project file format and build framework. The Qt VS Tools make use of the extensibility of MSBuild to provide design-time and build-time integration of Qt in VS projects — toward the end of the post we have a closer look at how that integration works and what changed in the new release. Up to this point, the Qt VS Tools extension managed its own project settings in an isolated manner. This approach prevented the integration of Qt in Visual Studio to fully benefit from the features of VS projects and MSBuild. Significantly, it was not possible to have Qt settings vary according to the build configuration (e.g. having a different list of selected Qt modules for different configurations), including Qt itself: only one version/build of Qt could be selected and would apply to all configurations, a significant drawback in the case of multi-platform projects. Another important limitation that users of the Qt VS Tools have reported is the lack of support for importing Qt-related settings from shared property sheet files. This feature allows settings in VS projects to be shared within a team or organization, thus providing a single source for that information. Up to now, this was not possible to do with settings managed by the Qt VS Tools.

Screenshots/Screencasts: 10 GNU/Linux Distros (Screenshots) and New Screencast/Video of Endeavour OS 2019.08.17

  • 10 Linux distros: From different to dangerous

    One of the great benefits of Linux is the ability to roll your own. Throughout the years, individuals, organizations, and even nation states have done just that. In this gallery, we're going to showcase some of those distros. Be careful, though. You may not want to load these, or if you do, put them in isolated VMs. We're not kidding when we say they could be dangerous.

  • Endeavour OS 2019.08.17 Run Through

    In this video, we are looking at Endeavour OS 2019.08.17.

A Cycle of Renewal, Broken: How Big Tech and Big Media Abuse Copyright Law to Slay Competition

In 1950, a television salesman named Robert Tarlton put together a consortium of TV merchants in the town of Lansford, Pennsylvania to erect an antenna tall enough to pull down signals from Philadelphia, about 90 miles to the southeast. The antenna connected to a web of cables that the consortium strung up and down the streets of Lansford, bringing big-city TV to their customers — and making TV ownership for Lansfordites far more attractive. Though hobbyists had been jury-rigging their own "community antenna television" networks since 1948, no one had ever tried to go into business with such an operation. The first commercial cable TV company was born. The rise of cable over the following years kicked off decades of political controversy over whether the cable operators should be allowed to stay in business, seeing as they were retransmitting broadcast signals without payment or permission and collecting money for the service. Broadcasters took a dim view of people using their signals without permission, which is a little rich, given that the broadcasting industry itself owed its existence to the ability to play sound recordings over the air without permission or payment. The FCC brokered a series of compromises in the years that followed, coming up with complex rules governing which signals a cable operator could retransmit, which ones they must retransmit, and how much all this would cost. The end result was a second way to get TV, one that made peace with—and grew alongside—broadcasters, eventually coming to dominate how we get cable TV in our homes. By 1976, cable and broadcasters joined forces to fight a new technology: home video recorders, starting with Sony's Betamax recorders. In the eyes of the cable operators, broadcasters, and movie studios, these were as illegitimate as the playing of records over the air had been, or as retransmitting those broadcasts over cable had been. Lawsuits over the VCR continued for the next eight years. In 1984, the Supreme Court finally weighed in, legalizing the VCR, and finding that new technologies were not illegal under copyright law if they were "capable of substantial noninfringing uses." Read more