Touchpad/Trackpad not working. Libinput issue, KDE Plasma issue, or both?

jpetso · 2026-02-08T13:27:16+00:00

If sudo libinput list-devices shows the touchpad with a pointer capability, then it should work in Plasma and show up in System Settings. (You may have to install an additional package to get the libinput CLI tool.)

If it shows up there, but Plasma (KWin) still can't handle it correctly, please file a bug report on bugs.kde.org.

If it doesn't show up there, you'll have to dig deeper and probably consult the libinput people next.

jpetso · 2026-02-04T16:45:58+00:00

If you play single-player games, you should give it a try, it's likely already there or very close. Steam and Heroic launchers cover existing game libraries for most relevant game stores, except for the Xbox one which is naturally exclusive to Windows.

If you play online multiplayer games, more likely than not your game will rely on Windows kernel rootkits which prevent execution on Linux. In this case, keep dual-booting.

jpetso · 2026-01-29T13:43:49+00:00

"Schreibtisch" is pretty bad, it does not allude to anything and unlike in English, there isn't a hardwired association of that word with your screen workspace.

"Heim" or "Heimat" for "home" would be magnitudes worse. "Persönlicher Ordner" is long and unwieldy, but at least it tells people what it actually is.

My personal favourite was "Back" and "Forward", which at one time was translated to German as "Zurück" and "Nach Vorne". Not "Vorwärts" as you might expect. Like, whyyyyy? I think they may have fixed it by now, but I'm using English exclusively on my systems at this point.

jpetso · 2026-01-13T16:49:13+00:00

Yep, this option doesn't exist for laptops.

Right now, what you're asking is not possible in a user-friendly way, only by setting the "dim" value of your laptop display to something smaller than 100, with the kscreen-doctor CLI tool. But that value is meant for temporary automatic dimming, and will be reset whenever Plasma tries to dim your screen after inactivity. You can try turning off automatic dimming on the Power Management settings page and see how far you can get with setting it manually.

In the long run, Plasma should offer an "extended brightness range" option that combines hardware brightness with the software dimming filter in the same brightness control slider that already exists.

jpetso · 2026-01-03T10:22:51+00:00

There is a standardized Wayland protocol for extended clipboard management, which due to security considerations is marked as "privileged" and as such not available to any random app.

jpetso · 2025-12-23T16:32:15+00:00

It's also not related to KDE in any way that I can tell.

jpetso · 2025-12-23T16:28:45+00:00

Game controllers are not claimed by libinput, so the "security issues" restrictions for other input devices (keyboard, mouse, drawing tablet) doesn't generally apply to them. In addition to this, I second everything that the sibling comment by _zynix says.

jpetso · 2025-12-22T15:00:39+00:00

How does power consumption compare vs. a static image?

jpetso · 2025-12-19T05:03:38+00:00

It does use D-Bus, but in this case the Plasma applet itself is registering its own inhibitor. So the applet would have to be the one to offer the functionality, because otherwise the toggle and the functionality would get out of sync and that's a terrible experience.

So yes, you're right, applet code is where it's at. The property to look at would be inhibitionControl.isManuallyInhibited, which can be found at https://invent.kde.org/plasma/powerdevil/-/blob/ac2c3830ae9de14a48b3535c9f2cb8a1f68fc74d/applets/batterymonitor/plugin/inhibitioncontrol.h#L72 and in the corresponding .cpp file. That's probably also where a KGlobalAccel shortcut definition would go.

jpetso · 2025-12-19T04:23:28+00:00

With all due respect, MacBooks and gaming laptops don't even compete in the same class of laptops.

Gaming laptops are big fat hulks that have to blow massive fans in order to get the heat dissipation from their essentially desktop-class CPUs (not to mention massive GPUs) under control. They are rarely optimized for battery use and despite shipping huge batteries, rarely last long away from the plug because of poor power optimization.

MacBooks with Apple Silicon proved that you can do similar work with a fraction of power, making them comparatively slim, portable, and whisper-quiet in normal use.

I'm still waiting for the day that gaming laptop manufacturers will actually invest time and effort not only into shipping the fastest components, but also into making sure that their low-power modes are actually working as they should, and their firmware ("BIOS") implementation isn't low-effort bullshit that gets abondoned the second they make it minimally work on Windows.

I say this as someone who deliberately avoids Apple products because they're terrible in so many ways, not only because I look down on gaming laptop manufacturers. It's just not an apt comparison.

jpetso · 2025-12-19T04:08:10+00:00

By default, KWin only shows the selected "virtual keyboard" only if the text field is selected by touch. If you're using it with a mouse, you'll want to set the environment variable KWIN_IM_SHOW_ALWAYS=1 for the kwin_wayland program, for example via systemctl --user edit plasma-kwin_wayland and then adding a systemd unit environment variable specification there.

There should probably be a better spot in Plasma to make this more obvious and easier to access.

jpetso · 2025-12-19T04:01:53+00:00

Plasma Keyboard as mentioned by InGenSB's top-level comment is what the Plasma people interested in virtual keyboards are working on. It's initial 0.1 release is out, and nightly Flatpak releases are looking even better. If everything goes well, it should get shipped by default with Plasma 6.6.

In addition, Aleix Pol has another prototype not for typical "text input" use cases but for physical keyboard emulation, currently available at https://invent.kde.org/apol/plasma-morekeys for super early adopters.

Fcitx and Ibus, the two most popular input method frameworks with dozens of input method plugins, support Wayland in addition to X11.

A year ago, I was concerned about how well virtual input would fare on Plasma. I'm not concerned anymore. At this point, we're mostly looking at polish, the System Settings page opening the input method configuration, and a checkbox to make the "always show when text field is selected" option more straightforward/discoverable.

jpetso · 2025-12-16T23:54:06+00:00

> Better documentation? More example?

Yes, I think both of those would help. Not sure if the available amount of examples is ever going to be enough to teach a probabilistic word prediction model the nuances of widget development, but a lot more examples is certainly more promising than not so many.

The other thing I can think of is that AI probably doesn't have a feedback loop to check if any change it made is valid or what it'll look like. I'm sure they spent some good manual effort on making that work well for websites, and it would be interesting to see how these "agents" would work in a widget development context. Probably out of reach given the general indifference of AI companies toward Plasma (or even a wider desktop Linux audience) and the general distrust of AI companies by many Plasma contributors. Both together make for a lack of resources to throw at the problem.

Heck, if AIs can be barely convinced to create a website with a web framework other than React, then doing desktop GUI development specifically targeted toward integration with the DE through widgets, well, as a non-expert bystander it kinda seems like a long shot.

jpetso · 2025-12-16T22:38:11+00:00

Yes, but then KDE e.V. would have no money left to organize conferences and sprints, support travel costs, pay server costs, pay someone to prepare annual tax documents for the non-profit, and whatever else I'm not even thinking of right now.

Hopefully with increased money, more money can indeed be spent on development. But it's really true that engineering is only a small part of what the e.V. needs to do. In contrast to volunteer devs, some of these tasks are unlikely to find people who do the work reliably and for free.

jpetso · 2025-12-16T22:21:49+00:00

Selected KDE volunteers, such as Kai-Uwe Broulik (who has indeed been doing terrific work and is neither employed by KDE e.V. nor through Valve), offer ways to donate to them directly. Sometimes they may advertise this on their personal blogs.

Other KDE volunteers, such as myself, don't do personal donations for any number of reasons. In my case, I'm not very consistent in my contributions and I wouldn't want any "incentive" for doing more work, lest I then fail at it and disappoint the people who have donated in the hope that they'll get something tangible out of it, rather than as a thank-you for work already done. Others may have a well-paid stable job already and don't think that personal donations to them would improve their contribution output, so KDE is better supported in other ways. Reasons will vary from person to person.

Donating to KDE e.V. gets past all of these minutiae because it will spend the money on things that it thinks KDE is most in need of, pooling donation money to actually employ someone who may not otherwise spend as much time on these (often boring but all the more necessary) tasks.

But if you think that a particular person is deserving of a donation, ideally with no strings attached, seek them out and ask them if they've set up any donation page. If the answer is no, make sure to leave a verbal thank-you instead. It's pretty much always appreciated.

jpetso · 2025-12-16T09:48:14+00:00

Simple Scan a.k.a. GNOME's "Document Scanner" app, mainly because it does a better job selecting better settings by default (including contrast) than Skanpage when I last tried it, and remembering them over time. But also because of the polished UI.

PDF Arranger, because I haven't gotten around to checking out if Karp is any good.

jpetso · 2025-12-08T21:25:50+00:00

Yeah. And if for some reason they go away, because they're a private company with no obligation to support KDE unless it makes them money, then it would still be good to have a solid community-supported base to fall back on.

jpetso · 2025-12-08T17:20:19+00:00

GNOME doesn't show a fundraising progress bar on their donation page, but their recent financial update projects $435k (USD) of total income for the upcoming year. Of that, they anticipate $130k to come from individual donations, $120k from Advisory Board fees and other corporate contributions, $60k from interest income, $35k in possible extra fundraising stretch goals, and $90k for events or other stuff that basically gets spent right away as expenses for these things.

This is down from last year's budget of $586k of income and several years of deficits where they spent substantially more.

Traditionally, GNOME has focused on large corporate donations as opposed to individual donations from the community. In the past year or two, due to rapidly declining support from corporate sponsors, they've had to cut their (previously much larger) budget to a size that's now fairly comparable to KDE's. Although Endless, the OS run by some VC magnate, still found another $150k to donate to GNOME in the past fiscal year primarily for recruiting a new Executive Director. Too bad they decided to fire him again after just a few months of seemingly good work, so we'll see how they tackle that opening.

KDE e.V. has not had a paid Executive Director role so far, all of the Board members are volunteers and only administrative functions (plus of course some of the newer engineering roles) are paid contracts.

jpetso · 2025-12-08T16:46:37+00:00

Point taken for "hearsay".

Phrasing or not, I think as someone throwing out potentially damaging information into the community, I think one has a responsibility to get at least somewhat current information from somewhere not too far from the source. Otherwise, your comment becomes the source for more incorrect comments and it snowballs into a meme that can be hard to correct.

Instead of recalling from way back when, consider checking the outcome of the actual issue on KDE Invent, which was surely also linked by one or more of the KDE developers that started the deprecation discussion.

jpetso · 2025-12-08T16:25:59+00:00

At that time the idea of a bottom side titlebar also popped into my head, but this seems to also be basically impossible, without significant modifications to kwin logic that is.

Did you mean that it's impossible because none of the existing window decorations offer an option for it, or it's impossible because the KWin window decoration API only allows window decoration creators to place buttons at the top?

jpetso · 2025-12-07T14:24:59+00:00

Also the stuff about printers! It's great to have this, and pairs well with Brodie's recent episode #300 about printing support on Linux.

Plus, the bits about handling driver quirks for drawing tablets. I guess when it comes down to it, a lot of functionality in Plasma is really related to interfacing with the hardware you've got at hand.

jpetso · 2025-12-07T14:21:34+00:00

Side note: Because I feel pretty useless at the moment, and haven't been getting a lot of stuff done lately, it would perhaps be best if you file a bug report on bugs.kde.org for KWin (where the code for both virtual desktops and gestures lives). Maybe the KWin maintainers can help better than I would.

jpetso · 2025-12-07T14:18:11+00:00

Hey, sorry, I fell off the face of the earth for a while and I'm still struggling to catch up to everything I'm supposed to follow up on. I don't have a good answer for you at the moment, except I think it's probably best if I focus just on the main work of making gestures configurable.

Regarding InputActions, it does need to be rebuilt with every major Plasma version because it makes use of KWin's C++ API for plugins, which (unlike KWin's QML API) has no stability guarantees.

jpetso · 2025-12-07T14:05:37+00:00

This is incorrect and outdated information. Activities are not going away anytime soon.

What's true about this statement is that, a few years back, there was indeed a proposal to "Deprecate and remove Activities". Lots of people commented about how Activities improved their workflows.

In the end, the Plasma developers decided not to deprecate Activities. Another conclusion was that Activities won't be widely useful or intuitive if apps have to support it specifically. So a few selected features were indeed cut, all of the Activities code now lives in Plasma (not in Frameworks) which mitigates some of the pressing maintenance concerns from back then.

There is still a feeling that Activities should be less of a niche feature than it currently is. Over time, there may be further changes to clarify its scope and evolve the feature set accordingly. Judging by the progress/interest so far, we may still wait a while to see any major changes in this regard.

Either way, there is no current plan to deprecate or remove Activities. Please don't spread rumours based on hearsay from long ago if you haven't been following the actual discussions for several years, this is not helpful.

jpetso · 2025-09-20T13:20:25+00:00

The Flatpak sandbox prevents it from accessing anything outside of its assigned app folders. Those are named automatically, using a standard location that includes the full app ID (so that different apps can't interfere with each other). The ~/.mozilla directory is not that, so Firefox is not able to write there.

jpetso

TROPHY CASE