From Fedora Project Wiki

< KDE

(add vaapi vdpau pkgs)
(pkgs)
Line 98: Line 98:


'''Dualhead''' systems (two physical displays) behave differently. While performing speed tests with '''glxgears''' tool described below, runing gears may give good results on one display and when dragged to another that does not have an active acceleration, results fall. KDE system setting's ''Display section'' has ''Primary display'' (xrandr ''--primary'' vs ''--noprimary'') setting. When that is set to No primary output/--noprimary, the GLX rendering performs with the same speed on both displays.
'''Dualhead''' systems (two physical displays) behave differently. While performing speed tests with '''glxgears''' tool described below, runing gears may give good results on one display and when dragged to another that does not have an active acceleration, results fall. KDE system setting's ''Display section'' has ''Primary display'' (xrandr ''--primary'' vs ''--noprimary'') setting. When that is set to No primary output/--noprimary, the GLX rendering performs with the same speed on both displays.
Packages: '''glx-utils'''


* https://en.wikipedia.org/wiki/OpenGL
* https://en.wikipedia.org/wiki/OpenGL

Revision as of 15:39, 12 March 2019

Some lose, partially undocumented, but useful debugging tips and tricks found here and there in discussions, bug comments etc.

General

Free space running out in home or system's /tmp directories is likely to cause problems. KDE will start loosing application configurations etc, very unwanted behaviour so always having some free space is recommended. Likely culprits/locations filling the disk are:

  • $HOME/.local/share/baloo
  • $HOME/.local/share/akonadi

Useful tool for space issues can be found from Program menu -> Utilities -> Filelight

NFS as $HOME directory storage solution might cause problems, there are bugs that hint to that direction but NFS is probably so rarely used among KDE developers. Related bugs:

Some processes require access rights (web browsers, file management over ssh, etc) and may pop up an own or kwallet dialog for password. With multiple virtual desktops and multiple open windows, that small dialog window may get buried and missed, keeping that given process waiting for - and maybe haging something in desktop environment. Going trough all windows to ensure that no such dialog is open could solve some hangups.


Display adapters

lspci |grep VGA 
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710 [Radeon HD 4550]
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710 [Radeon HD 4550]


X11 or Wayland?

$ echo $WAYLAND_DISPLAY 
wayland-0

or at X11 it returns empty line.

Display modes

xrandr 
Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 8192 x 8192
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DVI-1 connected 2560x1440+2560+0 (normal left inverted right x axis y axis) 597mm x 336mm
  2560x1440     59.95*+
  1920x1200     59.95  
  1600x1200     60.00  
  1680x1050     59.88  
  1280x1024     75.02    60.02  
  1280x800      59.91  
  1152x864      75.00  
  1024x768      75.03    60.00  
  800x600       75.00    60.32  
  640x480       75.00    59.94  
  720x400       70.08

Asterisk denotes active mode, first value is resolution, second refresh rate.

xdpyinfo 

% xdpyinfo|less
% xdpyinfo|grep dimensions
  dimensions:    5120x1440 pixels (1354x381 millimeters)

Kernel and DRI

Direct Rendering Interface between kernel and display process.

Basic information: 

% xdriinfo             
Screen 0: r600

% xdriinfo driver 0
r600

% xdriinfo options r600
<driinfo>
<section>
<description lang="en" text="Performance"/>
.
.
.



driconf

Is a GUI tool that should be run as normal user, it creates ~/.drirc for startup.

Directory 

/sys/kernel/debug/dri/0/

contains DRI debugging information.

OpenGL and GLX

OpenGL is an API for rendering 2D and 3D vector graphics. GLX is its implementation for X Window System. They utilize kernel DRI hardware interface. 

% glxinfo| grep rendering
direct rendering: Yes

% LIBGL_DEBUG=verbose glxinfo | grep libGL
libGL: pci id for fd 4: 1002:9540, driver r600
libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so
libGL: Using DRI3 for screen 0

Dualhead systems (two physical displays) behave differently. While performing speed tests with glxgears tool described below, runing gears may give good results on one display and when dragged to another that does not have an active acceleration, results fall. KDE system setting's Display section has Primary display (xrandr --primary vs --noprimary) setting. When that is set to No primary output/--noprimary, the GLX rendering performs with the same speed on both displays.

Packages: glx-utils

VAAPI & VDPAU

vainfo

vdpauinfo

Pacakges: libva-vdpau-driver libvdpau-va-gl libvdpau vdpauinfo

.xsession-errors

Users $HOME/.xsession-errors is the 'standard output and error' of graphic desktop. Most lines are not prefixed with source nor timestamp so it might be hard to understand from which process they're coming from.

Xorg.0.log

System wide X11 log /var/log/Xorg.0.log contains all base windowing system, graphic hardware, user interface like mouse, keyboard, tablet etc related log and error messages. Especially userful if problems are related to display controller's driver.

xvinfo, xwininfo, xprop

xvinfo

xwininfo -root -tree

xprop _NET_WM_PID

and click the window in question.

xprop can also set process variables, jonisalonen.com - Setting X11 window properties

X11 speed tests

x11perf 

x11perf -all

glxgears 

glxgears
Running synchronized to the vertical refresh.  The framerate should be approximately the same as the monitor refresh rate.
33 frames in 5.6 seconds =  5.927 FPS
5 frames in 5.0 seconds =  1.000 FPS
6 frames in 6.0 seconds =  1.000 FPS
6 frames in 6.0 seconds =  1.000 FPS

Working system should give 1000 - 2000 FPS or even more. 

LIBGL_ALWAYS_SOFTWARE=1 glxgears
1579 frames in 5.0 seconds = 315.758 FPS
1589 frames in 5.0 seconds = 315.888 FPS
1407 frames in 5.0 seconds = 281.383 FPS
1442 frames in 5.0 seconds = 288.396 FPS

gives software Mesa FPS, which should be lower than hardware accelerated FPS on same system.

gam_server

Sometimes it helps to kill the gam_server process to release odd hangups or when applications wont start from panel buttons. Process can be safely killed, it gets respawned automatically, but running processes might not like it. Once killed, all pending start attempts are executed if the gam_server was the culprit. Sending a SIGUSR2 to running gam_server makes it dump its debugging information into /tmp/gamin_debug_* 

kill -s SIGUSR2 $(pidof gam_server)

x11trace

Xtrace fakes an X server and forwards all connections to a real X server, displaying the communication between the clients and the server in an (well, thoretically) human readable form.

http://xtrace.alioth.debian.org/

IPC files

IPC socket files (Inter Process Communication) on disk are used to pass information between desktop processes. These are located in user's home directory, under ~/.kde. 

[tuju@wasa]~/.kde% ls socket*
lrwxrwxrwx  1 tuju tuju   26 feb  2  2015 socket-wasa.example.com -> /run/user/500/ksocket-tuju

The interesting bit is to trace to which socket/file/pipe the fd belongs to. In the full strace log can be tracked back the fd number to see the syscall which opened it. Or doing an 

# ls -l /proc/$pid/fd

also shows the open fds. The symlink contents "pipe:[20043922]" are a unique ID; the other end of the pipe will have a matching ID. 

# (find /proc -type l | xargs ls -l | fgrep 'pipe:[20043922]') 2>/dev/null

should show you both ends of the pipe. Or using lsof: 

# lsof | grep 90222668


More about IPC-files:

DBUS

DBUS can be followed using dbus-monitor, it can be lousy thou and hard to follow. Wireshark has dissector for dbus these days but it doesn't do that good job on it. 

dbus-monitor

Certain processes can be queried during their runtime using qdbus 

$ qdbus | grep address
org.kde.kaddressbook

$ qdbus org.kde.kaddressbook
/
/KAddressBook
/kaddressbook
/kaddressbook/MainWindow_1
/kaddressbook/MainWindow_1/actions
.
.
$

adding more options gives more information of running process. Some options allow remote controlling process and triggering its methods.


GDB

$ gdb dolphin
(gdb) set follow-fork-mode child
(gdb) run

KDE4 ()

plasma-desktop

KDE5 (F24, F25, F26, F27)

Two main desktop components, kwin_x11 a window manager and desktop's shell - the plasmashell processes that can both be restarted on running desktop, without need to re-login with new session. If krunner process is working on desktop, using ALT+F2 pops up a small command dialog at the top of screen. All commands can be run through that or in separate konsole window(s), where latter allows folloing their character based output as they run.

Enviroment variables for KDE on Fedora are set system widely in /etc/profile.d/kde.sh - if something needs to be added permanently, that is the right place.

Qt

Qt 5.x recognizes the following environment variables that affect to the logging: 


c=echo -e "\033"
export QT_MESSAGE_PATTERN="%{appname}(%{pid})/(%{category}) $c\[31m%{if-debug}$c\[34m%{endif}%{function}$c\[0m: %{message}"
unset c

QT_LOGGING_RULES='*=false'

should suppress all logging. 

QT_LOGGING_RULES="*.debug=false"

should suppress debugging messages. 

QT_NO_GLIB=1 dolphin

should run dolphin without glib's event dispatcher and use the more straight forward Qt unix event dispatcher. 


QML_IMPORT_PATH=$QML2_IMPORT_PATH
QML_DISABLE_DISK_CACHE=1

Uses or disables ~/.cache/plasmashell/qmlcache as QML-cache storage.

kdebugdialog / kdebugdialog5

kdebugdialog is a gui configuration dialog that is used to switch on/off KDE debugging information. All increased information will be in .xsession-errors file.

--fullmode Show the fully-fledged dialog instead of the default list dialog

System journal

Ksystemlog (/usr/bin/ksystemlog) is KDE GUI for system journal and maybe easier to use for some.

kwin_x11

kwin_x11 can be killed or replaced by itself with --replace option. Once its not running, all virtual destkop windows appear at one view. Having a konsole open during replace might be useful. A typical ALT+F2 restart is done in krunner dialog: 

kwin_x11 --replace

High processor load on these processes implies that hardware acceleration (GLX, DRI) is not working properly.

Some regocnized environment variables: 

export KWIN_USE_INTEL_SWAP_EVENT=0 # only affects intel IGPs 
export KWIN_EXPLICIT_SYNC=0 # most likely candidate on nvidia GPUs 
export KWIN_USE_BUFFER_AGE=0 # well, you tried, but hey ... ;-) 

kwin_x11 --replace &

xsel

xvkbd

xclip


xdotool lets you programatically (or manually) simulate keyboard input and mouse activity, move and resize windows, etc. It does this using X11's XTEST extension and other Xlib functions.

For example if screen is locked 

xdotool key "XF86LogGrabInfo"

dumbs all device grabs into /var/log/Xorg.0.log file. It can be run from character based consoles by prefixing it with DISPLAY=:0 

xdotool selectwindow getwindowpid

followed by click to window returns its process id.

More KWIN debugging tips at KDE: https://community.kde.org/KWin/Debugging

keyboard layouts

kded related entries in kdebugdialog should be activated. 

$ setxkbmap -print
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+it:2+inet(evdev)+group(shifts_toggle)"   };
        xkb_geometry  { include "pc(pc101)"     };
};

$ setxkbmap it

sets the layout.

Config files: 

/usr/share/kde-settings/kde-profile/default/share/config/kxkbrc
~/.kde/share/config/kxkbrc

plasmashell

plasmashell can killed and restarted during the same session. Some of its plugins are known to leak memory and thus it can grow and cause problems in memory footprint wise during long session. Removing plugins one by one might help to pinpoint the problematic one.

Akonadi

Akonadi was created and said to be a PIM 'cache'. Well, it tries to do that, but it's much more than that. It for example stores part of program configuration. Flushing cache, one flushes part of congfiguration like IMAP-connections that has to be reconfigured.

Unlike in KDE4, restarting akonadi service in console doesn't print its std out/errors anymore.

In its own package akonadiconsole is available a graphical debugging tool, which is a tool for Akonadi developers that provides means of direct interaction with the Akonadi storage, SQL debugging, protocol debugger and other tools.

  • Browser tab: Selecting a given collection, like IMAP inbox ->RMB menu - > Clear Akonadi Cache
  • Command line: akonadictl fsck makes consistency checks

See also:

Storage backend

Akonadi uses SQL-database (unfortunately) for its storage. In its table layout it uses RDBMS closure table theory to provide endless hierarchy structure by linking itself recursively with parent id.

It all starts from collection where, for example the IMAP connection name is inside the table collectiontable and its given name can be found from column name. Next in IMAP hierarchy are the folders that contain messages. An 'INBOX' can be found from collectiontable where its parentId is the same as connection's id was.

Mapping of all content, like IMAP messages is done in pimitemtable, and messages for given INBOX are linked to parent collectiontable with column collectionId. That links the content to remote service and has timestamps.

Actual content resides inside parttable and it links to given content entry, like IMAP message with pimItemId column. All message parts like header rows and actual body (partTypeId linked to parttype table name RFC822) are stored there.

Deleting cached content from the tables should take place in pimitemtable, as parttable has proper ON DELETE CASCADE constraint and all related rows will be deleted from there as well. Entries in the collection are related to the configuration and folders, not to the actual content.

Kmail

If kmail hangs, it should be run in gdb debugger, as it uses multiple threads and sub-processes and if some of those crash, it wont be visible on screen nor in terminal that started the main process.

Other

All programs that try to open file dialog, just hang. Creating a new Korganizer entry just hangs. Is there any dolphin processes running? Try killing them all. Does that solve the problem?

File $HOME/.kde/share/apps/kfileplaces/bookmarks.xml may be slowing things down. 

wc -l /home/tuju/.kde/share/apps/kfileplaces/bookmarks.xml
61155 /home/tuju/.kde/share/apps/kfileplaces/bookmarks.xml

contains 61k rows.

See also

External links

Retrieved from "https://fedoraproject.org/w/index.php?title=KDE/Debugging&oldid=536408"