Remote desktop has been one of the weaker areas of the transition to Wayland. There's a lot of software written exclusively for X that has a direct Wayland equivalent. Within KDE, we already have a Plasma-native RDP and VNC solution for Wayland, but we're aware that it hasn't yet reached the level we want it to.

Throughout the path to Plasma 6.8 it has been an area of focus, with contributions from me, Shouvik Kar, Nick Haghiri, Oliver Beard and Wensheng Tang.

Improved Unattended mode

There are a few different use cases for remote desktop:

Support Mode

This is the typical remote session. You see exactly the same thing on the remote client as on the host, with the contents matching the size of the monitors on the host machine.

This is great when there's someone at the host machine and someone else remoting in, and you want to work together while both seeing the same content.

Unattended mode

The above mode isn't so great when there's just you. If I'm connecting to my home PC from a tiny laptop, it's very unergonomic to have the remote screen be larger than my laptop display and have to scroll around it.

Additionally if my remote PC is in an office, I don't want my colleagues to see my cursor moving around clicking on windows when I'm not there.

We have a new UX that solves all of these issues:

• On connection, the remote machine shows the login screen.
• For the sesssion you log into, the host machine's screens are removed, ensuring privacy and security.
• The remote screens are resized to match the size and layout of the client's screen setup.
• When streaming in a window, the remote screen dynamically resizes to match the window size.
• Best of all, after the remote session is closed and the user logs back into the host machine, all their windows return to where they were last positioned on the host setup.

The underlying work also sets us up nicely for the full headless case.

Clipboard

Clipboard support has been massively improved with bi-directional text snippets and upcoming work for file transfers, including support in KRDC.

Performance

We've been cutting down latency throughout the system. A new timing mechanism tracks every frame throughout the entire process, letting us see where delays build up, from receiving the raw frame and encoding it, through transmission over the network, to rendering on the client and finally receiving the acknowledgement.

We now coalesce frames that are still waiting to be sent to the client. A new algorithm determines the optimal number of frames to keep in flight, while improved backpressure handling keeps latency lower during network dropouts.

There's also work happening to send multiple streams or even areas of the same desktop at once.

KRDC will also benefit from improved performance in 26.12 as an extra source of latency compared to the xfreerdp3's model performance has been addressed.

Better compatibility

One of the core reasons we have an RDP server is that there's a huge range of existing clients out there. That only helps if we actually support those clients, which isn't trivial given how much variation there is between them.

We now support both RemoteFX Progressive encoding as well as full hardware accelerated H264 encoding with improved fallback for when H264 encoding fails. We also fixed NLA authentication for Windows clients.

libei port

Another large refactor is the port to libei: a library/protocol for sending emulated input to the compositor that's a lot more fleshed-out than the basic 'move mouse' 'send keysym' that existed directly in the XDG Portal specification. libei is far more robust: it can support any number of devices at once and provides the infrastructure for us to also support remote tablet and touch.

We also have massively improved support throughout the stack for sending any keysym that isn't in the current keymap. i.e even if the host keyboard is set to US, you can still input on the remote side characters like ẞ, to even fully composed UTF-8 strings like "안녕 👋".

What's next

Multi-user headless

Whilst I am confident that we will have a great single-user story in time for Plasma 6.8 even for truly headless setups, it is unlikely we will deliver a remote server that handles multiple concurrent users at this time. It is far from trivial, and feature freeze for Plasma 6.8 is upon us.

Standardisation

Ultimately, it's frustrating that we're in a situation where we have to maintain this entire service at the KDE level, when much of it should be a solved and shared problem.

Having our own implementation has been useful to work out how to provide tight integration with Plasma, but there are many competing remote-desktop services that should be able to benefit from the same underlying infrastructure.

Others feel the same way, and there is some effort to start standardising the work for headless setups. I hope to have more news on that front shortly.

Call to action

As this remains a critical path for X11 holdouts, we need people to test and contribute. If you can, please run master builds and report any bugs you find. The final merge-requests for the parts mentioned above should be landing soon. Bug reports help; patches even more so!

In the feedback about dropping X11 support, one very surprisingly common comment is from users saying they "need" kgamma, a simple tool that allows the user to adjust the gamma, red, blue and green that gets drawn to the screen operating directly on the X server.

On our Wayland session we have colour management that blows simple gamma adjustment out of the water, so on the face of it it seems weird that this would come up. However at the same time, I get it. ICC profiles are very confusing and it's not the same as a few basic sliders that anyone can understand.

We want people to have the best transition to Wayland we can offer and this is a relatively easy fix.

The new tool

I have made a simple tool that edits the relevant part of an ICC profile - VCGTs.

"VCGT (Video Card Gamma Table): An optional, private tag inside an ICC file that stores 1D grayscale/gamma curves loaded directly into your graphics card's hardware Look-Up Table (LUT)."

That's a lot of fancy terms, but the key point is it's a tiny subset of the thing Kwin already supports. We can add a UI around those few values and not need to add a second code path in kwin or kscreen.

The UX is deliberately similar to the old UI.
Obviously it needs a round of polish (volunteers welcome!), but it's functional.

Why this is even better than on X11

Unlike KGamma on X11, this new tool:

• Supports multiple monitors with independent values

• Works with night colour rather than fighting over the same settings, Kwin will blend the two sets on top of each other

• Gets applied by Kwin on startup so the first frame is perfect, rather than glitching during loading

What next

Whilst changing your red/green settings wtih sliders might be something a few users do, and we got a few comments it remains a niche case.
My intention is to post it as a standalone application on Flathub and not as part of Plasma. I think that strikes the right balance of providing support without holding ourselves back longterm.

Getting it

The new tool is available at:

https://invent.kde.org/davidedmundson/kgamma2

Usual CMake + build instructions apply.

Feel free to make pull requests and let me know if it helps solve your issue!

If you've been around KDE, you've probably heard of Techpaladin Software

We're a consultancy that works almost exclusively on KDE, improving KDE upstream while delivering the features and functionality our clients need.

We're growing and looking for more developers to join the team. We're after experienced developers who are already familiar with KDE, C++, and Qt.

We currently have two positions available:

• Someone with a keen eye for design to work on high-level features and help shape the user experience.
• Someone with a more technical background to work on lower-level system integration and platform work.

In return, you'll get to work with some of the most talented and welcoming developers in this space... and also me!

If that sounds interesting, you can find more information and apply here:
https://techpaladinsoftware.com/joinus.html

When we first announced the transition to Plasma Wayland, one of Martin's slides from stated, "It's done when it's done!"

That talk was 15 years ago!

Nothing in software is never truly "done", but as announced previously we are finally at a point where we're ready to retire the X11 and put all our focus on the future.

As of today, the Plasma X11 session you can log into has been officially removed, and we will start a mass cleanup of X11-specific code soon.

When does it take effect?

This change will be included in Plasma 6.8, which will be released in around five months.

What's Changed?

In Plasma 6.8, there will be no X11 session in the login screen. There will only be a Wayland session available to log into.

In 6.8, all X11-specific code paths in Plasma for Plasma Shell, System Settings, and device configuration will be gone.

What's stayed the same?

XWayland support remains present. You can keep using your X11 applications, and our XWayland application support is second-to-none.

If you use KDE applications on another desktop environment, this change will have no effect. KDE applications will continue to work in X11 for the foreseeable future.

Plasma Login Manager will continue to be able to log you into X11 sessions of other desktop environments.

What's Next?

The possibilities this opens up are very exciting. Until now, on the desktop side, we've had to target the lowest common denominator or be stuck trying to maintain two conflicting code paths. It was absolutely the right choice to do a gradual transition and approach things this way, but that approach has its limits.

Moving forward with a single code path going through Wayland is going to allow us to bring new performance improvements, memory optimisations, and brand new exciting features throughout Plasma.

How Ready Are We?

Our internal metrics within KDE show that over 95% of users of Plasma 6.6 are on Wayland, with a gradual increase every release. The metrics also show that basically no one is testing or developing Plasma on X11 anymore. The platform was already, for all intents and purposes, abandoned by KDE contributors.

We have every reason to trust this metric data, as it is exactly in-line with what Sentry (our automatic crash reporting tool) reports for newly-encountered crashes shows.

For transparency, the one caveat in all of the above is that I've deliberately always focused on people using the latest Plasma release. We do still have a sizable chunk of users on X11 still using Plasma 5.27. Including them, the total Wayland adoption rate is about 76%. But back then, Wayland wasn't the default session type, so it's hardly a surprise those users are still on X11. Things have come a massively long way in the three years since Plasma 5.27 was released.

Anyone still using Plasma 5.27 — or any release older than Plasma 6.8 — won't be affected by what we do in Plasma 6.8, and nothing will be applied retroactively.

Still Have Issues with Wayland on 6.7?

Whilst we have had full confidence since Plasma 6.0 that our Wayland session provides the better overall experience, we are aware that things don't behave exactly the same. Not everything works the same especially in specialised areas.

We are not expecting a completely seamless transition for everyone. Custom scripts, tools used and even workflows might have to change. But we are aiming to offer a transition where there is still a way to accomplish all your day-to-day tasks.

Plasma 6.7 is the last release that will include an X11 session, and it's coming out in just a few days. If you still have issues that force you back to X11 we would love to hear from you.

We can't promise to get everything fixed in time for 6.8, but we can promise to listen and be aware. People's remaining pain point are and will be on our radar, so please take this time to communicate them.

This is a effectively a guest blogpost where I, as usual, take the credit for the work someone else has done.

Last year ago set out making a home automation <--> Desktop Linux bridge over the Christmas holidays.

The idea is that if you're using home automation your PC that you're in front of has a lot of important information that can be used for adjusting automations; are you in a call, are your headphones on, and so on. I made a small daemon, named Kiot (derived from "KDE Internet of Things") that exposes this information about your PC to Home Automation software, like Home Assistant.

It worked well enough for all my use-cases, so after a bit of initial buzz and a few drive-by fixes it fell to the wayside whilst I worked on other things.

In the last month it got a new contributor, Odd Østlie (TheOddPirate) who has been like a rocket ship of new features; and a bit of a community with another member being active in testing and feedback.

We now track and expose:

• bluetooth

• audio devices, volume control and selection

• battery states for laptops and wireless peripherals

• gamepad detection

• active window information

• media player/mpris connection

With more integrations in pull requests.
There's also the start of a configuration UI, so there's no messing about with configuration files.

I'll do another post once we've made a 0.1 and a flatpak, but if you're interested in KDE + home automation, go check out his work at https://github.com/davidedmundson/kiot .

I hate waiting for compilations. For day-to-day it may only be a minute or two, but once you start doing another task, the context switching distracts from what you were doing before and breaks everything up. Life is too short to be waiting for computers.

Obviously the first answer is to have a faster machine, but having a super fast laptop and a super fast PC all the time contributes to e-waste which I also hate. Some of my test devices for touch and tablet work are 5 year old Intel atom devices that I still sometimes need to compile on to fix things.

The solution is distributed compiling, using multiple computers to share the work.

Icecream or distcc used to be the tools back in the day, but they're both quite dated and have other issues.

There's a relatively new kid on the block, sccache. sccache primarily serves as a way of keeping your cached compiled assets around (think ccache), but also sharing them across users. Sharing cached assets requires exactly matching paths and dependencies and compilers so it's not that great for my needs; but it seems it would be perfect for flatpak and immutable cases.

But sccache also has another trick up it's sleeve; distributed compilation.

The documentation for sccache is a bit overwhelming packed with enterprise level features https://github.com/mozilla/sccache/blob/main/docs/Distributed.md.
It wasn't that clear how to do something simple, so I thought it might be useful to share how I got things working nicely for me.

Installation

Sccache is probably available in your distribution, note that not all distros include the shared compiler part.

If not you can download a version from https://github.com/mozilla/sccache/releases/download

The nice part is it's statically linked with no external dependencies so you can throw it on anything, even if it's immutable like KDE Linux or even a Steamdeck or two.

The parts

Scheduler

The scheduler is the key part of the operation; the client sends requests to the scheduler which in return replies with a list of schedulers that can recieve payloads distributing them accordingly.

Simple

Create a file as follows:

scheduler.conf

public_addr = "0.0.0.0:10600"
client_auth = { type = "token", token = "dave_is_great" }
server_auth = { type = "token", token = "dave_is_great" }

sccache-dist scheduler --config scheduler.conf

Docker

As I want the scheduler always on, I run it on a small home-server, where I prefer to docker-ise everything.

docker-compose:

version: '3.8'

services:
  sccache-scheduler:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        VERSION: "v0.10.0"
        SHASUM: bbf2e67d5e030967f31283236ea57f68892f0c7b56681ae7bfe80cd7f47e1acc
    image: sccache:latest
    container_name: sccache-scheduler
    ports:
      - "10600:10600"
    volumes:
      - ./scheduler.conf:/scheduler.conf:ro
    entrypoint: ["/usr/local/bin/sccache-dist", "scheduler", "--config", "/scheduler.conf"]
    restart: unless-stopped
    environment:
      - SCCACHE_NO_DAEMON=1

Dockerfile

FROM alpine:3.9.2

ARG VERSION
ARG SHASUM

RUN apk add clang
RUN apk add curl
RUN apk add --no-cache bubblewrap

RUN curl -L https://github.com/mozilla/sccache/releases/download/$VERSION/sccache-dist-$VERSION-x86_64-unknown-linux-musl.tar.gz > sccache-dist.tar.gz \
    && tar xf sccache-dist.tar.gz \
    && mv sccache-dist-$VERSION-x86_64-unknown-linux-musl/sccache-dist /usr/local/bin/sccache-dist \
    && rm -r sccache-dist.tar.gz sccache-dist-$VERSION-x86_64-unknown-linux-musl

RUN apk del curl

ENTRYPOINT ["/usr/local/bin/sccache"]

and the scheduler.conf as above.

Servers (build machines)

This is the part that does the building.
The config takes the address of the scheduler, but also the server's own IP address as a sort of "callback" address.

It needs to run as root in order to have capabilities to set up sandboxing and restrict it back down to something lower than where we started. The sitaution is a bit silly, but it is what it is.

server.conf

public_addr = "192.168.1.YOURIPADDRESS:10501"
scheduler_url = "http://192.168.1.SCHEDULERIPADDRESS:10600"
cache_dir = "/tmp/toolchains"
scheduler_auth = { type = "DANGEROUSLY_INSECURE" }

[builder]
type = "overlay"
# The directory under which a sandboxed filesystem will be created for builds.
build_dir = "/tmp/build"
# The path to the bubblewrap version 0.3.0+ `bwrap` binary.
bwrap_path = "/usr/bin/bwrap"

Then you can run sudo sccache-dist server --config server.conf

Systemd

As I want this running constantly on my desktop and laptop I use a systemd service.

/etc/systemd/system/sccache.service
[Unit]
Description=sccache scheduler
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/sccache-dist server --config /etc/sccache/server.conf
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Clients

The final part is relatively simple, making local builds use the other build servers.

First we need to set up a config as follows:

.config/sccache/config

[dist]
scheduler_url = "http://192.168.1.SCHEDULERIPADDRESS:10600"
toolchains = []
toolchain_cache_size = 5368709120
auth = { type = "token", token = "dave_is_great" }

Cmake

Enabling requires just telling cmake to use the relevant wrapper with -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache

kde-builder

And/or it to your kde-builder as follows:

.config/kde-builder.yaml

global:
  cmake-options: -GNinja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON  -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache 

and reconfigure the project(s)

Quirks and workarounds

The most annoying quirk is servers need a consistent IP address within your network. Servers register to the scheduler with a fixed IP address. When clients queue jobs they are given the IP addresses back from the scheduler and are expected to then talk to the build server(s) directly. Using hostnames doesn't work.

Note also if you change your local .config/sccache you may need to run sccache --stop-server on the client to relaunch. Confusingly in this case 'server' refers to a process on the client that compile jobs are thrown at.

Debugging

sccache --dist-status will show the connected schedulers and how many total active jobs

Managing job count

By default ninja schedules the same number of jobs as you have local cores for. It's unaware of the many other cores you have.
I have this in my zshrc to set the number of jobs to the total number on the scheduler at that time.

function getSccacheCPUs() {
        sccache --dist-status  | jq '."SchedulerStatus"[1].num_cpus'
}
alias ks='MAKEFLAGS=-j${getSccacheCPUs} kde-builder'

Comparison to icecream

Cons:

• The setup process is a lot more laborious than icecream's magic turn-up-and-compile structure
• No cool UI to see how many tasks are being compiled.

Pros:

• It's very robust to network issues. If the scheduler is down or no servers are available things build locally extremely transparently
• It also has it's own equivalent of a local 'ccache' which means you don't need to worry about daisy-chaing compilers wrappers to still have cached output.
• It's actively maintained, the last meaningful commit in icecream is years ago

I'm writing this blog in the very very early stages of development because I'm 50% sure someone will link me to some existing library that Google failed to find.

Varlink

Varlink is an IPC mechanism that is gaining popularity in a few places across Linux. It's very simple, JSON blobs over a socket terminated with a null byte. It doesn't have anywhere near the features of DBus, but the simplicity is the main selling point.

Ultimately when it comes to choosing IPC what matters is what the servers you want to talk to are already using and then things become forced.

QtVarlink

Interacting with C APIs is a horrible experience for all involved. We want something that looks and behaves likes a Qt developer would expect and used the inbuilt QtJson classes.

My new library provides API as follows.

    VarlinkClient client("unix:/tmp/foo");
    QFuture<VarlinkResponse> pendingResponse = client.call("org.example.Ping", QJsonObject({{"ping", "1"}}));
    pendingResponse.then(this, [](VarlinkResponse response) {
        qDebug() << response.parameters()["pong"].toString();
    });

Or any variation of QFutureWatcher or just blocking.

State

Code is available at: https://invent.kde.org/davidedmundson/qtvarlink

As mentioned in the intro, it's pre pre alpha. It's the minimum viable product for a task I had, but I intend to make it a standalone project.

Please let me know if this would be useful to you. There's a roadmap in the Readme and pull requests are more than welcome!

Activities' future is a bit unclear at the moment. It overlaps with functionality provided by other services and the user story for how it fits into the desktop is unclear at best. However we also have to acknowledge that some people use activities to create a workflow that works for them. Rather than taking a sledgehammer to the concept, we're performing a more surgical approach of working out what use-cases people are trying to fix at finding the best solution to deliver that.

With that comes cleaning out some of the parts we don't like and one part decided at the Plasma sprint was dropping the activity based sub-session management.

What's changing

At the moment activities can be started and stopped at runtime.

This start/stop feature (pictured above) is being dropped.

---

In theory there is is XSMP code performs session management on a per-activity basis. When an activity is stopped, those applications are frozen, closed as running processes and restored when the activity next gets restarted.

It's a neat idea, but in practice this rarely happens, for a range of reasons:

• XSMP is not supported in an increasing amount of apps and toolkits. Subsessions even less so, and even more less so with Wayland.
• It is blocked in almost all Flatpak/Snap applications as there's a fundamental sandbox escape in the protocol.

The vast majority of apps just move to the neighbouring activity.

---

Even if it did work, there's a fundamental design flaw with the entire concept.

A window/app can be on two activities at once, if it should remain open on the other activity we can't suspend it. The concept of session restoration is at odds with the cardinality of windows to activities.

Many applications don't allow multiple instances; so if you resume an activity with the application already running, it won't do anything and that's unfixable.

The end result is one that's inconsistent and unpredictable which is a state worse than not existing so we're dropping this feature.

Will I see an impact?

Not much. If you do use activities you can still switch between them as before, just with no "stop" and "start" button.

Plasma's login experience is an area that we know requires some improvement — it works OK in the basic case, but it's very barebones and doesn't handle anything beyond that.

As a complete desktop experience, it's our job to provide support for the edge cases too.

What we want

• Great out-of-box experience in multi-monitor and high DPI and HDR
• Keyboard layout switching
• Virtual keyboards
• Easy Chinese/Japanese/Korean/Vietnamese (CJK) input
• Display and keyboard brightness control
• Full power management
• Screen readers for blind people (which then means volume control)
• Pairing trusted bluetooth devices
• Login to known Wi-Fi for remote LDAP
• Remote (VNC/RDP) support from startup

A brief history

In Plasma 5, we retired our own bespoke display manager KDM, in favour of SDDM. A display manager started for multiple lightweight Qt Desktops. It was modern at the time making use of new QML for the front and as a big selling point at a time when Plasma was also making use of it.

SDDM's Big Architecture Problem

We ran into a problem, though. SDDM is designed to show a single greeter window, loading arbitrary QML from the specified theme.

Whilst this all sounded great for Plasma, the abstraction is at the wrong level — for our wishlist we need a lot more tight integration from our login screen than just a window showing sessions and users.

With SDDM, power management is reinvented from scratch with bespoke configuration. We can't integrate with Plasma's network management, power management, volume controls, or brightness controls without reinventing them in the desktop-agnostic backend.

SDDM was already having to duplicate too much functionality we have in KDE, which was very frustrating when we're left maintaining it.

The Competition

GNOME's GDM is the gold-standard of display managers, and it achieves this higher level of quality by running half of a Gnome session.

SDDM got closer when it added Wayland support — it had to use a compositor such as KWin. But because the project tries to be agnostic between desktops, it has to support any compositor. There aren't compositor-agnostic ways to do even simple things like set the keyboard layout, so in the end this compositor agnosticism goal simply didn't work.

Theme Problems

A major mistake we made throughout Plasma 5 was conflating "writing UI in a high level scripting language" with "it's themable" as the same thing — they are not. QML does make it easy to modify and iterate without programming skills, but it still contains business logic. It should not be the primary method of customisation that we expose to users.

Ultimately, this was poor for end users. We pushed back on adding support for configurable theme options, because building a theme engine within a theme was wasteful! But often people want to just change a few things. Choosing a theme meant finding a combination that had everything. The store filled up with themes that are 99.9% identical code-wise; most are just wallpaper mods.

It was also poor for theme developers. Not only do they have to modify the visuals, but also re-implement focus handling, accessibility, and the same boring logic again. They can't benefit from widespread testing so regressing these functionalities is common. Reddit is full of screenshots of broken SDDM themes.

Finally, it's poor for us Plasma developers: theme support holds us back from adding new features or tidying code; if we want to add a new feature that in any way affects existing UIs, the situation get very messy very fast. The end result is that features just don't land, and the end user is the one that misses out.

So, what's the plan?

It's worth stressing nothing is official or set in stone yet, whilst it has come up in previous Plasma online meetings and in the 2023 Akademy. I'm posting this whilst starting a more official discussion on the plasma-devel mailing list.

Oliver Beard and I have made a new mutli-process greeter, that uses the same startup mechanism as the desktop session. It doesn't have all the features that we propose at the start of the blog, but an architecture where features and services can be slowly and safely added.

For customisation we intend to expose the same familiar settings that exist in Plasma and bring the design more in-line with the existing screenlocker where we also dropped arbitrary QML years ago. We'll make the wallpaper configurable with any existing wallpaper plugins, and expose the existing plasma theme and colour settings. Syncing will be a case of copying files, not re-inventing things.

The backend

When starting work on this, I tried to explore all alternative backends out there even with fully working implementations, however in practice nothing was maintained that matched our requirements. SDDM has been proven in the real world, so we have taken that and stripped it down to cover what we want moving forwards. I also aim to incubate it into the KDE ecosystem to have full autonomy over the project and merging stuck patches.

Current State

All of this has been implemented as two new repositories. Plasma Login Manager a continuation of SDDM and Plasma Login for front end and KCM (settings) code. These might be merged at some point.

The new code all works, and is at roughly feature parity with what we're replacing. A screenshot looks roughly the same as a stock Plasma SDDM setup. Whilst this is at a state where developers can opt-in, I would not want distros to be packaging things at this point.

Please do reach out if this sounds interesting, either directly or in the Plasma Matrix room - or with merge requests!

About

Home Automation is mostly, as the name implies, about automation.

The machine you're in front of all work-day has an awful lot of useful information that can be useful in your home management.

I have a script lower my blinds if I turn on the camera during the afternoon as otherwise there's an annoying glare. My office lights and monitor both have a redder hue at night, but disabling night-mode on my PC automatically disables the main light performing redshift too. I want my screen to turn off not 10 minutes after activity, which is simultaneously both annoyingly too long and too short, but the moment the motion sensor in my room says I've left.

Home Assistant, the best open source home automation tool out there supports all of this, but it needs some hooks for the PC to tell it about the current state and invoke actions on the PC.

None of the existing solutions worked well for what I wanted. I wrote something for personal use a few years ago that worked great for me, I ran it in the background and didn't plan to take it further.
During the KDE Goals sprint another user suggested creating something very similar (https://phabricator.kde.org/T17435). That goal may not have been chosen, but it did motivate me to tidy up and document what I had and turn it into a more fleshed out project.

The App

I made a small daemon, named Kiot (derived from "KDE Internet of Things") that exposes this information to your Home Automation software.

This is pre-alpha software, there's no GUI configuration it relies on manually setting up a configuration file to point to your Home Automation server. If there's enough traction I might make it more packagable, and create a UI config over the Christmas break.

There's a bunch of sensors and actions shipped, but it contains a faux plugin system to make extension easy along with hooks for user supplied scripts.

• User activity
• Locked state
• Suspend/Power actions
• Camera in use
• Accent Colour
• Arbitrary Scripts
• Shortcuts
• Nightmode Inhibition

Using this from Home Assistant is then as straightforward as possible.

Checking it out

The repository can be found at https://github.com/davidedmundson/kiot which has setup instructions along with developer documentation (https://github.com/davidedmundson/kiot/blob/master/DEVELOPMENT.md) if you want to make any additional plugins.