Bernd Nachtigall posted on Wed, 24 Oct 2018 07:44:51 +0200 as excerpted:
> Hi,
>
> in KDE you can scale the whole display. (use systemsettings / Display
> and Monitor / Display / Display scaling)
>
> I try this and set scaling to 1.2. I reboot and found that this not
> usable for me. I set this value back to 1.0, reboot, but the scaling is
> not reverted :-\ (Now may monitor is to small ;-)
>
> How is the way to get the scaling back to normal? Is there a way without
> the use of the systemsettings menu?
>
> Bernd
>
> BTW: the menu names are translated from german to english. So maybe they
> are not accurate.
OK, I have a "plasma-lite" installation here, without some components I
find more trouble than they are worth, and in plasma systemsettings,
display and monitor, I don't have the display applet, which I believe is
part of kscreen, which I don't have installed (because using it would
break the existing X configuration and I'd have trouble getting things
back they way I wanted, sound familiar? =:^( ), but...
Here's a generic answer that applies to pretty much anything kde/plasma
related, that I hope will help:
In general, yes, there's a way to reset everything, you just have to
figure out which config file to edit or delete to do it. =:^\ At least
all kde/plasma settings are stored in plain-text files and thus can
almost always be easily edited, once you figure out which file to edit!
=:^)
There are two ways to figure out what to edit:
The bisect method, brute force and requires patience, but not too much
technical knowledge:
First, confirm that the setting for a clean config is working. Either
create a new user temporarily and try it there, or move all your normal
user settings elsewhere temporarily, so you start with a clean config,
and ensure that works.
If a clean user config doesn't work, the problem is at the system level,
perhaps a recent update from your distro.
Assuming you've confirmed it's a setting in your user config, you then
"bisect" the problem down in steps, testing roughly half the potential
setting space by backing up and then removing (with the thing under test,
plasma in this case, shut down) the other half, then based on whether
it's in the remaining half or the removed half, testing half of the bad
half, bisecting the problem space roughly in half at each step until
you've isolated the specific directory, then the specific file, with the
problem in it.
Once you reach the specific file, you can either just delete it and start
over with fresh settings for everything it controlled, or switch from a
file manager to a text editor for testing, and dive down into the
configuration section and then individual line.
>From experience with plasma, I can tell you that most settings are
under .config (well, the XDG_CONFIG_HOME environmental var, which is
normally set to $HOME/.config), in your home dir. So at the first bisect
step after confirming it's a user setting, not system, I'd back up
~/.config and remove it (with kde/plasma shut down, of course), then
start plasma to test if the setting is reset or not. If so, try with
only half the files/dirs in ~/.config, otherwise, try ~/.local/share (or
$XDG_DATA_HOME) instead, as that's the other common location.
The bisect method works for all sorts of stuff and is great because it
doesn't require a lot of specific technical knowledge to do it. In fact,
it's so effective and popular there's a git bisect command to help people
nail down the specific patch/commit that introduced a bug, and I use it
routinely for that purpose to nail down new bugs in both the Linux kernel
and the live-git kde/plasma I run, so as to more effectively report them
because I can report exactly which commit introduced them, even if I'm
not a dev.
The strace/grep method, a bit more technical but less repetitive:
The strace/grep method uses strace -eopen or similar to trace the files
opened by the process you're trying to find the config file for. But any
modern X-based process will open hundreds or thousands of files as it
starts, libs, system config, icons, fonts, etc, in addition to the config
file you're looking for, so to filter out some of the noise, pipe the
strace output to grep -v to kill what you do NOT want to see. Of course
run in a terminal/konsole window.
For a kcm (kcontrol module, aka systemsettings module, as it was called
kcontrol before), the easiest way is to figure out which module you're
looking at and invoke it directly, using kcmshell5 <module>. You get a
list of the modules with kcmshell5 --list (again, run in a konsole
window). Then from the list, choose a kcm that looks like it might be
the one you need, and run it. Once you have the kcm you want, then strace
it. That way, you avoid all the strace output from just opening
systemsettings and browsing to the kcm you want, by opening it directly.
I did say this method's a bit technical, so I'll assume if you are going
to use it you already have some familiarity with strace and grep so I
don't have to give you the specifics, but I do use this myself from time
to time, and it does work. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
