Feeds

A new FAI version was released and the FAIme service is using this new release. You can now also create installation images for Debian 13 (testing aka Trixie).

https://fai-project.org/FAIme/

Another new feature of the FAIme service will be announced at DebConf24 in August.

Hash-o-Matic 1.0.1 is out! Hash-o-Matic is a tool to compare and generate checksum for your files to verify the authenticity of them. It also verify files via their use PGP signatures.

This new release of Hash-o-Matic provides updated translations and some small visual changes. In the background, the application was ported to the new QML type registration, we now support building Hash-o-Matic on Haiku and we now require released version of KDE Frameworks instead of pre-released version.

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

Qt Academy, the free online platform for learning Qt framework and tools, is constantly updated with new content. Our new learning path made up of 9 courses, is specifically designed for Squish, and offers an ideal baseline for those interested in automated GUI testing. Created by Qt's team of Customer Success Engineers, this path features a comprehensive guide to mastering Squish and will equip you with all the necessary skills to get started with ease. 

KRdp in Plasma 6.1

It's been a while since I posted about KRdp. For those who missed it, KRdp implements a server that exposes a running Plasma session to be controlled by other machines through the RDP protocol.

The biggest news here is that KRdp is now part of Plasma and is being shipped along with the rest of Plasma 6.1. Originally we hoped to be able to include it for Plasma 6.0, but due to the amount of work getting everything else ready for Plasma 6.0 we decided to postpone inclusion to Plasma 6.1. This allowed us to include some fairly important changes that we wanted to include.

What's New

One of the most important changes to be included for Plasma 6.1 is that there is now a KCM in System Settings to configure Remote Desktop support:

Image The new Remote Desktop page in System Settings.

This removes the need for setting things up manually and should make it a lot simpler to get started. This also adds support for logging in with multiple users. This work was mainly done by Akseli Lahtinen, who has been taking over more of the general development work for KRdp.

We also did a fair amount of work on the underlying libraries used for video encoding to improve encoding speed and reduce latency. This should mean that even with software encoding and a slow client, things should remain fairly responsive, even though video quality might suffer somewhat.

Virtual Session Support

One thing that is being asked somewhat often is whether KRdp would allow a remote user to login without a currently running session. Unfortunately, currently that is not supported and there is no clear roadmap for when it will be supported. Remote login requires quite some extra infrastructure to fully work, not only in Plasma but other projects as well.

If you feel this is an important use case for you and you have the ability to work on something like this, feel free to reach out to us to discuss things. Ultimately having someone who is passionate about a use case working on it will ensure things get developed a lot quicker. See the Get Involved page on the KDE Community wiki on how to get started. For KRdp specific questions, feel free to ask them in #plasma on Matrix.

Discuss this post on KDE Discuss

ahiemstra Tue, 06/25/2024 - 10:45

The following text is in German, since we're announcing a regional user group meeting in Düsseldorf, Germany.

Ankündigung

Das nächste Python Meeting Düsseldorf findet an folgendem Termin statt:

03.07.2024, 18:00 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Programm Bereits angemeldete Vorträge

• Charlie Clark:
  Reflections on the importance of APIs in Python
  
• Klaus Bremer:
  Nox
  
• Marc-Andre Lemburg:
  Shipping ready-to-run Python apps without the need to install Python
  
• Jens Diemer:
  Django Find My Device
  
  

Weitere Vorträge können gerne noch angemeldet werden. Bei Interesse, bitte unter info@pyddf.de melden. Startzeit und Ort

Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden.

Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden.

Über dem Eingang steht ein großes "Schwimm’ in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt.

>>> Eingang in Google Street View

⚠️ Wichtig: Bitte nur dann anmelden, wenn ihr absolut sicher seid, dass ihr auch kommt. Angesichts der begrenzten Anzahl Plätze, haben wir kein Verständnis für kurzfristige Absagen oder No-Shows. Einleitung

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet.

Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen.

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

Format

Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning) Talks und offener Diskussion.

Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit HDMI und FullHD Auflösung steht zur Verfügung.

(Lightning) Talk Anmeldung bitte formlos per EMail an info@pyddf.de

Kostenbeteiligung

Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet.

Da Tagungsraum, Beamer, Internet und Getränke Kosten produzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst. Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.

Anmeldung

Da wir nur 25 Personen in dem angemieteten Raum empfangen können, möchten wir bitten, sich vorher anzumelden.

Meeting Anmeldung bitte per Meetup

Weitere Informationen

Weitere Informationen finden Sie auf der Webseite des Meetings:

              https://pyddf.de/

Viel Spaß !

Marc-Andre Lemburg, eGenix.com

Before diving into the differences between SAML (Security Assertion Markup Language) and OAuth 2.0, let's first discuss what they have in common. Both are protocols used for authentication and authorization. While these terms are sometimes mistakenly used interchangeably, they serve distinct purposes. Authentication asks, “Who are you?”, whereas authorization asks, “What are you allowed to do?”.  This means that SAML and OAuth 2.0 are used for very distinctive purposes and work on different mechanisms. The good news is that Drupal integrates really well with both these protocols. In this article, we’ll talk about how different the protocols are from each other and also how to implement them in your Drupal 10 website. What is SAML SAML is an XML-based authentication system that works across different domains. It lets you do Single Sign-On (SSO), so you can access multiple applications with just one set of credentials. Key components of SAML 1. Assertions Assertions are the heart of SAML transactions. They contain information about a user, such as their identity, attributes, and authentication status. SAML defines three types of assertions: Authentication, Attribute, and Authorization Decision. 2. Identity Provider (IdP) The IdP is responsible for authenticating users and generating SAML assertions. It acts as a trusted entity that asserts the identity of users to service providers. 3. Service Provider (SP) It is the application or service a user is trying to access. The SP consumes SAML assertions and makes access control decisions based on the information provided by the IdP. 4. Single Sign-On (SSO): SAML enables SSO, allowing users to authenticate once with the IdP and access multiple SPs without re-entering credentials. The SAML Workflow User Access RequestA user attempts to access a service or application (SP). SP Initiated SSOThe Service Provider (SP) creates an SAML authentication request, initiating the process by redirecting the user to the Identity Provider (IdP). IdP AuthenticationThe IdP authenticates the user. SAML Assertion GenerationUpon successful authentication, the IdP generates a SAML assertion containing user information. Assertion Delivery to SPThe IdP sends the SAML assertion to the user's browser, which then delivers it to the SP. SP ValidationThe SP validates the SAML assertion, and if successful, grants the user access. Image source: Drupal.org Implementing SAML in Drupal 10 Ensure that you have Drupal 10 installed and configured. Ensure that Composer is installed on your local system before proceeding. Install the miniorange_saml Authentication Module: composer require 'drupal/miniorange_saml:^3.0' Enable the module: drush en miniorange_saml Configure your SP’s by following the steps mentioned in the “Readme.md” file of module. Checkout the official documentation of SSO using Google Apps as Identity Provider (IDP).Note: We can also configure SAML to work as an IdP for others which they can use to get sign into other’s platform using our IdP platform (Drupal). For more information please checkout the official documentation here. What is OAuth2 OAuth 2.0 authentication is a method of granting users access to a protected resource, such as a website or application, without sharing their username and password. Instead, the user grants permission to a third-party application, which then accesses the protected resource on their behalf.  This provides an extra layer of security and allows for more control over the user's data.OAuth2 is commonly used for social media, email, and other online services. The thing to note here is that OAuth2 is an authorization mechanism, not an authentication mechanism. Key Components of OAuth2 1. Resource Owner (User) The Resource Owner is an entity (typically a user) that owns the protected resources. These resources could include data, images, or any other type of information. 2. Client The Client, representing the application or service, initiates requests for access to protected resources on behalf of the Resource Owner. It may take the form of a web application, mobile app, or any other software application. 3. Authorization Server This is responsible for authenticating the Resource Owner(User), obtaining their consent, and issuing access tokens. It plays a pivotal role in the OAuth2 workflow, ensuring secure authorization processes. 4. Resource Server The Resource Server is the host for the protected resources that the Client intends to access. It verifies the validity of access tokens provided by the Client and provides the requested resources if the token is deemed valid. 5. Access Token The Access Token is a credential representing the authorization granted to the Client. It is a string that the Client includes in its requests to the Resource Server to access the protected resources. 6. Authorization Grant An Authorization Grant is a credential representing the Resource Owner's authorization for the Client to access their protected resources. There are various types of authorization grants, including authorization codes, implicit grants, client credentials, and resource owner passwords. 7. Redirection URI During the OAuth2 flow, the Client specifies a Redirection URI where the Authorization Server sends the user after authentication and consent. This URI is used to deliver the authorization code or access token back to the Client. 8. Scope The Scope parameter defines the range of the access that the Client is requesting. It specifies the permissions the Client is seeking from the Resource Owner. Scopes can be predefined or defined by the application. 9. Token Endpoint The Token Endpoint is an endpoint on the Authorization Server used by the Client to exchange the Authorization Grant for an Access Token. It plays a crucial role in the OAuth2 Token Exchange process. 10. Refresh Token The Refresh Token is an optional credential that can be used by the Client to obtain a new Access Token without requiring the Resource Owner to reauthenticate. It provides a way to extend the validity of the access. The OAuth2 Workflow The client initiates the authentication process by redirecting the user to the authorization server. The user authenticates with the authorization server and grants permissions to the client. The authorization server grants an access token to the client. The client presents the access token to the resource server to access protected resources on behalf of the user. Image Source: Oracle Implementing OAuth 2.0 in Drupal Let’s take an example of logging into a Drupal site using Google credentials: 1. Install and Enable the OAuth2 Authentication Module Download and install the OAuth2 Authentication respective module from the Drupal.org website or using Composer. Enable the module in the Drupal administration interface. 2. Configure OAuth2 Providers Navigate to the Configuration page and select OAuth2 Authentication settings. Add a new OAuth2 provider configuration by providing details such as client ID, client secret, authorization endpoint, token endpoint, and scope and save configuration. For detailed information please refer to module’s README.md file. 3. Test Authentication Integration Once the OAuth2 provider is configured, Drupal will handle the authentication flow automatically. Test the integration by logging out of Drupal and attempting to log in using the OAuth2 provider credentials. Verify that the authentication process is successful and that user accounts are created or linked appropriately. 4. Secure Access and Manage Permissions Ensure that access tokens are securely stored and transmitted to prevent unauthorized access. Manage permissions and access control settings within Drupal to restrict access to sensitive resources based on user roles and permissions. Key differences between SAML and OAuth2 Feature SAML OAuth2 Purpose Identify and Single Sign-On (SSO) Authorization and Access Control Use Case Authentication or Cross-domain authentication Authorization or Third-party application authorization Protocol Type Authentication protocol Authorization framework Authentication Flow Browser Redirect (POST or Artifact Binding) Redirect or Direct Communication Token Type Assertions (SAML Tokens, typically XML) Access Tokens like: JWT, Bearer Tokens, etc (typically JSON) Token Validations Signature verifications Token validation against Authorization Server Scenarios Often used for enterprise SSO Commonly used in API access and third-party integrations Use with APIs Less common for APIs authrorization Widely used for securing APIs’ and accessing resources Supported by Drupal Yes, via modules such as SimpleSAMLphp Yes, via modules like Social OAuth authentications Integration Complexity More complex due to SSO and identity mapping Generally simpler for basic use cases Use in Mobile Apps Possible, but less common Commonly used for mobile app authentication User Experience Seamless SSO experience for users Transparent authorization for users Examples in Drupal Modules SimpleSAMLphp, Shibboleth OAuth2 Authentication, OAuth2 Server Final Thoughts It's important to note that SAML and OAuth2 serve different purposes, and in some scenarios, they can be used together. For instance, SAML could handle authentication, and OAuth2 could handle authorization in a federated identity scenario. The choice between SAML and OAuth2 often depends on the specific requirements of the application and the use case. Drupal 10 provides modules for both SAML and OAuth2 to accommodate various authentication and authorization needs. Talk to our Drupal experts to find out how we, as a leading Drupal development company, can help build secure, robust, and user-friendly digital solutions with Drupal.

Working as a Drupal contractor can be rewarding and fulfilling, but it also comes with its own set of challenges. In this article, we'll explore 6 tips for boosting productivity and success as an independent contractor. From setting clear goals and priorities to staying organized and keeping your skills up-to-date, these tips can help you be more efficient and effective in your work. We'll also discuss the importance of networking and building relationships, as well as how to negotiate fair and reasonable rates for your services. By following these tips, you can set yourself up for success and enjoy a fulfilling career as an independent Drupal contractor.

The question we want to answer in this blog post is whether Drupal is still the leading CMS platform in 2022 and beyond. If you have been thinking of trying out Drupal, this article will help you decide whether it is still worth it in 2022. Let’s jump right in!

I have been attending Drupal Dev Days for the fifth time and I have to say that this year’s event was as great as the other ones. The tech talks were really interesting and I learned a lot about new trends in the industry. In this article my highlights.

We are working on porting Feeds to Drupal 8 today at the Global Sprints weekend in Amsterdam. We would like to know from you how you use these and similar import/export modules and what functionality you like but still miss in Drupal 8.

As always the Drupal Association puts videe-recording of most sessions on DrupalCon Youtube.
That is also true for the now ongoing DrupalCon New Orleans 2016.
An excellent option for learning and understanding Drupal. (and following the event!)

Drupal 8 is better than Drupal 7. Data-modelling, performance, multi-language. It feels so much more robust this day. More functionality is in-core and fully tested.
In a conceptual way, Drupal 8 is not so different from Drupal 7. The Administration-UI’s are the same and you probably will also use the same modules for a project. Site builders will feel really comfortable.
All-in-all I am getting excited about Drupal 8!

More than 125+ sessions from last week's Drupalcon in Barcelona are on Youtube:

https://www.youtube.com/user/DrupalAssociation/videos

Posted by the Drupal Association.

Hope you can learn from it too!

One little Drupal community secret: the main-event of a DrupalCon might be sprinting... Right now (Saturday 26th Sep) the Drupal community is pushing hard on the first next-gen CMS that will have stable releases early 2016.

This article contains a detailed instruction on how to setup the Entity Translation module for Drupal 7 websites.
Entity Translation is part of Drupal 8 core and its approach is to translate fields instead of full nodes/entities.

Goal of this tutorial is to set up a multilingual website that can be navigated in multiple languages by visitors and to enable the content to be easily manageable by editors / cms administrators.
To get multilingual right, it’s critical that you configure your content-types and fields with care and precision and upfront, because if content is already in your database it is almost impossible to change these configurations.
So let's go.

Recently I was building a Drupal site with Display Suite, Entity Reference and Bootstrap. In this blog I want to share why that combination and some tricks I used to get a great frontend and editor-UX.

This is a bug fix and minor feature release over INN 2.7.1, and the upgrade should be painless. You can download the new release from ISC or my personal INN pages. The latter also has links to the full changelog and the other INN documentation.

For the full list of changes, see the INN 2.7.2 NEWS file.

As always, thanks to Julien ÉLIE for preparing this release and doing most of the maintenance work on INN!

Tellico 3.5.5 is available, with a few important fixes.

Improvements and Bug Fixes

• Fixed the XSLT file loading to work correctly with libxml2 >= 2.13 (Bug 488707).
• Fixed bug for showing entries with large content (Bug 487079).
• Improved the SRU fetcher to allow user-defined search indices (Bug 488931).

KWin had a very long standing bug report about bad performance of the Wayland session on older Intel integrated graphics. There have been many investigations into what’s causing this, with a lot of more specific performance issues being found and fixed, but none of them managed to fully fix the issue… until now.

The source of the problem

Understanding the issue requires some minimal understanding about how displays work. My earlier post about gaming on Wayland goes into more depth about them and the different presentation modes, but the TL;DR is that most displays today require frames to be sent to it in fixed intervals if you want them to be shown without tearing artifacts.

With the vast majority of displays, that interval is 16.67ms. In order to show everything as smooth as possible, the compositor thus has to render a new frame every 16.67ms as well; it must not miss a single deadline or the user will see stutter as some frames are shown twice and others are skipped.

This problem is not unique to Intel of course, when the deadline is missed, that causes the same stutter on every system. It’s just an often reported issue on old Intel processors because they’re used a lot, because both CPUs and GPUs in them are pretty slow, and laptop manufacturers too often paired them with high resolution screens, requiring the GPU to render for a long time each frame.

How KWin deals with this deadline

In the past, KWin would just start compositing immediately once the last frame was presented, to have as much time as possible for rendering; this worked pretty well but meant that it almost always rendered too early. On desktop GPUs, compositing can take as little as a few hundred microseconds; if we start compositing 16ms before the deadline, that means we’re also unnecessarily increasing latency by roughly 16ms, which makes the system feel less responsive.

For KWin 5.21, Vlad Zahorodnii implemented a scheduling mechanism to do this better: Instead of assuming we always need the whole frame for rendering, KWin measures how long rendering takes and could start compositing closer to the deadline, which reduced latency. However, this strategy could still not get very close to the deadline by default, because it only measured how long rendering took on the CPU, but not how long it took on the GPU.

For KWin 6.0, I implemented the missing part, recording GPU render times. This meant that we could reduce latency more, without causing stutter… Or at least that was the idea. It turns out, render times are very volatile at times; KWin’s rendering can be delayed by other apps using the CPU and GPU, by the hardware changing power management states, by additional windows opening, by KWin effects starting to render something heavy, by input events taking CPU time, and so on.

As a result, taking a simple average of recent render times wasn’t enough, and even taking the maximum wasn’t good enough to prevent all the noticeable stutter. Instead, KWin now analyzes past render times for how volatile they are, and starts compositing much earlier if they’re volatile, and only moves closer to the deadline when render times are stable and predictable. This will likely be tweaked a few more times as I can collect more render time data from different PCs and optimize that algorithm with it, but so far it works pretty well, and gets us the best of both worlds: High latency when necessary to prevent stutter, and low latency when possible.

So, with these old Intel processors, KWin should now detect that rendering takes long and render times are not very stable, and start rendering as early as possible, and that should fix everything, right? Unfortunately, that’s not the whole story.

Old Intel processors are just too damn slow!

On these old processors, especially when paired with a 4k screen, rendering doesn’t just take long, it often takes too long for a frame to be completed after 16.67ms! All the previous improvements were useful, but can’t make the hardware faster.

In the very beginning of the post I hinted that this is a Wayland only problem though, so what’s going on on Xorg? kwin_x11 has a trick that makes this problem less severe: On the start of each refresh cycle, it starts rendering a frame, even if the last frame isn’t done rendering yet. This is called “triple buffering”1 because it uses up to three buffers at the same time (two for rendering, one for displaying) and it has two big benefits:

• while the GPU is still working on the last frame, the CPU can already prepare rendering commands for next one. As long as both CPU and GPU individually take less than 16.67ms, you can still get one image rendered for each frame the display can present
• because more frames are being rendered, the driver may increase CPU and GPU clock speeds, which makes rendering faster and might allow for hitting the full refresh rate

However, it also has some caveats:

• it increases latency in general, as rendering is started earlier than necessary
• when rendering takes more than one refresh duration, latency is increased by a whole refresh duration - even if it would only need a single millisecond more for rendering
• to avoid increasing latency for dedicated GPUs, it’s only active on Intel GPUs and never used elsewhere
• it’s active even on Intel GPUs that have good enough performance to not need it
• when the driver increases GPU clocks because of triple buffering, that may be enough for rendering to be fast enough to not need triple buffering anymore… which means the GPU clocks will reduce again, and frames will be dropped until triple buffering is active again, and that repeats in a cycle. This can, in some situations (like video playback), be more noticeable than a reduced but constant refresh rate.

The goal then was to implement a form of triple buffering that would come with the same benefits, without also having the same shortcomings. First, a few things needed to be patched up to allow for triple buffering to work.

Fixing prerequisites

The DRM/KMS kernel API currently only allows a single frame to be queued for presentation at a time. When you submit a frame to the kernel, you have to wait until it’s done rendering and shown on the screen, before you’re allowed to commit the next frame - but for triple buffering we need to queue two frames. Luckily I had already implemented a queue for other functionality with a drm commit thread (check out my previous post about cursor updates for details), so this one was mostly taken care of already and only needed minor changes.

The queue wasn’t good enough yet though. If KWin’s render time prediction is too pessimistic and it starts rendering much earlier than necessary, it could end up rendering two frames that are meant for consecutive refresh cycles, and complete rendering both during the same refresh cycle… which means that GPU power is wasted. Worse, as the refresh rate of apps is coupled to KWin’s, apps would try to render twice as fast too! To fix that, frames are now simply delayed until the time they’re intended to be displayed.

In order to figure out how long compositing takes on the GPU, KWin uses OpenGL query objects. These are quite useful, but they have three issues for triple buffering:

• query objects only hold a single result. If you start two queries, the last one gets dropped
• if you query a timestamp for commands that haven’t finished executing yet, OpenGL will do a blocking wait until that’s done
• they’re bound to an OpenGL context, which especially complicates things with multiple GPUs

To avoid the last problem, I did a bunch of OpenGL refactors that removed unnecessary global state from OpenGL code, and encapsulated what was left in OpenGL context objects. Render time queries in KWin now store a reference to the OpenGL context object they were created with and handle the context switching for fetching the result themselves, so code using them doesn’t have to care a lot about OpenGL anymore. With that done, the other two issues were fixed by simply creating a new query for each frame, which gets queried after the frame is done rendering, and never gets reused.

Actually implementing triple buffering

After these prerequisites were taken care of, I extended the existing infrastructure for frame tracking, OutputFrame objects, to encapsulate more properties of presentation requests and handle render time tracking as well as presentation feedback directly. With all information and feedback for each frame being tracked in a single object, a lot of presentation logic was simplified and allowing multiple pending frames ended up being a relatively simple change in the drm backend.

To make use of that capability, I extended the render scheduling logic to allow render times of up to two frames. It computes a target presentation timestamp by calculating how many refresh cycles have gone by since the last presented frame and how many refresh cycles rendering will take. If there’s already a frame pending, it just ensures that the refresh cycle after that is targeted instead of the same one… and that’s almost it.

Remember how I wrote that displays refresh in a fixed time interval? Well, it’s not that simple after all. Timings can fluctuate quite a bit, and that could make KWin sometimes schedule two frames for the same refresh cycle, just for the older one to get dropped again and be a complete waste of energy and even cause stutter. As a fix, when the last frame completes and provides a more accurate timestamp about when the next refresh cycle begins, KWin now reschedules rendering to match it.

This is the state of things in the 6.1.0 release; since then issues on a few systems were reported and more adjustments may still be added - in particular, some sort of hysteresis to not make KWin switch between double- and triple buffering too often.

The result

With all those changes implemented in Plasma 6.1, triple buffering on Wayland

• is only active if KWin predicts rendering to take longer than a refresh cycle
• doesn’t add more latency than necessary even while triple buffering is active, at least as long as render time prediction is decent
• works independently of what GPU you have

In practice, on my desktop PC with a dedicated GPU, triple buffering is effectively never active, and latency is the same as before. On my AMD laptop it’s usually off as well, only kicking in once in a while… But on some older Intel laptops with high resolution screens, it’s always active and I’ve been told it’s like having a brand new laptop - KWin goes from doing stuttery 30-40fps to a solid 60fps.

It’s not just old or slow processors that benefit though, I also tested this on a laptop with an integrated Intel and a dedicated NVidia GPU. With an external display connected to the NVidia GPU, due to some issues in the NVidia driver, multi gpu copies are quite slow, and without triple buffering, the external monitor was limited to 60fps. Triple buffering can’t do magic, but KWin now at least reaches around 100-120fps on that setup, which is likely the best that can be done until the driver issue is resolved and feels a lot smoother already.

1. Keep in mind that “triple buffering” means a few different things to different people and in different contexts. I won’t go deeper into that mess here; just be aware that it’s a loaded term. ↩

Tuesday, 25 June 2024. Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.1.1.

Plasma 6.1 was released in June 2024 with many feature refinements and new modules to complete the desktop experience.

This release adds a week's worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include:

• KScreenLocker Greeter: Fix Shader Wallpaper plugin and possibly others. Commit.
• Increase minimum plasma wayland protocols version to 1.13. Commit.
• Use snap:// URLs rather than appstream:// ones on snap only distros. Commit.

View full changelog