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

Open source mind mapping with Draw.io

There's something special about maps. I remember opening the front book cover of JRR Tolkien's The Hobbit when I was younger, staring at the hand-drawn map of Middle Earth, and feeling the wealth of possibility contained in the simple drawing. Aside from their obvious purpose of actually describing where things are in relation to other things, I think maps do a great job of expressing potential. You could step outside and take the road this way or that way, and if you do, just think of all the new and exciting things you'll be able to see. Read more

19 Absolute Simple Things About Linux Terminal Every Ubuntu User Should Know

Terminal often intimidates new users. However, once you get to know it, you gradually start liking it. Well, that happens with most Linux users. Even if you are using Ubuntu as a desktop system, you may have to enter the terminal at times. New users are often clueless about many things. Some knowledge of basic Linux commands always helps in such cases but this article is not about that. This article focuses on explaining small, basic and often ignored things about using the terminal. This should help new Ubuntu desktop users to know the terminal and use it with slightly more efficiency. Read more

EndeavourOS 21.4 Review [Atlantis] - Pure Arch Linux Experience for You

We review the EndeavourOS 21.4 (Atlantis) — the best Arch Linux flavor for beginners. Read more

today's leftovers

  • Mesa's Classic Drivers Have Been Retired - Affecting ATI R100/R200 & More - Phoronix

    The day has finally come that Mesa's classic OpenGL drivers (non-Gallium3D) have been cleared out of the code-base as part of their modernization effort for mainline. After a half-year pending, the "Delete Mesa Classic" merge request was honored today in eliminating the Mesa "classic" OpenGL drivers from the code-base. The drivers will still be maintained in an "Amber" branch, but considering how little focus these drivers have been receiving by upstream Mesa developers currently, don't expect much (or, if any) real changes moving ahead.

  • Steam support for Chromebooks could surface this week

    After months and months and even more months of waiting, it appears that we may finally get our first look at native Steam gaming on Chrome OS in the very near future. Affectionately known as project ‘Borealis’, the containerized version of Steam has been in the works for nearly two years and it was initially thought that Google was targeting mid to late 2022 for a release. With Chrome OS 96 just rolling out and the next iteration of Google’s desktop operating system not due until January of 2022, it’s fairly clear that this target was missed but that’s okay. I’d rather see a fully baked product released than a buggy piece of software that sours users to Chrome OS. Anyway, in its early development, I presumed that ‘Borealis’, a.k.a. Steam on Chrome OS, would simply be an optimized version of the Steam application that would install and run inside the current Linux container. Over time, we learned that Google was actually creating an entirely new container designed specifically to house Borealis and that it should run independently from the Debian container currently available in Stable Chrome OS. This makes more sense as Google can retain control of the Borealis container and keep it neat and clean for running Steam. Presumably, users will never actually interact with the container like you can with the Linux terminal.

  • iXsystems Recognized in 11th Annual Best in Biz Awards for Most Innovative Product Line of the Year

    TrueNAS by iXsystems is the world’s most popular Open Source storage operating system and is the most efficient solution for managing and sharing data over a network. TrueNAS Open Storage provides unified storage for file, block, object, and application data – making it an exceptionally flexible storage platform for business. All TrueNAS editions -- CORE, Enterprise, and SCALE -- leverage the enterprise-grade OpenZFS file system to provide an all-inclusive data management solution that protects customer data with features like Copy-on-Write, Snapshots, Checksums, Scrubbing, and 2-Copy Metadata.