Graphics: Alpha of Wayland's Weston 9.0, Emulating Input Devices In Wayland, Raspberry Pi 4 "V3DV" Vulkan Driver and X.Org/X11 Security
-
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.
- Login or register to post comments
- Printer-friendly version
- 4130 reads
- PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is releasedAfter 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. |
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future TechThe 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. |
today's howtos
|
More on the X.Org Issue
X.org security fixes address potential ASLR bypass, heap corruption