This is currently a few scrappy notes just to jog my memory as to things to try. Messing about with monitor settings can blow your monitor, graphics card and probably both; although in practice sensible use should ensure that never happens to you.

Note that some of these commands may not exist on your system, if you need to install them, then remember to install into the chroot, e.g.:

# chroot /opt/ltsp/i386
# apt-get update
# apt-get install lshw
# exit

Erm, suppose I should mention this whole page was tested on Debian Lenny.

Cables

Do consider trying a new monitor cable - as a poor quality or damaged cable can cause problems that are difficult to trace. A few seconds to try a different cable might save you endless time.

A word about drivers

There are often multiple drivers for a particular graphics card, for example with nvidia cards you can sometimes use the opensource “nv” driver and sometimes the proprietary “nvidia” driver, and I believe there is a “nouveau” driver, which I have not yet experienced. Similarly in intel, stipulating that the driver should be “intel” may solve your problem. See lspci below for details.

X Authority

All of the following commands were run from an ssh session to the thin client itself, for this to work you need to install openssh-server in the chroot. Alternatively you can simply go to the client and type ctrl-alt-f1 to access to the client’s console and type the following commands from there. Obviously the benefit to the ssh approach is that you can do it remotely and cut and paste from your browser into the client.

We need to be able to access the xserver from the console, so we need to set the XAUTHORITY:

# export XAUTHORITY=`find /var/run -name Xauthority`
# echo $XAUTHORITY
/var/run/ldm-xauth-qOQkpTdNp/Xauthority
# export DISPLAY=:7
#

Useful Programs

lspci

In order to google your problems, you’ll need to know the make and model of your graphics card, to find this out, run the lspci command:

# lspci
# lspci -v | more

The first command is a summary, the second command gives you more information. The “VGA compatible controller” is probably for what you’re looking.

lshw

List Hardware will list all the hardware on your PC.

# lshw -C display

getltscfg

Report all the settings from lts.conf which apply to this terminal. This helps diagnose those occasions where the client is refusing to obey your lts.conf commands.

# getltscfg -a

xvidtune

xvidtune -show will report the current monitor settings as a modeline:

# xvidtune -show

You can also run xvidtune as a localapp when logged into the thin client:

"/usr/bin/ltsp-localapps xvidtune"

xdpyinfo

xdpyinfo reports a great many details from the xserver, including resolution, colour depth etc:

# xdpyinfo | more

gtf cvt

There are two tools for creating a modeline - gtf and cvt. My understanding is that cvt is the newer tool, in use from 2003, but tbh I really don’t know which you should use. Both tools work in the same way. Some examples:

# gtf 1920 1080 60
# cvt 1280 1024 75

xrandr

To save rebooting endlessly you can test monitor settings on the fly with xrandr:

# xrandr
# xrandr --newmode "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync
# xrandr --addmode VGA "1920x1080_60.00"
# xrandr --output VGA --mode "1920x1080_60.00"
# xrandr --auto

The first command provides you with useful information about your xserver, including the available modes, and most importantly the available “outputs” (these are your monitors/displays); in the above example my only output is a monitor called “VGA”. newmode creates the newmode (e.g. as output by gtf or cvt), addmode makes that mode applicable to the output, and the next command activates that mode. The final command “auto” will reset your display automatically, probably your previous settings.

References

For once almost all of this was my own work, and so all my fault ;). That said the following page was helpful to me in the section about xrandr:

• https://wiki.ubuntu.com/X/Config/Resolution

The DPI problem was fixed very easily by following the instructions on the link I provided in my previous post, I calculated that my Sony Bravia KDL 32S3000 had dimensions of 700mm x 390mm and a native resolution of 1366x768.

$ xdpyinfo | grep dimensions
$ xdpyinfo | grep "dots per inch"

Converting the millimetres to inches and dividing the resolution by the inches dimensions gave me DPI of 50x50, surprisingly low. I believe this is because the KDL 32S3000 is not a full HD TV but only 1080i. Setting this in /etc/X11/xorg.conf cured the problem with the KDM login manager.

Section "Monitor"
    Identifier "Monitor0"
    Option   "DPI" "50 x 50"
EndSection

If the display resolution is VGA, the run:

$ dpkg-reconfigure xserver-xorg

When configuring XORG, do ensure that the maximum resolution is as you want it, as this will be the default resolution for every boot.

It’s been bothering me for some time that I am using Kubuntu instead of Debian on my work desktop PC. Yesterday I had a drive failure necessitating a reinstall; what better excuse could there be? Having decided to change to Debian, I decided to install Sid, and then I decided that, as KDE 4.1 is now out, why not go the whole hog.

The experience was pretty positive, really the only problem was that I needed to tweak the xorg.conf in order to get my keyboard and mouse working, other than that it was a pretty straightforward install.

Section "ServerLayout"
    Identifier   "Default Layout"
    Screen       "Default Screen"
    Inputdevice  "Generic Keyboard"
    Inputdevice  "Configured Mouse"
EndSection

Installing VirtualBox was not such fun, but the following link sorted me out:

• Virtualbox OSE Debian Install

So far I have installed Iceweasel3, OpenOffice3, NoMachine NX Client and VirtualBox, and it’s running really nicely. I have activated the KDE4 compositing effects, which seem very slow, so hopefully some room for improvement there in subsequent releases.

So would I recommend Debian Sid KDE4.1 over Kubuntu? Well I think that’s an unfair comparison, as I’ve installed a bleeding edge solution, but all-in-all it really wasn’t a scary installation at all.

Well done to the Debian team.