Language Selection

English French German Italian Portuguese Spanish

Graphics: Alpha of Wayland's Weston 9.0, Emulating Input Devices In Wayland, Raspberry Pi 4 "V3DV" Vulkan Driver and X.Org/X11 Security

Filed under
Graphics/Benchmarks

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

More on the X.Org Issue

  • X.org security fixes address potential ASLR bypass, heap corruption

    The X.Org project has announced two security advisories that impact Xserver and libX11. The first advisory for X server is regarding uninitialized memory in AllocatePixmap() that could lead to address space layout randomization bypass. The second, impacting libX11, is a heap corruption caused by integer overflows and signed/unsigned comparisons.

Comment viewing options

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

More in Tux Machines

Linux Foundation Broadens Relationship With Surveillance

  • Facebook joins The Linux Foundation as a platinum member

    Most web-based companies are built on Linux and open-source software. Two-billion member social network Facebook is no different. For years, Facebook has not only relied on open-source, it's been an active contributor to major open-source projects. These include the React JavaScript library; the Open Compute Project, which open sources data-center hardware; and Linux's cGroup2 container software. Now Facebook is joining The Linux Foundation membership at the Platinum level. [...] While Facebook has been criticized for how it deals with privacy and politics, it has impeccable open-source credentials. It was already the lead contributor of many Linux Foundation-hosted projects, such as Presto, GraphQL, Osquery, and ONNX. The company also employs many Linux kernel key developers and maintainers.

  • Amundsen Joins LF AI as New Incubation Project

    LF AI Foundation (LF AI), the organization building an ecosystem to sustain open source innovation in artificial intelligence (AI), machine learning (ML), and deep learning (DL), today is announcing Amundsen as its latest Incubation Project.

  • LF AI Accepts Amundsen as Incubation Project

    The Amundsen data discovery project has joined the LF AI as an incubation project. Amundsen is a data discovery and metadata engine aiming to improve the productivity of data analysts, data scientists and engineers by indexing data resources. “Think of it as Google search for data,” the LF AI announcement said.

Graphics: Mesa 20.2 RC2 and DXVK 1.7.1

  • mesa 20.2.0-rc2
    Hi list,
    
    Available today is mesa 20.2.0-rc2. This is the second release candidate for
    the 20.2 release. Currently our open to close ratio on blocking bugs is looking
    really good. This release is dominated by changes to radeonsi, radv, and aco,
    with a few additional changes sneaking in for freedreno, meson,  etnaviv,
    st/mesa, anv, and a few utility fixes.
    
    Dylan
    
    
  • Mesa 20.2-RC2 Released With Many Fixes For RadeonSI + RADV Drivers

    The second weekly release candidate of the forthcoming Mesa 20.2 is now available for testing. Mesa 20.2 is aiming for release around the end of August or early September depending upon how the bug situation plays out. This quarterly feature release to Mesa3D brings many new Vulkan extensions, the RADV driver using ACO by default, initial support for Navi 2 GPUs, initial support for Intel Rocket Lake and DG1, OpenGL 4.3 for LLVMpipe, and much more as outlined in last week's article.

  • DXVK 1.7.1 Released With Many Game Fixes For Direct3D Over Vulkan

    It's been nearly three months without a new DXVK release for mapping Direct3D 9/10/11 atop the Vulkan API while finally today there is a big feature release out. DXVK 1.7.1 was released a few minutes ago as the first update since May. While the version number isn't significant, this version does have many changes.

  • Direct3D to Vulkan translation layer DXVK 1.7.1 is out, lots of game fixes

    After a few months since 1.7 went out, DXVK 1.7.1 is now live to further improve Direct3D to Vulkan translation. This is the project that helps to power Proton, the compatibility layer for Steam Play. This release adds support for newer Vulkan extensions, fixes bugs and has new GPU driver requirements. On the driver side, the VK_EXT_transform_feedback extension is now required which has been supported in drivers on Linux since late 2018 / early 2019. Specifically you will need at least NVIDIA 415.22 and for AMD / Intel it looks like Mesa 19 covers both.

Devices/Embedded: Raspberry Pi and Android Devices

  • Indoor air quality HAT for Raspberry Pi boasts high-res TVOC sensor

    Avnet’s $49.95 “Renesas ZMOD4410 Indoor Air Quality HAT for Raspberry Pi” can be used to measure volatile organic compounds, humidity, and temperature, as well as estimate carbon dioxide levels. Avnet has launched a Renesas ZMOD4410 Indoor Air Quality HAT for Raspberry Pi (AES-RHSEN-ZM44-G) that joins other indoor air quality measurement add-ons for the Pi including Metriful’s $44.50 Sense module and Pimoroni’s $57 Enviro+ pHAT. The ZMOD4410 HAT lacks some of the extras of those boards, but appears to offer a higher quality total volatile organic compound (TVOC) sensor with its Renesas ZMOD4410, which offers resolution ranging from parts-per-billion to parts-per-million.

  • Tiny module and dev kit run RT Linux on STM32MP1

    Exor’s 25.4 x 25.4mm, extended temp “NanoSOM nS02” module runs real-time Linux and its XPlatform industrial IoT software on a soldered, 800MHz STM32MP157 with up to 1GB DDR3L and 32GB eMMC. An “OpenHMI nS02” dev kit with 5-inch touchscreen is optional. Italian embedded technology firm Exor Embedded has launched a NanoSOM nS02 module that runs real-time Linux on the new 800MHz version of ST’s dual-core, Cortex-A7 based STM32MP157. As with the recent, Apollo Lake based, FPGA-enabled GigaSOM GS01 module, Exor announced the product with Arrow, which will be distributing the module and an OpenHMI nS02 Development Kit (see farther below).

  • Zidoo Z10 Pro & Z9X Realtek RTD1619DR 4K Android Media Players Launched for $229 and up

    We previously wrote about some upcoming Realtek RTD1619 media players targeting the videophone and audiophile crowd, and expected them to launch very soon with models from Zidoo and Dune HD. Zidoo has now launched two models with the awaited Zidoo Z9X and a new, higher-end Zidoo Z10 Pro which can be purchased on Aliexpress for respectively $229 and $349 with free shipping.

  • Snapdragon 626 Powered Rugged Tablet Comes with NFC, RFID and Barcode Readers

    Estone Technology has launched another rugged tablet with UA-80 IP-67 waterproof rated, and MIL-STD-810G compliant rugged Android tablet powered by a Qualcomm Snapdragon 626 mobile platform driving an 8″ capacitive touchscreen display.

Python Programming

  • Announcing the new Jupyter Book

    Jupyter Book is an open source project for building beautiful, publication-quality books, websites, and documents from source material that contains computational content. With this post, we’re happy to announce that Jupyter Book has been re-written from the ground up, making it easier to install, faster to use, and able to create more complex publishing content in your books. It is now supported by the Executable Book Project, an open community that builds open source tools for interactive and executable documents in the Jupyter ecosystem and beyond.

  • Holdgraf: Announcing the new Jupyter Book

    On the Jupyter blog, Chris Holdgraf announces a rewrite of the Jupyter Book project. LWN looked at Jupyter and its interactive notebooks for Python and other languages back in 2018; Jupyter Book extends the notebook idea.

  • EuroPython 2020: Live Stream Recordings available

    We’re happy to announce the public availability of the live stream recordings from EuroPython 2020. They were already available to all conference attendees since the sprint days.

  • Learn Any Programming Language with This Learning Plan

    All it takes to master any programming language is the right learning plan. If you know anything about programming you should be aware that often you can’t tell whether what you are doing is wrong until it’s too late. That’s what makes programming a frustrating skill to master — long hours doing the wrong things. But hey, whether you want to make programming your full-time job or just a hobby, you can always make the learning curve less steep. The secret to getting it right with coding is this: have a learning plan! While the plan will not do the hard lifting for you, it will definitely provide the much-needed elbow grease to keep you grounded and focused as you learn programming.

  • Deploying Django to AWS ECS with Terraform

    In this tutorial, we'll look at how to deploy a Django app to AWS ECS with Terraform.

  • Matt Layman: Rendering Calendars - Building SaaS #68

    In this episode, I worked on rendering a calendar of important events in a school year. We built out the appropriate data structures, and I wrote some new model methods and added tests. On the last stream, I created a new model to track breaks in the school year. The app now shows the calendar for the school year, and I want to display the breaks on the calendar. Before digging too far into the code, I provided my thoughts about using Docker for development from a question that came from the chat.