• Wrap it before you tap it? No, say Linux developers: 'GPL condom' for Nvidia driver is laughed out of the kernel

  Linux devs have dismissed a proposed patch to the kernel that would only work with a Nvidia driver, motivating a second patch that will prevent disguised use of proprietary code in GPL modules.

  The Linux Kernel licensing rules make provision for proprietary third-party modules but state that they must be tagged as such.

  This "cannot be used for modules with source code in the kernel tree. Modules tagged that way are tainting the kernel with the 'P' flag when loaded and the kernel module loader refuses to link such modules against symbols which are exported with EXPORT_SYMBOL_GPL()."

  Facebook developer Jonathan Lemon put forward an RFC (Request for Comments) on a proposal to implement DMA (Direct Memory Access) zero-copy between a network card and a GPU to enhance network performance, while keeping the protocol processing on the CPU. The use case is for "GPUs used for machine learning, which are located near the NICs, and have a high bandwidth PCI connection between the GPU/NIC," states the RFC.

  The code relies on Nvidia's proprietary driver for Linux, noticed by kernel maintainer Greg Kroah-Hartman, who observed: "OK, now you are just trolling us. Nice job, I shouldn't have read the previous patches. Please, go get a lawyer to sign-off on this patch, with their corporate email address on it. That's the only way we could possibly consider something like this."

• Power Management and Thermal Control Microconference Accepted into 2020 Linux Plumbers Conference

  We are pleased to announce that the Power Management and Thermal Control Microconference has been accepted into the 2020 Linux Plumbers Conference!

  Power management and thermal control is an important area in the Linux ecosystem to help with the global environment. Optimizing the amount of work that is achieved while having long battery life and keeping the box from overheating is critical in today’s world. This meeting will focus on continuing to have Linux be an efficient operating system while still lowering the cost of running a data center.

  Last year’s meetup at Linux Plumbers resulted in the introduction of thermal pressure support into the CPU scheduler as well as several improvements to the thermal framework, such as a netlink implementation of thermal notification and improvements to CPU cooling. Discussions from last year also helped to improve systems-wide suspend testing tools.

• Intel Tiger Lake OpenCL Support On Linux Now Considered Production Ready

  With all the recent work on Intel's open-source compute stack around the vector back-end and GPU code generation with their ISPC compiler there was another significant milestone achieved that went unnoticed until spotting the change a few days ago. 

  The open-source Intel Compute Runtime in the past two weeks now has "production" ready OpenCL support for the forthcoming Gen12 Tiger Lake graphics. That's good news with Tiger Lake laptops expected to market soon. 

• RADV ACO Back-End Begins Tackling Navi 2 / GFX10.3 Support

  With the "Sienna Cichlid" and "Navy Flounder" open-source driver support as what appear to be the first "Navi 2" GPUs and the first of the "GFX10.3" generation on the graphics engine side there is the initial kernel support with Linux 5.9 and the initial Mesa support for 20.2. That Mesa support has been focused on RadeonSI as the official OpenGL driver as well as Mesa's RADV driver as the Radeon Vulkan driver in-tree but not officially supported by AMD. That RADV support is currently un-tested. Both drivers currently depend upon the "AMDGPU" back-end found in the forthcoming LLVM 11.0 with its initial GFX10.3 support. But now on the RADV driver side there is preliminary GFX10.3 bits landing for the popular "ACO" back-end. 

  ACO is the back-end worked on by Valve and other stakeholders like open-source graphics driver engineers from Google and Red Hat. But as ACO isn't officially supported by AMD, there hasn't been any patches from them in wiring up the Navi 2 / GFX10.3 support for this AMDGPU LLVM alternative. Rhys Perry as part of Valve's Linux driver efforts though has worked out what should be the initial changes needed for this yet-to-be-released hardware with ACO. 

libinput 1.16.0 is now available.

No significant changes since the second RC, so here's slightly polished RC1
announcement text.

This has been a long cycle, mostly because there weren't any huge changes on
the main development branch and a lot of the minor annoyances have found
their way into the 1.15.x releases anyway.

libinput now monitors timestamps of the events vs the current time when
libinput_dispatch() is called by the compositor. Where the difference
*may* result in issues, a (rate-limited) warning is printed to the log.
So you may see messages popping up in the form of
  "event processing lagging behind by XYZms, your system is too slow"
This is a warning only and has no immediate effect. Previously we would only
notice (and warn about) this when it affected an internal timer. Note that
these warnings do not show an issue with libinput, it shows that the the
compositor is not calling libinput_dispatch() quick enough.

The wheel tilt axis source was deprecated. No device ever had the required
udev properties set so we should stop pretending we support this.

Touchpads now support the "flat" acceleration profile. The default remains
unchanged and this needs to be selected in the configuration interface. The
"flat" profile applies a constant factor to movement deltas (1.0 for the
default speed setting).

Events from lid or tablet-mode switches that are known to libinput as being
unreliable are now filtered and no longer passed to the caller.
This prevents callers from receiving those known-bogus events and having to
replicate the same heuristics to identify unreliable devices that libinput
employs internally.

A new "libinput analyze" debugging tool is the entry tool for analysing
various aspects of devices. Right now the only tool is
"libinput analyze per-slot-delta" which can be used to detect pointer jumps
in a libiput record output. This tool used to live elsewhere, it was moved
to libinput so that reporters can easier run this tool, reducing the load on
the maintainers.

The tools have seen a few minor improvements, e.g.
- "libinput record touchpad.yml" does the right thing, no explicit --output
  argument required
- libinput measure touchpad-pressure has been revamped to be a bit more
  obvious
- libinput measure touchpad-size has been added (as replacement for the
  touchpad-edge-detector tool)
- libinput measure fuzz has been fixed to work (again and) slightly more
  reliable

The libinput test suite has been fixed to avoid interference with the
currently running session. Previously it was virtually impossible to work
while the test suite is running - multiple windows would pop up, the screen
would blank regularly, etc.

And of course a collection of fixes, quirks and new bugs.

As usual, see the git shortlog for details.

Diego Abad A (1):
      FIX: typo on building documentation

Peter Hutterer (2):
      test: semi-fix the switch_suspend_with_touchpad test
      libinput 1.16.0

git tag: 1.16.0

Also: >Libinput 1.16 Released - Ready To Warn You If Your System Is Too Slow

• weston 8.0.91

  This is the alpha release for Weston 9.0.0. This release cycle has been
  pretty quiet, with just a few new features:
  
  
  
  
  - A new kiosk shell allows to display regular desktop apps in an
    always-fullscreen mode
  - Improved testing infrastructure: the test harness has been
    redesigned, DRM tests are now supported, DRM and OpenGL tests are now
    enabled in our CI
  - DRM panel orientation property support
  
  
  
  
  As always, a number of bug fixes are included as well.
  
  
  
  
  Thanks to all contributors!
  
  
  
  
  Full commit history below.
  

       

• Wayland's Weston 9.0 Reaches Alpha

  Weston 9.0 release preparations are getting underway. At least compared to the original Weston 9.0 release plans, this Wayland compositor is running about a month behind those plans but in any case the release is now making its way to reality. 

  On Thursday shortly after the Weston kiosk/full-screen shell was merged, Weston 9.0 Alpha was tagged in getting the release process moving forward. Simor Ser is again serving as release manager. 

• RFC: libei - emulated input in Wayland compositors

  I've been working on a new approach for allowing emulated input devices in
  Wayland. Or in short - how can we make xdotool and synergy work? And
  eventually replace them.
  
  
  
  
  The proposal I have is a library for Emulated Input, in short libei.
    https://gitlab.freedesktop.org/whot/libei/
  
  
  
  
  libei has two parts, the client side (libei) for applications and
  a server side (libeis) for the compositor. The two libraries communicate
  with each other (how? doesn't matter, it's an implementation detail) to
  negotiate input devices.
  
  
  
  
  The process is roughly:
  - the libei client connects and says "I am org.freedesktop.SomeApplication
    and I want a pointer and a keyboard device"
  - the libeis server says "ok, you can have a pointer device and a keyboard
    device"
  - the libei client says 'move the pointer by 1/1', etc. and the server does
    just that. or not, depending on context.
  
  
  
  
  There are more details, see the README in the repo and the libei.h and
  libeis.h header files that describe the API.
  
  
  
  
  The sticking point here is: emulated input comes via a separate channel.
  The server a) knows it's emulated input, b) knows who it is coming from and
  c) has complete control over the input.
  
  
  
  
  a) is interesting because you can differ between the events internally. The
  API right now is very similar to libinput's events so integrating it into a
  compositor should be trivial.
  
  
  
  
  b) is somewhat handwavy if an application runs outside a sandbox - any
  information will be unreliable. Flatpak gives you an app-id though and
  with that we can (eventually) do things like storing the allow/deny
  decisions of the user in the portal implementation.
  
  
  
  
  c) allows you to e.g. suspend the client when convenient or just ignore
  certain sequences altogether. The two made-up examples are: suspend EI
  during a password prompt, or allow EI from the software yubikey *only*
  during a password prompt.
  
  
  
  
  Now, the next question is: how do they *start* talking to each other?
  libei provides multiple backends for the initial connection negotiation. My
  goal is to have this work with flatpak portals so an application running
  within the sandbox can be restricted accordingly. Alternatives to this could
  be public DBus interfaces, simple fd passing or (as is implemented right
  now) a named unix socket.
  
  
  
  
  The aim is that a client can simply iterate through all of the options until
  finds a connection. Once that's found, the actual code for emulating input is
  always the same so it's trivial to implement a client that works on any
  compositor that supports some backend of libeis.
  The server part only needs to care about the negotiation mechanisms it
  allows, i.e. GNOME will only have dbus/portal, sway will only have... dunno,
  fd exchange maybe?
  
  
  
  
  Next: because we have a separate channel for emulated input we can hook up
  XTEST to use libei to talk to a compositor. I have a PoC implementation for
  weston and Xwayland:
    https://gitlab.freedesktop.org/whot/weston/-/commits/wip/eis
    https://gitlab.freedesktop.org/whot/xserver/-/commits/wip/xwayland-eis
  With that xdotool can move the pointer. Note this is truly the most minimal
  code just to illustrate the point but you can fill in the blanks and do
  things like the compositor preventing XTEST or not, etc.
  
  
  
  
  This is all in very early stages with very little error checking so things
  will probably crash or disconnect unexpectedly. I've tried to document the
  API to make the intentions clear but there are still some very handwavy
  bits.
  
  
  
  
  Do let me know if you have any questions or suggestions please though.
  
  
  
  
  Cheers,
    Peter
  
  
  
  
  

• LIBEI Yields New Effort For Emulating Input Devices In Wayland

  Red Hat's input expert Peter Hutterer has started writing another library to help the Linux input ecosystem: LIBEI. This new library is focused on offering emulated input device support for Wayland in order to support use-cases like xdotool for automating input events. 

  The LIBEI library is working to support emulated input use-cases on Wayland to offer functionality akin to X11's xdotool automation software or the Synergy software for sharing keyboard/mouse setups between systems. LIBEI consists of a client library for applications and then a server-side library (LIBEIS) for the Wayland compositor integration. These two libraries communicate with each other for negotiating the emulated input events.

• Alejandro Piñeiro: v3dv status update 2020-07-31

  Pipeline cache objects allow the result of pipeline construction to be reused. Usually (and specifically on our implementation) that means caching compiled shaders. Reuse can be achieved between pipelines creation during the same application run by passing the same pipeline cache object when creating multiple pipelines. Reuse across runs of an application is achieved by retrieving pipeline cache contents in one run of an application, saving the contents, and using them to preinitialize a pipeline cache on a subsequent run.

  Note that it can happens that a pipeline cache would not improve the performance of an application once that it starts to render. This is because application developers are encourage to create all the pipelines in advance, to avoid any hiccup during rendering. On that situation pipeline cache would help to reduce load times. In any case, that is not always avoidable. In that case the pipeline cache would allow to reduce the hiccup, as a cache hit is far faster than a shader recompilation.

  One specific detail about our implementation is that internally we keep a default pipeline cache, used if the user doesn’t provide a pipeline cache when creating a pipeline, and also to cache the custom shaders we use for internal operations. This allowed to simplify our code, discarding some custom caches that had alread implemented.

• Raspberry Pi 4 "V3DV" Vulkan Driver Begins Tackling MSAA, Other Improvements

  This month the Raspberry Pi Foundation funded "V3DV" open-source Vulkan driver for the Raspberry Pi 4 began being able to run vkQuake. In ending out July, the developers at consulting firm Igalia who are working on this driver for the Raspberry Pi Foundation shared some of their latest driver activity. 

        

• X.Org's Latest Security Woes Are Bugs In LibX11, Xserver

  The X.Org/X11 Server has been hit by many security vulnerabilities over the past decade as security researchers eye more open-source software. Some of these vulnerabilities date back to even the 80's and 90's given how X11 has built up over time. The X.Org Server security was previously characterized as being even worse than it looks while today the latest vulnerabilities have been made public. 

  CVE-2020-14344 is now public and covers multiple integer overflows and signed/unsigned comparison issues within the X Input Method implementation in the libX11 library. These issues can lead to heap corruption when handling malformed messages from an input method. 

While we have looked a lot at how the Core i9 10900K performs at the top-end of Intel's Comet Lake line-up as well as with the likes of the i5-10600K and i3-10100, here is our first look at the very bottom of the stack with the new Celeron and Pentium processors. Benchmarked today are the Celeron G5900 as a ~$40 processor and the Pentium Gold G6400 that retails for around $60 and compared against other low-end Intel and AMD processors as well as older Intel Core i3 CPUs.

The Intel Celeron G5900 is one of the lowest-end Comet Lake processors offered. For $42 USD (indeed was able to purchase it for that price) is a dual-core processor with a 3.4GHz clock frequency. The CPU has just a 2MB cache, no turbo frequency, support for dual channel DDR4-2666 memory, no form of AVX support, 2MB L3 cache, UHD Graphics 610 that clock up to 1.05GHz, and a 58 Watt TDP. It's a CPU quite at the bottom of the gutter by 2020 standards.