AMD Catalyst: Fixing Underscan

The proprietary ATI Catalyst fglrx driver always tends to underscan on my 1080p Panasonic TV.

Underscan is the condition of seeing a smaller image than should be the case: a "black border" around the edges. It is sometimes set by default to counteract overscan (where the image is enlarged and cropped; a throwback from the old days of CRT monitors).

The method for fixing it is non-obvious. One expects to be able to adjust the underscan/overscan settings via amdcccle - the AMD graphical configuration tool - but all too often amdcccle doesn't make this facility available for HDTVs.

Let me briefly step you through the bizarre history of AMD's support for fixing underscan, before presenting the solution that works for today's drivers. If you can see any logic behind AMD's strange decision-making, I'd be intrigued to hear about it!

The solution to this problem used to involve aticonfig's* --set-dispattrib command. You had to establish which arbitrary display name (from a possible list of of 12 candidates) the driver was using to identify the monitor in question, then identify the size/position settings for that display, and play around with them until the output looked right.

This used to be the procedure:

1) One would find the "display type" (here I'm outputting the horizontal offset in pixels for each display, so of the display types that return values, I can determine which display is the one I want, based on the horizontal offset):

$ for disptype in crt1 lvds tv cv tmds1 crt2 tmds2 tmds2i dfp3 dfp4 dfp5 dfp6 ; do amdconfig --query-dispattrib=${disptype},positionX; done

2) Then one would find the relevant settings for the display identified as exhibiting underscan:

$ for dispattrib in positionX positionY sizeX sizeY overscan ; do amdconfig --query-dispattrib=<display type>,${dispattrib} ; done

3) Finally, one would check over these values and amend them as appropriate:

$ sudo amdconfig --set-dispattrib=<display type>,<display attrib to correct>:<correct value>

However, here's the problem with this method: if you're using RandR >= 1.2 (which you will be if you're running recent software), this procedure will fail with the following.

$ amdconfig --query-monitor
Error: option --query-monitor is not supported when RandR 1.2 is enabled!

The next step was to work around this by disabling XRandR (by editing /etc/ati/amdpcsd and adding EnableRandR12=Sfalse under [AMDPCSROOT/SYSTEM/DDX], and by adding Option "EnableRandR12" "false" under the Driver section of your xorg.conf).

Again, this has been superseded.

The new solution, for cases where XRandR is >= 1.2, took me a while to figure out, and is surprisingly non-intuitive.

There is a practically undocumented variable in AMD's Persistent Configuration Store (PCS), used to store AMD specific driver settings. It's called DigitalHDTVDefaultUnderscan, and if set to false, it disables underscan completely.

Following this procedure should remove the black border and restore your 1:1 pixel mapping:

$ sudo amdconfig --set-pcs-val=MCIL,DigitalHDTVDefaultUnderscan,0
$ sudo reboot

One wonders what AMD was thinking, leaving such a common and important task out of amdcccle, and without documentation. It's a serious oversight.

As for other secret PCS variables: you can find some in /etc/ati/amdpcsdb, some in /etc/ati/amdpcsdb.default, and the rest are buried somewhere in the output of strings /usr/lib64/xorg/modules/drivers/fglrx_drv.so

Not exactly what one could call intuitive.

*Note that aticonfig is now called amdconfig.

Raspberry Pi: Expanding the SD Card Partition

32GB card with an expanded root partition and
an expanded swap partition

The Debian image for raspberry pi only totals 1.8GB; so, if your SD card is larger than 2GB, a lot of space will be going to waste.

You can resize the partition directly via the Pi (the hard way), or you can take out the SD card and do it on another PC (the easy way). Let's do that.

Insert the SD card into your other computer. Don't mount the SD card; or if it automounts, unmount it first. Install and open gparted (the friendly GUI for parted):


# apt-get install gparted
# gparted

find your SD card device using the dropdown menu in the top-right. It might be obvious which it is from the partition sizes, but if in doubt, check. You can refer to the system logs:

# tail -n 1 /var/log/messages
Jun  4 17:46:02 ace2 kernel: [321194.297736] sd 9:0:0:0: [sde] Attached SCSI removable disk

Once you've selected the device, you should see a fat32, and ext4, and a swap partition. 

• the fat32 partition is the boot (/boot) partition
• the ext4 partition is your root (/) partition
• the swap partition is for swap space, but is by default unused by the Pi

You have various options here. To expand the root partition leaving other partitions untouched:

• select the swap partition, right-click and select Resize/Move. In the window that appears, drag the partition to the end of the available space, until "Free space following (MiB)" shows 0.
• select the ext4 partition, right-click and select Resize/Move. In the window that appears, drag the arrow on the right of the partition to the end, until "Free space following (MiB)" shows 0.
• ensure you have backed up any important data
• click the tick to "Apply all operations". This may take a few minutes. 

Now when you boot your Pi, your root partition should be considerably larger.

Swap space

4GB SD card with an expanded root partition and no swap

You are free to delete the swap partition instead of just moving it. By default, your Pi has swap space disabled, hence it is just wasted space anyway. 

Alternatively, you can enable use of the swap space via the swapon command or by editing /etc/fstab. I think the reason this isn't done by default is twofold:

• it will make heavy use of your SD card in terms of IOPs, thereby reducing its lifespan
• random read/write performance is pretty poor for SD cards, hence this might slow you down considerably

I think it's best to leave swap disabled, and delete the partition if you see fit.

Oracle v. Google v. Common Sense

Oracle's drawn-out legal campaign against Google has finally reached its conclusion. First came the judgment that Google has not breached copyright (aside from one elementary 9-line method), and that it has not infringed upon Oracle's patents. On Thursday, the final determination came, which asserted that APIs are non-copyrightable.  Here it is:

This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted

Groklaw

Finally, some common sense in the world of patent litigation. It's been a long time in coming.

This is great news for software developers everywhere, and we all owe a debt of thanks to Google (for not caving in and paying Oracle's ransom demands), to the FSF (whose support over the years has been invaluable), the EFF (with great coverage), those at Groklaw for their tireless monitoring of the trial, and countless others; not forgetting the patient jury and most learned judge.

The problem is this represents just the tip of the iceberg. Software patents are a menace to the very practice of software design, leaving programmers (especially lone programmers) at the mercy of corporations with large patent portfolios, even if their work is entirely of their own inspiration and manufacture. Software patents are simply nonsensical.

The argument for software patents goes like this: those who spend time and effort creating a product should be assured of their ability to reap financial rewards, free from risk of their competitors duplicating and reselling their work. Without this assurance, say the patent advocates, companies and individuals won't produce software. (You have to put open source to the back of your mind for this argument to hold water.)

Yet, every programmer knows that their work is amply protected by existing copyright legislation. Consider the Oracle v Google case: the only complaint that was even partially upheld was copyright violation in a single nine line method. Copyright assures that another competitor can't take your code and use it (even with changes) in their own product without your permission. They would have to rewrite it.

Software patents go further, and copyright ideas behind the code. Yet, there's an odd dilemma here: ideas which make up code are expressed in algorithms. Algorithms are not copyrightable.

You can't just go and copyright the concept of a loop. That would make programming nigh on impossible - unless you paid royalties to the owner of the "loop" patent. Yet, a loop is hardly that much of a mental leap when considering machine code. It's basic. Just because somebody wrote a loop first before somebody else doesn't give them the right to collect money from everybody who subsequently writes something similar. There are only so many fundamental programming constructs which one can use to write software with.

It's tantamount to copyrighting the method of harvesting an apple from an apple tree. Somebody managed it first - they made a mental leap, and determined that to acquire the apple, one needs to:

harvest_apple : apple
  while !sense_apple
    move_hand(observe_rel_pos(apple, hand)) 
  close_hand
  return pull_toward

Since this individual did it first, they should be able to receive money for every subsequent apple harvest that takes place on the Earth. This is the principle behind a software patent.

If software patents sound crazy, that's because they are. In too many cases, they prevent programmers from coding the obvious. It shows, too: the amount of litigation over software patents is simply astonishing. It's why Google bought Motorola for its patent portfolio. It's why Google's filing an antitrust suit against Microsoft and Nokia.

Yet the situation will be hard to change, as patents are worth a lot of hard cash, and no business wants to throw away most of its net worth. RIM's patents are said to be worth billions of dollars. Google bought Motorola for over $12bn, moreorless entirely for its patents.

Perhaps some common sense is coming to the situation. Kodak recently lost a case against Apple and RIM, where it was trying to enforce a patent around camera image previews. The judge threw out the case due to the "obviousness" of the patent. This case also highlighted the financial significance of these patents: Kodak's share price dropped 25% after the ruling.

This lunacy will have to reach a balance soon, between assurance of revenues on the one hand, and common sense on the other. At present, the only way companies can protect themselves is by investing billions in vast patent portfolios and expensive lawyers. A long term solution needs to involve more intelligence than this.

The supremely amusing factor in the Oracle v Google case was that the case concerned copyright and patents for Java. Up until only a couple of years ago, Java was owned by Sun Microsystems. Sun released Java under the GPL license to open things up to the community. Oracle bought out Sun in early 2010, and in just half a year, were taking Google to court for supposed infringement of Sun's patents. All this, even though Oracle's official position was only to use patents for defensive purposes.

It's really quite sad. Tarnishing an excellent reputation in just a couple of years, thanks to one company hell-bent on sapping R&D and replacing it with lawyers. How they could fail to realise that their existence depends on the developer community is mind boggling.  It's no wonder that the father of Java, James Gosling, has recently switched sides and joined Google. We wish him all the best.

There's been much dissatisfaction with Java 7, Java security, Java's falling behind other languages, and  plenty of other Oracle products of late. For example, think about Oracle's atrocious treatment of OpenOffice (which sat almost dormant, before the community branched off LibreOffice, and Oracle finally relinquished OO to Apache).

Oracle must stop pursuing quick monetary wins through unwarranted litigation, get back to developing their own software portfolio, and re-engage a battered, disillusioned and diminished community. Lest they slip and fall on their own sword.