Language Selection

English French German Italian Portuguese Spanish

Graphics: Nouveau, Wayland's Weston and Libinput

Filed under
  • The Open-Source NVIDIA "Nouveau" Driver Gets A Batch Of Fixes For Linux 5.3

    Originally on Thursday was finally the Nouveau-next 5.3 pull request that offered improvements to the display color management, fixes to Secure Boot on newer hardware, and Turing TU116 mode-setting support. But that was rejected by the DRM maintainers for being way too late as usually the cut-off for new feature material is when hitting RC6 on the previous cycle, just not days before the end of the current merge window. Not that those changes were all too exciting or notable, but this pushes back the color management and other work to Linux 5.4.

    Nouveau DRM maintainer Ben Skeggs of Red Hat as a result today sent in Nouveau-fixes 5.3. This pull request has support still for the TU116 GPU since that shouldn't regress any existing support as well as having fixes around KMS, a memory leak, and a few other basic fixes.

  • Wayland's Weston Lands A Pipewire Plug-In As New Remote Desktop Streaming Option

    Wayland's Weston compositor for the past year has provided a remoting plug-in for virtual output streaming that was built atop RTP/GStreamer. Now though a new plug-in has landed in the Weston code-base making use of Red Hat's promising PipeWire project.

    The PipeWire plug-in was merged into Weston today and is similar to the GStreamer-powered remoting plug-in but instead leverages PipeWire. The compositor's frames are exported to PipeWire and the same virtual output API is shared between these plug-ins. The virtual outputs can be configured using the weston.ini configuration file. Any PipeWire client in turn can read these frames.

  • Libinput 1.14 RC Arrives With Better Thumb Detection & Dell Canvas Totem Support

    Linux input expert Peter Hutterer of Red Hat shipped the much anticipated release candidate today for libinput 1.14, the open-source input handling library used by both X.Org and Wayland systems.

  • libinput 1.13.901
    The first RC for libinput 1.14 is now available.
    We have new and improved thumb detection for touchpads, thanks to Matt
    Mayfield. On Clickpad devices this should make interactions where a thumb is
    resting on the touchpad or dropped during an interaction more reliable. A
    summary of the changes can be found here:
    The Dell Canvas Totem is now supported by libinput. It is exposed as a new
    tool type through the tablet interface along with two new axes. Note that
    this is only low-level support, the actual integration of the totem needs
    Wayland protocol changes and significant changes in all applications that
    want to make use of it. A summary of the changes can be found here:
    Touch-capable tablets now tie both devices together for rotation. If you set
    the tablet to left-handed, the touchpad will be rotated along with the
    tablet. Note that this does not affect the left-handed-ness of the touchpad,
    merely the rotation. 
    Tablet proximity out handling for tablets that are unreliably sending
    proximity out events is now always timeout-based. It is no longer necessary
    to add per-device quirks to enable this feature and it is completely
    transparent on devices that work correctly anyway. A summar of the
    changes can be found here:
    Tablets that send duplicate tools (BTN_TOOL_PEN and BTN_TOOL_ERASER) now
    ignore the latter. This is an intermediate fix only but at least makes those
    tablets more usable than they are now. Issue #259 is the tracker for this
    particular behaviour if you are affected by it.
    The handling of kernel fuzz has been slightly improved. Where our udev rule
    fails to reset the fuzz on the kernel device, we disable the hysteresis and
    rely on the kernel now to handle it. Previously our hysteresis would take
    effect on top of the kernel's, causing nonresponsive behaviour.
    Note to distribitors: the python-evdev dependency has been dropped, the
    tools that used it are now using python-libevdev instead.
    And of course a random assortment of fixes, improvements, etc. Many thanks
    to all contributors and testers.
    As usual, the git shortlog is below.

Network transparency with Wayland

  • Network transparency with Wayland

    Three large changes have been completed this week. The first is a change to the wire format used for waypipe. The previous protocol, dating back almost to the start of this project, sent a single large message containing a series of subblocks, each of which either contained Wayland protocol data, indicated that a new file descriptor was sent by the connected Wayland program, or provided all the information needed to update a given file descriptor. These file descriptor update messages used a 16-byte header containing the object id, size, type, and a very overloaded metadata field. Furthermore, the content following the header was sometimes context-dependent. For example, the first data transfer to replicate a shared memory buffer sent its initial data, while all successive messages sent a diff relative to the previous state. Because so much in the update messages was implicit, the code acquired a few unusual workarounds; for example, size extensions to a shared memory buffer were only supported by assuming the newly extended region to have contained all zeros and then sending a diff relative to that state.

    The replacement wire format protocol operates with much smaller transfer units, with distinct types for the various file operations that used to be combined into a single generic header. To keep individual message sizes small, file data update operations can be split into distinct messages corresponding to different shards of a buffer. While having distinct messages for each operation does very slightly increase the bandwidth needed for a connection, it ensures that operations can be performed as soon as the corresponding message block arrives; a remote pipe or video-type DMABUF can be created before the data for its contents has fully arrived.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Late Coverage of Confidential Computing Consortium

  • Microsoft Partners With Google, Intel, And Others To Form Data Protection Consortium

    The software maker joined Google Cloud, Intel, IBM, Alibaba, Arm, Baidu, Red Hat, Swisscom, and Tencent to establish the Confidential Computing Consortium, a group committed to providing better private data protection, promoting the use of confidential computing, and advancing open source standards among members of the technology community.

  • #OSSUMMIT: Confidential Computing Consortium Takes Shape to Enable Secure Collaboration

    At the Open Source Summit in San Diego, California on August 21, the Linux Foundation announced the formation of the Confidential Computing Consortium. Confidential computing is an approach using encrypted data that enables organizations to share and collaborate, while still maintaining privacy. Among the initial backers of the effort are Alibaba, Arm, Baidu, Google Cloud, IBM, Intel, Microsoft, Red Hat, Swisscom and Tencent. “The context of confidential computing is that we can actually use the data encrypted while programs are working on it,” John Gossman, distinguished engineer at Microsoft, said during a keynote presentation announcing the new effort. Initially there are three projects that are part of the Confidential Computing Consortium, with an expectation that more will be added over time. Microsoft has contributed its Open Enclave SDK, Red Hat is contributing the Enarx project for Trusted Execution Environments and Intel is contributing its Software Guard Extensions (SGX) software development kit. Lorie Wigle, general manager, platform security product management at Intel, explained that Intel has had a capability built into some of its processors called software guard which essentially provides a hardware-based capability for protecting an area of memory.

Graphics: Mesa Radeon Vulkan Driver and SPIR-V Support For OpenGL 4.6

  • Mesa Radeon Vulkan Driver Sees ~30% Performance Boost For APUs

    Mesa's RADV Radeon Vulkan driver just saw a big performance optimization land to benefit APUs like Raven Ridge and Picasso, simply systems with no dedicated video memory. The change by Feral's Alex Smith puts the uncached GTT type at a higher index than the visible vRAM type for these configurations without dedicated vRAM, namely APUs.

  • Intel Iris Gallium3D Is Close With SPIR-V Support For OpenGL 4.6

    This week saw OpenGL 4.6 support finally merged for Intel's i965 Mesa driver and will be part of the upcoming Mesa 19.2 release. Not landed yet but coming soon is the newer Intel "Iris" Gallium3D driver also seeing OpenGL 4.6 support. Iris Gallium3D has been at OpenGL 4.5 support and is quite near as well with its OpenGL 4.6 support thanks to the shared NIR support and more with the rest of the Intel open-source graphics stack. Though it's looking less likely that OpenGL 4.6 support would be back-ported to Mesa 19.2 for Iris, but we'll see.

The GPD MicroPC in 3 Minutes [Video Review]

In it I tackle the GPD MicroPC with Ubuntu MATE 19.10. I touch on the same points made in my full text review, but with the added bonus of moving images to illustrate my points, rather than words. Read more Also: WiringPi - Deprecated

today's howtos