Thanks to gwydion

I got my xorg.conf to finally work in Ubunutu 9.04 Jaunty. I was having problems where when I boot into ubuntu, I didn’t even get a login screen, it just froze at a black screen after boot up with a few artifacts of color here and there.

Took many, many hours trying to finding this solution. I ended up being able to use the proprietary driver fglrx when all was said and done, instead of having to use vesa.

Here is what I did:

dpkg-reconfigure xserver-xorg
aticonfig --initial -f --adapter=all
aticonfig --cfa --adapater=all
aticonfig --add-pairmode=<your width>x<your height>+<your width 2>x<your height 2>

Also had to add

Option "EnableRandR12" "false"

to each device section and

EnableRandR12=Sfalse

to the [AMDPCSROOT/SYSTEM/DDX] section of /etc/ati/amdpcsdb (source) in order to disable RandR 1.2

xorg.conf

# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# Note that some configuration settings that could be done previously
# in this file, now are automatically configured by the server and settings
# here are ignored.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "ServerLayout"
    Identifier     "aticonfig Layout"
    Screen      0  "aticonfig-Screen[0]-0" 0 0
    Screen         "aticonfig-Screen[1]-0"# RightOf "aticonfig-Screen[0]-0"
EndSection

Section "Files"
EndSection

Section "Module"
EndSection

Section "Monitor"
    Identifier   "aticonfig-Monitor[0]-0"
    Option      "VendorName" "ATI Proprietary Driver"
    Option      "ModelName" "Generic Autodetecting Monitor"
    Option      "DPMS" "true"
    HorizSync   30-82
    VertRefresh  56-76
EndSection

Section "Monitor"
    Identifier   "aticonfig-Monitor[1]-0"
    Option      "VendorName" "ATI Proprietary Driver"
    Option      "ModelName" "Generic Autodetecting Monitor"
    Option      "DPMS" "true"
    HorizSync   30-82
    VertRefresh  50-75
EndSection

Section "Device"
    Identifier  "aticonfig-Device[0]-0"
    Driver      "fglrx"
    Option      "EnableRandR12" "false"
    Option      "PairModes" "1680x1050+1280x1024"
    BusID       "PCI:3:0:0"
    Option          "XAANoOffscreenPixmaps"
EndSection

Section "Device"
    Identifier  "aticonfig-Device[1]-0"
    Driver      "fglrx"
    Option      "EnableRandR12" "false"
    BusID       "PCI:4:0:0"
    Option          "XAANoOffscreenPixmaps"
EndSection

Section "Screen"
    Identifier "aticonfig-Screen[0]-0"
    Device     "aticonfig-Device[0]-0"
    Monitor    "aticonfig-Monitor[0]-0"
    DefaultDepth     24
    SubSection "Display"
        Viewport   0 0
        Depth     24
        Modes      "1680x1050_75.00"
    EndSubSection
EndSection

Section "Screen"
    Identifier "aticonfig-Screen[1]-0"
    Device     "aticonfig-Device[1]-0"
    Monitor    "aticonfig-Monitor[1]-0"
    DefaultDepth     24
    SubSection "Display"
        Viewport   0 0
        Depth     24
        Modes      "1280x1024_75.00"
    EndSubSection
EndSection

This probably is a solution for the 4870 X2, or any other X2 based board.

Added another shortcut… I had a config variable in my settings_local file to specify where the media folder was in order to have django static serve it.

This is much easier.

urls.py:

if DEBUG:
    import os
    media_root = os.path.join(PROJECT_ROOT, 'media')
    urlpatterns += patterns ('',
        (r'^media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': media_root}),
    )

A common problem I have had is that too much work was required when I needed to deploy my django project, or if i needed to work on the project on another computer. Subversion has been my friend, but part of the problem is the necessary local settings in each of the projects.

In addition to the overall structure between all my projects, I have developed a few tricks to make handling things inside of a project much easier.

Previously, my template folder and my media folder were in different parent directories. This caused me to need to change several variables in the settings.py (or my settings_local.py) of django in each environment that it existed in. However I no longer have to do that.

Inside my settings.py I have this:

import os, sys
PROJECT_ROOT = os.path.dirname(__file__)
sys.path.insert(0, os.path.join(PROJECT_ROOT, 'apps'))

The first two lines figure out the directory that the settings.py lives in The third line inserts my apps folder to the python path (this works great with my django directory structure)

Now, the next step for me was to move my template and media directories around. My directory structure for a project is as follows:

-project
–media
—css
—js
—images
–templates
—application template directory 1
—application template directory 2
—base.html
–apps
—app1
—app2
–settings.py
–settings_local.py

So as you can see, my templates folder is in the same directory as my settings.py. My media folder is too. In order to avoid making this a variable too:

MEDIA_ROOT = os.path.join(PROJECT_ROOT, 'media')

TEMPLATE_DIRS = (
     os.path.join(PROJECT_ROOT, 'templates'),
)

Over the course of my web development life, I have changed my work flow and directory structure many times. Each time gets a little bit better, but I doubt I will ever finish modifying it, as I am always learning new techniques.

I am presently using Django in all of my projects, both at work and as a hobby. Django’s ability to easily reuse applications has mad me change my directory structure several time. Finally, I do believe I have settled.

First thing to know, is that both at work and in my pet projects, I am hosting multiple websites on the same apache instance. This is simply because the load behind the website does not justify buying a new slice (I use slicehost for my hosting needs).

I also make use of several available applications out there, django comment utils, django tagging, and django-registration just to name a few (all/most are findable through django pluggables)

So that being said, I need to have a directory structure capable of handling each one of my projects, all of my own shared applications, and all of the downloaded applications.

Here is what I have come up with.

• projects/
  – project 1/
  — apps/
  —- non reusable app 1/
  —- non reusable app 2/
  – project 2/
  – project 3/
  —apps
  —- non reusable app 3/

• common/
  – self made reusable app 1/
  – self made reusable app 2/

• external/
  – grabbed reusable app 1/
  – grabbed reusable app 2/
  – grabbed reusable app 3/

Basically, the idea being that I store my projects in the projects folder, with applications made just for that project in the project’s application folder.

I put applications that I build that will be used by more than one project into the common folder.

Applications that I have grabbed from other people (comment_utils, tagging, etc) into the external folder.

Then for each virtual host, I add to the python path the projects folder, then reference settings by projectname.settings (from observation, django adds the folder where the settings file is to the python path itsself), and the common folder and the external folder. I also add the projects, external, and common folders to the python path inside of conf file.

That works for apache, but then to get manage.py to work (it doesn’t work because none of the python paths are set for it), I edit “/etc/environment” and add the line

PYTHONPATH="/home/username/projects:/home/username/common:/home/username/external"

Bingo, now manage.py works.

Now, any time I want to add a new project, I do not have a ton of hassle trying to get the project’s manage.py to work, and all my virtual hosts in apache have the same structure!

Subversion has been my friend ever since I learned about it. However, it took me a while to figure out how to deal with configuration files. For Django, this specifically relates to the settings.py.

Django projects can end up on many different environments. Putting settings.py into source control directly will cause our settings to migrate across all working copies. This is not reasonable, as not every person will have the same environment (not all using mysql, not all using the same directory).

Removing settings.py from version control, and make a separate settings.py.template file that contains just the basic structure is a solution to that. However, it brings another problem: What if you want to change a used application or a middleware? You would then have to make that change on all working copies.

My solution has been to make a settings_local.py.dist

This file has variables in it like media path, database information, and caching options. You can copy these things straight out of the settings.py (and delete them from settings.py)

This file will go under version control.

Now, in your settings.py, add the line

from settings_local import *

(I added the line to the very bottom of my settings.py)

So, now when a working copy of the project is grabbed, the person behind it can copy settings_local.py.dist to settings_local.py. Inside settings_local.py the environment’s details are placed. This file will be ignored from version control.

With this setup, you can add an application or middle ware to settings.py for easy distributing through version control, and it will not affect a workspace’s local variables.

Over the course of my programming life, I have written some form of blog in perl, then php, then in a framework of php, then ruby on rails, and now Django.

The real purpose of this site is to get an understanding of every component that goes into a blog. This is without a doubt the best one I’ve ever written, but the same could be said about each of the ones I built before at that time.

This website is built in Django, where I currently build most of my applications now.

In addition to the building of the blog, I decided that it is time for me to write some of my technical thoughts down.

Yes I like to share, discuss, and debate many technological things, however another purpose of this site is to store my docs so that I can grab them anywhere. Not real big things or private things, but things like, a step by step on server setup, so that I can copy paste my long apt-get install command, without trying to remember it from memory.

This serves that purpose well.

This blog is obviously not complete. I will finish it over time, but it does share the same code with another website, so any improvements will reflect on both.