https://bugs.kde.org/show_bug.cgi?id=494612
Bug ID: 494612
Summary: Add CLI flags for Disabling Plugins/Effects on
Startup?
Classification: Plasma
Product: kwin
Version: master
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: general
Assignee: kwin-bugs-n...@kde.org
Reporter: stellarpo...@googlemail.com
Target Milestone: ---
I've been writing a custom effects plugin for KWin, and also (by total
co-incidence) seem to have just hit a bug in another effect whilst testing mine
out on metal for the first time. I see quite a few recent bugs regarding
effects.
I am wondering if it would be useful (and viable) for other developers to add a
CLI flag to kwin (and possible startplasma-... - I am not sure if there is a
way to pass arguments through to kwin when starting plasma from a TTY) to
disable the loading of plugins and effects entirely for that compositor
session. I would've thought there might already be an option for this, but I
don't see one currently on 6.1.5.
Effects and the like can be de-activated in the config files/through settings,
but to the bets of my knowledge, this only turns them off - what I am proposing
is actually not loading the plugins at all into the session, to be sure that we
have a more stripped back compositor. I had a subtle bug in the constructor of
my effect that didn't reproduce before, so this will still crash even if I
disable the effect in my settings, as the plugin itself is loaded in on
startup.
Personally, my own usecase is that I'm developing in a VM and modifying from a
system package recipe, so that I can be sure I can patch in future releases and
rule out any build flags my distro wants to have applied - so I don't (yet)
have a separate build of kwin for testing from the one running the display,
it's pretty much my first time working with the sources. It'd be useful not to
have to run a different compositor (such as wayfire) to manage the actual
output, and get somewhere to run the nested session, but instead start a plasma
shell without effects as the root display, getting my nice familiar desktop,
and then start a simpler nested KWin with the effects loaded just through the
debugger to troubleshoot.
But I figure this option might come in handy in other ways - especially with
crash reporting as a step users can take to rule out the ... effect, of effects
on the session, pinpoint issues and verify if it is reproducible in a core
sessuib or not. Without extra work this proposal would of course only affect
users starting through the command line from a TTY or using a nested session,
but as further scope perhaps a fallback session could be added for the login
manager. Again, feels like this might already exist in some form, but it
doesn't appear in my SUSE or KUbuntu installations. Some other compositors I've
used have an option in the login manager to start in fallback mode, with
software rendering, or with all extensions disabled for this reason.
Thanks
--
You are receiving this mail because:
You are watching all bug changes.
