As time passes, increasingly exotic features are being added to the Linux desktop environment. Some of these additions are unequivocal advances, some are neutral, and some represent big mistakes. Below I discuss some of the problems I've encountered while evaluating Fedora 17. (Read "Running Fedora Linux on Dell Laptops" for some prior issues.)

Figure 1: Mathematica 5.0 misbehaving under Fedora 17
with desktop compositing enabled (click for full-size)

Fedora 17 is the first Fedora version that enables desktop compositing (hereafter DC) by default, and IMHO it's a disaster. Many otherwise reliable applications refuse to render correctly unless they've been specifically coded to accommodate DC and fully tested. This obviously excludes most applications a typical user is likely to need.

I quickly noticed that, with DC enabled, if an application extended a list or menu outside the area of the app's frame, the content wouldn't be rendered correctly. And in some cases, a drop-down list or menu, fully within an app's frame, would also not render correctly. But when I tested Mathematica 5.0, I was in for a real surprise — it wouldn't render its document content at all (see Figure 1 on this page).

Over the years I've watched this Mathematica version's performance gradually deteriorate, but on principle I'm unwilling to solve the problem by periodically sending $2500.00 to Wolfram Research (that's Mathematica's current retail price), so instead I've used a number of increasingly hacky schemes to keep it alive, solely to avoid losing the time invested in many Mathematica programs I've written over the years. Parenthetically, now I mostly use and recommend the free and open-source Sage project (link to my Sage tutorial), but I have many older programs written for Mathematica that I don't want to lose.

First I tried solving the issue by manipulating fonts, a time-honored Mathematica issue, but eventually I realized I was misreading the problem — it wasn't about fonts, it was about rendering: text, in the document and in some dialogues, was being interpreted as an alpha (transparency) value instead of a color, and it happened that the "black" color value signified fully transparent. This meant that, if the Mathematica window overlay a white background as in part of Figure 1, most document content would disappear.

This problem results from one of the DC features — applications are able to control their degree of transparency, but older apps, owing nothing to the future, sometimes signal "transparent" unintentionally. I am sure there are many other legacy applications that will show text as transparent instead of black, or otherwise misbehave, so what follows should have general usefulness (not just for cheapskates unwilling to support Stephen Wolfram's lavish lifestyle).

Here are some solutions, from the simplest to the most complex:

• Press Alt-Shift-F12, which toggles the state of DC: disable DC, run the problem app, re-enable DC.
• Disable DC in System Settings (System Settings ... Desktop Effects ... deselect "Enable desktop effects at startup"). But if you then enable DC with Alt-Shift-F12 then run the problem app, you're back to square one.
• Use a script to selectively disable DC for problem applications, then launch the app. Example Python code (plain text version):

  #!/usr/bin/env python
  # -*- coding: utf-8 -*-
  
  # Copyright 2012, P. Lutus
  # Released under the GPL
  
  import sys,os
  
  def get_compositing_state():
    return os.system('qdbus org.kde.kwin /KWin compositingActive | grep -q true') == 0
    
  def toggle_compositing():
    os.system('qdbus org.kde.kwin /KWin toggleCompositing')
    
  def enable_compositing(request):
    if(request != get_compositing_state()):
      toggle_compositing()
      
  def help():
    s = ('disabled','enabled')[get_compositing_state()]
    print 'usage: -e(nable) -d(isable) compositing, currently %s.' % s
  
  if(len(sys.argv) < 2):
    help()
  else:
    arg = sys.argv[1]
    if(arg == '-e' or arg == '-d'):
      enable_compositing(arg == '-e')
    else:
      help()
                  

  The above could be called from a shell script, which would use it to disable DC and run the legacy application. This approach is recommended for end users who won't necessarily know or care about the issues being discussed here.

• Update: An early reader of this article has described another way to solve this problem in KDE:
  • Run the problem application.
  • Click the extreme upper left corner of the app frame (or Alt-F3).
  • Choose "Advanced ... Special Application Settings".
  • Choose the "Appearance and Fixes" tab.
  • Select "Block Compositing", select "Force" and "Yes".

  After making the above settings, close and re-open the program. Running the program should disable compositing for the duration of the program's run and re-enable it when the program exits.

  The drawback to this approach is that it needs to be applied to each system individually, it won't survive a system upgrade, and it's not suitable for untutored end users. The advantage is that it doesn't require an extraordinary script-based approach (as described above) for a single misbehaving application, and it restores the prior system state after the application exits.

I recently received an e-mail from someone who read my prior article about Fedora issues, and who told me Fedora 17 solved the backlight issue plaguing some Dell laptops (mine is a Dell Studio 1749 with an ATI video adaptor). But after I installed Fedora 17, I saw the same issue — no backlight control. The display dims on cue, but the backlight never turns off.

While addressing this issue I decided to update my previous hacky backlight control method. Originally I would read a certain system register (/sys/class/backlight/acpi_video0/brightness) and use it to decide whether display dimming was in effect. That method was incredibly hacky, even by my standards, because it used a specific /sys location that was bound to fail over time.

The new method uses qdbus to measure display brightness, in a slightly less hacky approach, as in this shell script:

#!/bin/sh

ob=""

while true
do
   # must use "Dim Display" control for this to work
   br=$(qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement \
        org.kde.Solid.PowerManagement.brightness)
   # if new and old values differ
   if [ "$br" != "$ob" ]
   then
      # if brightness is below a threshold value
      if [ $br -le 15 ]
      then
         vbetool dpms off > /dev/null 2>&1
      else
         vbetool dpms on > /dev/null 2>&1
      fi
      ob=$br
   fi
   sleep 2
done

Users of the above code will have to install vbetool from the usual repositories. Obviously the best solution is for someone to fix the original code, but after several years of waiting for that solution, we're still here. I'm sure system coders have more important things to do, like writing code to make windows wiggle like Jello and transparently fly across the desktop.

This KDE desktop issue is a simple problem with a simple solution. It happens when you have a dark desktop background image and the default desktop theme (for KDE under Fedora 17, that's "Beefy Miracle"). Under these circumstances, the task manager (the bar at the bottom of the KDE desktop display) is transparent and the task manager text cannot be read:

The solution is to choose a desktop theme other than "Beefy Miracle," one that doesn't make the toolbar transparent. After some experimentation I chose the Oxygen theme.

This is another bug that no one seems interested in fixing. A computer with an HDMI adaptor should be able to switch sound output to the HDMI display when it's activated. Lacking that, the user should be able to manually switch from the computer's sound system to the HDMI sound output. But on my Dell Studio 1749 laptop, neither is true. To make HDMI sound functional in a system with an ATI HDMI sound adaptor, one needs to do this:

• Edit and save the /etc/default/grub kernel boot configuration file:
  • One of the lines in this file typically looks like this: GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet"
  • Edit it to look like this (note the green text): GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 radeon.audio=1 rhgb quiet"
  • (This may seen unnecessarily detailed, but it turns out that the order of the options makes or breaks the desired outcome.)
• Run this commmand as root: "grub2-mkconfig -o /boot/grub2/grub.cfg"
• Reboot the machine.

Over the years, certain tastes and preferences have become apparent among the Linux kernel maintainers and primary Linux coders, including Linus Torvalds. Because of my many years in software development, I can appreciate some of the choices they've made. The two primary choices are to focus on server applications (i.e. "heavy iron"), or the desktop environment:

• The server side of the business is quite satisfying — one can make changes in the kernel code and receive coherent, detailed field reports from people just as motivated and professional as you are, and progress tends to be visible and tangible. Everyone wants to make the target servers as much alike as possible, for any number of reasons including economy and the kind of operational reliability that comes from a large installed base of nearly identical machines.

• The desktop, end-user side of the business, although important to the future of Linux, is extremely frustrating. THere are any number of target machines and models, and for various marketing and intellectual property reasons the machines tend to differ in ways that are simultaneously trivial and certain to break any code you write. You have to read bug reports written by people who never learned to compose clear prose of any kind, much less technical descriptions. And every once in a while, someone submits a bug report that includes a threat of legal action.

On the server side of the business, the hardware builders want to make their machines as much alike as possible, to assure reliability and ease of maintenance. On the end-user side, the builders want to make the machines differ in ways that will protect them from patent trolls, and to create the illusion that new machines are measurably different, better than old ones, to motivate end users to buy new hardware.

These forces make writing for servers much more fulfilling and rewarding than writing for desktop/end users. In fact, one wonders why anyone would want to write code for the desktop environment, and it gives us an insight into why Windows end-user code is so dreadful (Microsoft has exactly the same problem internally — no one wants to write code for the desktop).

In the old software marketing model (the one with which I am most familiar), you sold software and gave away support. In the new, open-source marketing model, it's the reverse -- you give away software and sell support (this is Red Hat's basic, and very successful, business model). Surprisingly, this reversal of the old model doesn't change very much -- people still don't want to deal with end-user environments and end users.

This is an area where Microsoft, because of its market share, has a key advantage. If a hardware vendor wants to build a new machine, compatibility with Windows is critical, and issues of compatibility accompany such a project like a silent business partner. But few care whether a new machine is Linux-compatible, except of course for Linux advocates, who are reduced to writing drivers and support software (like that aove) long after the machine has been released.

It may not be apparent from the perspective of the present, but I think Microsoft will eventually be seen as a historical aberration, sort of like a medieval printing guild that controlled all printing and related technologies, only later to be supplanted by ubiquitous, inexpensive printing presses and a gradual shift in public thinking that made printing seem to be the inalienable right of everyman. In the same way, eventually the idea that a single company could control something as basic as a computer's operating system will seem alien and undemocratic.

The best part of this process is that no governmental intervention or new laws will be required (or should be allowed). Microsoft will simply wither away, outcompeted by a radically different business model that gives away code and sells services and support.

In the meantime, however, something needs to be done about the Linux desktop experience, which at present is pretty terrible. It's split into too many variations, the largest of which are Gnome and KDE, each of which claims advantages over the other, and neither of which is an obvious winner. There seems to be too much attention paid to cutesy features like desktop compositing and special effects, and too little to longstanding bugs that every user notices after the last special effect has faded away.

End of digression.