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

Today in Techrights

today's howtos

  • Hans de Goede: Changing hidden/locked BIOS settings under Linux

    This all started with a Mele PCG09 before testing Linux on this I took a quick look under Windows and the device-manager there showed an exclamation mark next to a Realtek 8723BS bluetooth device, so BT did not work. Under Linux I quickly found out why, the device actually uses a Broadcom Wifi/BT chipset attached over SDIO/an UART for the Wifi resp. BT parts. The UART connected BT part was described in the ACPI tables with a HID (Hardware-ID) of "OBDA8723", not good. Now I could have easily fixed this with an extra initrd with DSDT-overrride but that did not feel right. There was an option in the BIOS which actually controls what HID gets advertised for the Wifi/BT named "WIFI" which was set to "RTL8723" which obviously is wrong, but that option was grayed out. So instead of going for the DSDT-override I really want to be able to change that BIOS option and set it to the right value. Some duckduckgo-ing found this blogpost on changing locked BIOS settings.

  • Test Day:2021-05-09 Kernel 5.12.2 on Fedora 34

    All logs report PASSED for each test done and uploaded as prompted at instruction page.

  • James Hunt: Can you handle an argument?

    This post explores some of the darker corners of command-line parsing that some may be unaware of. [...] No, I’m not questioning your debating skills, I’m referring to parsing command-lines! Parsing command-line option is something most programmers need to deal with at some point. Every language of note provides some sort of facility for handling command-line options. All a programmer needs to do is skim read the docs or grab the sample code, tweak to taste, et voila! But is it that simple? Do you really understand what is going on? I would suggest that most programmers really don’t think that much about it. Handling the parsing of command-line options is just something you bolt on to your codebase. And then you move onto the more interesting stuff. Yes, it really does tend to be that easy and everything just works… most of the time. Most? I hit an interesting issue recently which expanded in scope somewhat. It might raise an eyebrow for some or be a minor bomb-shell for others.

  • 10 Very Stupid Linux Commands [ Some Of Them Deadly ]

    If you are reading this page then you are like all of us a Linux fan, also you are using the command line every day and absolutely love Linux. But even in love and marriage there are things that make you just a little bit annoyed. Here in this article we are going to show you some of the most stupid Linux commands that a person can find.

China Is Launching A New Alternative To Google Summer of Code, Outreachy

The Institute of Software Chinese Academy of Sciences (ISCAS) in cooperation with the Chinese openEuler Linux distribution have been working on their own project akin to Google Summer of Code and Outreachy for paying university-aged students to become involved in open-source software development. "Summer 2021" as the initiative is simply called or "Summer 2021 of Open Source Promotion Plan" is providing university-aged students around the world funding by the Institute of Software Chinese Academy of Sciences to work on community open-source projects. It's just like Google Summer of Code but with offering different funding levels based upon the complexity of the project -- funding options are 12000 RMB, 9000 RMB, or 6000 RMB. That's roughly $932 to $1,865 USD for students to devote their summer to working on open-source. There are not any gender/nationality restrictions with this initative but students must be at least eighteen years old. Read more

Kernel: Linux 5.10 and Linux 5.13

  • Linux 5.10 LTS Will Be Maintained Through End Of Year 2026 - Phoronix

    Linux 5.10 as the latest Long Term Support release when announced was only going to be maintained until the end of 2022 but following enough companies stepping up to help with testing, Linux 5.10 LTS will now be maintained until the end of year 2026. Linux 5.10 LTS was originally just going to be maintained until the end of next year while prior kernels like Linux 5.4 LTS are being maintained until 2024 or even Linux 4.19 LTS and 4.14 LTS going into 2024. Linux 5.10 LTS was short to begin with due to the limited number of developers/organizations helping to test new point release candidates and/or committing resources to using this kernel LTS series. But now there are enough participants committing to it that Greg Kroah-Hartman confirmed he along with Sasha Levin will maintain the kernel through December 2026.

  • Oracle Continues Working On The Maple Tree For The Linux Kernel

    Oracle engineers have continued working on the "Maple Tree" data structure for the Linux kernel as an RCU-safe, range-based B-tree designed to make efficient use of modern processor caches. Sent out last year was the RFC patch series of Maple Tree for the Linux kernel to introduce this new data structure and make initial use of it. Sent out last week was the latest 94 patches in a post-RFC state for introducing this data structure.

  • Linux 5.13 Brings Simplified Retpolines Handling - Phoronix

    In addition to work like Linux 5.13 addressing some network overhead caused by Retpolines, this next kernel's return trampoline implementation itself is seeing a simplification. Merged as part of x86/core last week for the Linux 5.13 kernel were enabling PPIN support for Xeon Sapphire Rapids, KProbes improvements, and other minor changes plus simplifying the Retpolines implementation used by some CPUs as part of the Spectre V2 mitigations. The x86/core pull request for Linux 5.13 also re-sorts and better documents Intel's increasingly long list of different CPU cores/models.

  • Linux 5.13 Adds Support For SPI NOR One-Time Programmable Memory Regions - Phoronix

    The Linux 5.13 kernel has initial support for dealing with SPI one-time programmable (OTP) flash memory regions. Linux 5.13 adds the new MTD OTP functions for accessing SPI one-time programmable data. The OTP are memory regions intended to be programmed once and can be used for permanent secure identification, immutable properties, and similar purposes. In addition to adding the core infrastructure support for OTP to the MTD SPI-NOR code in Linux 5.13, the functionality is wired up for Winbond and similar flash memory chips. The MTD subsystem has already supported OTP areas but not for SPI-NOR flash memory.