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

digiKam 7.7.0 is released

After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. Read more

Dilution and Misuse of the "Linux" Brand

Samsung, Red Hat to Work on Linux Drivers for Future Tech

The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. Read more

today's howtos

  • How to install go1.19beta on Ubuntu 22.04 – NextGenTips

    In this tutorial, we are going to explore how to install go on Ubuntu 22.04 Golang is an open-source programming language that is easy to learn and use. It is built-in concurrency and has a robust standard library. It is reliable, builds fast, and efficient software that scales fast. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel-type systems enable flexible and modular program constructions. Go compiles quickly to machine code and has the convenience of garbage collection and the power of run-time reflection. In this guide, we are going to learn how to install golang 1.19beta on Ubuntu 22.04. Go 1.19beta1 is not yet released. There is so much work in progress with all the documentation.

  • molecule test: failed to connect to bus in systemd container - openQA bites

    Ansible Molecule is a project to help you test your ansible roles. I’m using molecule for automatically testing the ansible roles of geekoops.

  • How To Install MongoDB on AlmaLinux 9 - idroot

    In this tutorial, we will show you how to install MongoDB on AlmaLinux 9. For those of you who didn’t know, MongoDB is a high-performance, highly scalable document-oriented NoSQL database. Unlike in SQL databases where data is stored in rows and columns inside tables, in MongoDB, data is structured in JSON-like format inside records which are referred to as documents. The open-source attribute of MongoDB as a database software makes it an ideal candidate for almost any database-related project. This article assumes you have at least basic knowledge of Linux, know how to use the shell, and most importantly, you host your site on your own VPS. The installation is quite simple and assumes you are running in the root account, if not you may need to add ‘sudo‘ to the commands to get root privileges. I will show you the step-by-step installation of the MongoDB NoSQL database on AlmaLinux 9. You can follow the same instructions for CentOS and Rocky Linux.

  • An introduction (and how-to) to Plugin Loader for the Steam Deck. - Invidious
  • Self-host a Ghost Blog With Traefik

    Ghost is a very popular open-source content management system. Started as an alternative to WordPress and it went on to become an alternative to Substack by focusing on membership and newsletter. The creators of Ghost offer managed Pro hosting but it may not fit everyone's budget. Alternatively, you can self-host it on your own cloud servers. On Linux handbook, we already have a guide on deploying Ghost with Docker in a reverse proxy setup. Instead of Ngnix reverse proxy, you can also use another software called Traefik with Docker. It is a popular open-source cloud-native application proxy, API Gateway, Edge-router, and more. I use Traefik to secure my websites using an SSL certificate obtained from Let's Encrypt. Once deployed, Traefik can automatically manage your certificates and their renewals. In this tutorial, I'll share the necessary steps for deploying a Ghost blog with Docker and Traefik.