Accidentally fixing problems I didn't know I had

Peter Wemm

• 2 min read

I confess. I use KDE on FreeBSD on my primary desktop. The nVidia drivers were the big enabler for me and it was enough to switch back from an OSX desktop to FreeBSD. My desktop demands weren't that great - my main use case was to be able to maintain a browser, an email client, and an insane number of ssh windows. My KDE pager has 20 desktops (the limit!) and the steady state is full. I hit the 256 client limit of Xorg fairly regularly. I run FreeBSD-current, right now that's 12.x - the bleeding edge.

Lately my misery level had been rising. Not a lot, but enough that I noticed that things weren't quite as crisp and responsive as I thought they should be. I came to the conclusion that it was probably bloat in FreeBSD and tried to put up with it.

I'd see things like kwin_opengl_test crash at kde startup, but dismissed it because OpenGL was clearly still being used. Other things would be slower than they should be. Buffering was a bit off. Lots and lots of small things but together they actually had me noticing how much more responsive things like OSX and Windows10 were as a desktop.

Then it happened. I did one more update and all hell broke loose. All the nifty KDE GL compositor effects died and the desktop turned into a slug. A great deal of profuse language followed. My .xsession-errors file showed that kwin was unable to create an OpenGL context.

A flurry of internet searches lead me to the ~/.kde4/env/kwin_env.sh file and I tried setting: export KWIN_DIRECT_GL=1 in it. Another warning message advised me to set export __GL_YIELD="USLEEP" as well and I did. To say that the improvement was profound would be quite an under-statement.

Many people would be happy with it working and post things for people to cut & paste. I wanted to know why?

Various internet searches lead to me to mailing list pages and a picture began to emerge. It appeared that my installation of KDE + nVidia OpenGL had been a while and it looked like it had been running in OpenGL-over-X11 protocol, aka indirect GL mode, and using Xorg as a proxy. Versus using OpenGL directly. It also appeared that the most recent Xorg upgrade I did caused indirect GL to be disabled and that finally made the house of cards come crashing down. Why now? I have no idea. I found references to this change being made some time in 2015 so I should have seen it long before now.

These changes look like it may have affected other things too. For example, Firefox is suddenly much more responsive. Spectacularly so.

But now I have a dilemma. I want to know more and I am unsatisfied with what I think I have learned so far. But I am now at the point where I would have to disrupt my ability to get work done. My work environment is set up organically and disrupting 200+ ssh sessions isn't something without a cost.

Things I don't know:

  • why does kwin_opengl_test fail now?
  • why does __GL_YIELD=USLEEP seem to help? [It should be the same as sched_yield on FreeBSD.]
  • why did it break in the last few weeks when it should have broken in 2015 some time?
  • Is the spectacular Firefox speedup because of Firefox itself or because of those settings?

I am at the point where I am going to give in. To fix FreeBSD with KDE4 with nVidia binary drivers and OpenGL, I present for your cut & paste pleasure:

$ cat ~/.kde4/env/kwin_env.sh
#! /bin/sh
export KWIN_DIRECT_GL=1
export __GL_YIELD="USLEEP"
$ chmod +x ~/.kde4/env/kwin_env.sh

This tells KDE4 to NOT test the OpenGL libraries and instead assume that they work and just use them. It tells the OpenGL libraries to use usleep(0) instead of sched_yield().

KDE's documentation on environment variables.

Thoughts, feedback? Try twitter here