[ANNOUNCE] kwin-type v0.1 is released
Jason A. Donenfeld
jdonenfeld at kde.org
Mon Oct 26 23:21:41 GMT 2026
On Mon, Oct 26, 2026 at 10:48 PM David Edmundson
<david at davidedmundson.co.uk> wrote:
>
> On Mon, Oct 26, 2026 at 3:24 PM Jason A. Donenfeld <jdonenfeld at kde.org> wrote:
> >
> > Hi Vlad,
> >
> > On Mon, Oct 26, 2026 at 02:23:39PM +0000, Vlad Zahorodnii wrote:
> > > > Some background: I didn't want to have to make such a utility, but all
> > > > the existing utilities for this seemed deficient in one way or another
> > > > -- requiring /dev/uinput or requiring virtual-keyboard-unstable-v1 or
> > > > using portals + EIS. I actually initially made a utility that used
> > >
> > > It's still highly advised that you look for supporting libei. We want to
> > > remove the fake input protocol in favor of supporting only libei.
> >
> > Nooooeeeee.... libportal + libei is really stinky. There's gobs of dbus
> > setup and it's way slower and has more overhead.
>
>
>
> > And then every time you
> > use it, you have to authorize the caller. So then there's a need for a
> > `--token-file=...` parameter and logic to automatically replace that and
> > also lock it properly against concurrent use.
>
> There is a path for libei without portals. It might be a happy medium
> between avoiding your portal woes and using the API we will support
> long term.
Are you referring to using org.kde.KWin.EIS.RemoteDesktop? Isn't this
also a "private" interface? Is this stable?
That would still involve clunky dbus stuff -- it's a lot more straight
forward to just have WAYLAND_DISPLAY control things in a sane way --
but at least that wouldn't require crazy portal stuff and token
management. I suspect it might also raise a notification everytime
it's used, which is sort of suboptimal too (assuming that comes EIS
and not the portal server side).
Jason
More information about the kde-devel
mailing list