====== Debugging Graphics Problems ======

If you are having problems with [[MarkLinimon/WorkAreaGraphics/|Graphics]] on %%FreeBSD%%, you may be asked to provide information from your system.

Here are some things that you need to know.

===== Getting Information =====

  * dmesg(8)

    * Everyone should become familiar with ''%%dmesg%%''.  (If the output is incomplete, you many need to look at ''%%/var/run/dmesg.boot%%''.)

    * Here are the relevant details from one very simple x86 system with graphics on the motherboard:

<code>
vgapci0: <VGA-compatible display> port 0xdc80-0xdcff mem 0xf6000000-0xf6ffffff,0xc0000000-0xdfffffff,0xf4000000-0xf5ffffff irq 24 at device 0.0 on pci2
vgapci0: Boot video device
[...]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
</code>

  * kldstat(8)

    * ''%%kldstat -v%%'' gives you detailed information about which devices are built into your kernel, and also, which other modules have been loaded. 

    * To find out if you have the ''%%drm2%%'' module loaded, and if so, where it came from:

''%%kldstat -v | grep drm2%%''

* [[https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/025004.html|xorg-udev-setup-check.sh]]

  * TODO document

* another tool

  * example

===== Debugging Tips =====

==== Complaints From glxinfo/glxgears ====

If you get **libGL error: failed to open drm device**, try the [[https://forums.freebsd.org/threads/various-programs-libgl-error-failed-to-open-drm-device.62446/|following suggestion]] from [[/CarlosPuga|CarlosPuga]]:

<code>
pw groupmod video -m <youruser>
cat >> /etc/devfs.rules << EOF
add path 'dri/*' mode 0666 group video
add path 'drm/*' mode 0666 group video
EOF
</code>

==== Kernel Features ====

  * It is useful to see what features the kernel reports as being available, especially in regards to driver features exposed via the linuxkpi.  On %%FreeBSD%% these are mapped to sysctl compat.linuxkpi. The best way to see what's available for your driver is to execute sysctl compat.linuxkpi after you loaded the driver.  For description of what these parameters do, call sysctl with the description flag. ''%%% sysctl -d compat.linuxkpi.enable_fbc%%''

''%%compat.linuxkpi.enable_fbc: Enable frame buffer compression for power savings (default: -1 (use per-chip default))%%''

==== DRM-specific issues ====

  * Periodically you will have a kernel panic but a core will not be recorded.  You can test setting this sysctl knob which will prevent you from entering ddb on panic which has been found to unreliable in some circumstances: ''%%debug.debugger_on_panic=0%%''

  * Also, adding this to your ''%%/boot/loader.conf%%'' can help in these scenarios: ''%%dev.drm.skip_ddb="1"%%''

  * The following can be useful for providing context and can be set in ''%%/boot/loader.conf%%'' to ensure debug output remains enabled. The one problem with it is that debug output will slow things down enough to mask many problems:

''%%dev.drm.drm_debug_persist="1"%%''

  * Want to enable all DRM related debug flags at runtime?  There is a knob for that:

''%%dev.drm.drm_debug=-1%%''

==== KMS Drivers ====

  * KMS drivers through linux-kpi report debugging information using debugfs. To mount it:

''%%# mkdir /debug && mount -t debugfs none /debug%%''

==== Hardware Acceleration ====

  * To test how hardware acceleration is working you may want to run ''%%glxgears%%'', but by default it may force syncing with your display (60fps for example).  To disable this you can invoke ''%%glxgears%%'' like so: ''%%$ env vblank_mode=0 glxgears%%''