Adblocking with DNS


Ads on websites can be both annoying and resource intensive for older PowerPC systems. Waiting for the browser to load all the ads just so you can use the site can be trying on your patience. This is where adblocking becomes a great help.

Dan has a really good post comparing different types of adblocking tools for TenFourFox. I would like to suggest another method you can use that will take the work of adblocking off of your browser and machine by using DNS. If you have a spare machine (I will be using my Mac mini G4 running Jessie) then setting this up will be pretty simple.

First we will install bind9 then setup DNS caching and forwarding. Then we will setup the adblock portion. Finally we will set up a simple webserver to present a transparent pixel instead of the ads.


Setting up DNS caching

First we will need to install bind9 if you have not already. This is as simple as running the command as root, apt-get install bind9. Next you will want to edit the file /etc/bind/named.conf.options. Below is my file.

acl goodclients {
    192.168.0.0/24;
    localhost;
    localnets;
};

options {
    directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

    // If your ISP provided one or more IP addresses for stable
    // nameservers, you probably want to use them as forwarders. 
    // Uncomment the following block, and insert the addresses replacing
    // the all-0's placeholder.

     forwarders {
         208.67.222.222;
        208.67.220.220;
     };

    //========================================================================
    // If BIND logs error messages about the root key being expired,
    // you will need to update your keys.  See https://www.isc.org/bind-keys
    //========================================================================
    dnssec-validation auto;

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
};


The acl section defines who is allowed to ask queries to the DNS server. This stops unwanted people from trying to use your server. It is better suited if this was server was accessible from the internet, but it is good practice to do.

Next we want to turn on recursion and define who is allowed to query. DNS recursion is when the DNS server queries other servers on behalf of the client and sends the reply back.

Then we will define the forwarders to use. Some people refer google DNS, but I like using OpenDNS. This should be all you need to set up caching. A great tutorial on DNS caching the can be found at Digitial Ocean.


Adblocking

Now you need to get a blacklist file, which can be found here. Select the bind8 option and download the file. The open it and edit the zone lines to look as follows.

zone “101com.com” IN { type master; notify no; file “/etc/bind/null.zone.file”; };

If you are handy with vim then doing this should be really quick and easy.

The next thing is to copy the file to the /etc/bind directory and add this line to the /etc/bind/named.conf.local file.

include “/etc/bind/blacklist”;

Now it is time to create the /etc/bind/null.zone.file. This will redirect the ad urls to the simple webserver we will setup shortly. You want to set the A records to point the web server. In my case the mini serves as both. Here is my file.

$TTL 86400 ; one day

@ IN SOA ads.attlocal.net. hostmaster.attlocal.net. (
2002061000 ; serial number YYMMDDNN
28800 ; refresh 8 hours
7200 ; retry 2 hours
864000 ; expire 10 days
86400 ) ; min ttl 1 day
NS debian-minippc.attlocal.net

A web server

@ IN A web server
* IN A web server


Now you want to restart bind so that it takes all these changes you made. The first command to run is named-confcheck. This does a sanity check on the configs. If all is good then you should return to the prompt. Then to restart the command is systemctl bind9 restart and to check status of the service systemctl status bind9.

This finishes all that you need to set up the DNS server.


Pixelserver

Like I said in the beginning we want to set up a simple server to present a transparent image to replace the ads. If not then you page will full of page not found errors.

Pixelserver is a simple pearl script that can be found here. Download the file and edit it so that the listening ip address is your server. Then you change the permissions and run the server.
chmod u+x pixelserver.pl
./pixelserver.pl

Now point your machine to get DNS requests to your  server and test. Here is an example of a successful query.
herminio-hernandezs-power-mac-g4:~ herminio$ nslookup foo.doubleclick.com
Server: dns server
Address: dns server#53

Name: foo.doubleclick.com
Address: pixelserver

You should see the domain name point to your web server. Now browse the web ad free!

UPDATE I:

If you want to start the pixelserver.pl script on boot. Then you going to have it managed by systemd. This is not too hard to do.

First I put a copy of the script in the /usr/bin directory. Then entered the /etc/systemd/system directory and create a service file ( I called mine pixelserv.service). Here is what it looks like.

[Unit]
Description=pixelsirv.pl

[Service]
ExecStart=/usr/bin/pixelserver.pl

[Install]
WantedBy=multi-user.target

Then run systemctl enable pixelserv.service after run systemctl restart pixelserv.service. Now check to see if systemd is running the service.
root@debian-minippc:/etc/systemd/system# systemctl status pixelserv.service
● pixelserv.service - pixelsirv.pl
Loaded: loaded (/etc/systemd/system/pixelserv.service; enabled)
Active: active (running) since Thu 2015-11-19 00:37:26 CST; 7s ago
Main PID: 5345 (pixelserver.pl)
CGroup: /system.slice/pixelserv.service
└─5345 /usr/bin/perl -Tw /usr/bin/pixelserver.pl

UPDATE II:

If you do not turn off dnssec-validation in the /etc/bind/named.conf.options file then forwarding will break. Change the setting to what you see below then restart bind.

dnssec-validation no;

UPDATE III:

If anyone is stuck with provider wifi router that will not let you modify the DNS option in DHCP then you can add this line to the /etc/dhcp/dhclient.conf file.
prepend domain-name-servers server ip address
Then run the command dhclent <interface> to restart dhcp and you should be good.

PowerPC parts exchange?


I have had this idea for a while, but it somehow always went to the back of my mind.  What would you guys think of me adding a parts exchange area to this blog?  I'm asking my fellow authors as well as all the readers.

It would simply be an area on this blog where fellow PowerPC users can give and receive any spare parts they have, especially if they don't really have a use for it themselves.  If we do this, I would like to start it as a pure parts exchange, where the only real money involved is for shipping.  If it goes well then we could even add the ability for people to use it as a sort of PowerPC-specific Craigslist of sorts, but parts are MUCH cheaper to ship compared to systems.

I'm not talking about you all sending spare parts to one place, then making them available to others, as that would be horribly inefficient, but rather a page here to put people that have and/or need parts in touch with each other.  You would then work out your details with each other in private, in your preferred method of communication.  A central parts portal, if you will, for our always shrinking little PowerPC community.

So tell me what you guys think.  I don't want to add this here if no one will really use it.

Since none of the Apple PowerPC parts can be bought new any longer, I think an exchange could really fill a parts void for many.

New SATA PCI card findings


This will be brief...  as there really isn't much to tell, but a more recent finding has changed everything for me.

About three or four years ago, I had come to the conclusion that booting from SATA PCI cards was only about 99.9% stable.  This is because every so often things would just lock up system-wide, and I would be forced to do a hard boot.  Not a good thing when you're smack dab in the middle of important work.  After tolerating it for a couple years...  I finally decided that I would stick to SATA card attached drives for storage only, and boot from IDE/PATA drives instead.

About four or five months ago, I realized that during all those system lockups I had drive sleep enabled.  So I decided to try it for a while without any type of sleep enabled, other than display sleep, which has no effect whatsoever on hard drives.  I never use system sleep, as my systems are always 24/7 on, but I normally use drive and display sleep on every OS.

So I have now been running a WD Caviar Black 2TB as my boot drive for about five months, with drive sleep disabled on every OS, and have never once had an issue.  I have now found 100% reliability with SATA card booting!

The WD Black is the perfect drive to use in a system where drives don't sleep, because it's built for higher endurance than most drives, and has more performance to go along with that.

I had already tried every version of firmware for my FirmTek SATA cards, and nothing solved it, but disabling drive sleep did.  The only real difference now in my computing habbits is that I need to unmount all the externals I'm not using, since they are typically backup drives, and don't go to sleep any longer. 

Keep in mind that these finding are all based off use in two Sawtooth, along with one Gigabit Ethernet system.

Anyway, I had told some readers in the past via comments that SATA card booting wasn't 100% stable, and I just wanted to share how I did find that sweet spot on my hardware.

For the record...  this is all with the FirmTek SeriTek/1S2 PCI controller; I own three.  The Sonnet 2-port PCI is the same card, as they are made for Sonnet by FirmTek.  By the way...  the best firware to use in G4 towers is 5.1.3.  You still need to disable drive sleep, but the newer firmware (5.3.x) is meant for early G5's with standard PCI, and most of these cards ship with the newer version.  So if you have a G4, and you have the 5.3.x firmware, you need to downgrade to 5.1.3 for best results.  You can download the 5.1.3 firmware here.

Please share any SATA PCI controller stories and findings you may have in comments.

G5: (And G4) Nouveau Modesetting Bug and Fix Explained


This is an expansion of the bug report Dan linked to in the previous post here at the PowerPC Liberation blog regarding a specific PPC bug which happened to break nouveau modesetting for PPC Nvidia card users. Much of what I am about to discuss is a already covered in relevant bug report, but I thought I would put it out here with the hope that more individuals would learn about the bug, what it consisted of, the workaround, and how it was fixed.  So with these goals in mind, let us move to the meat of this post.

The Bug

The same Debian user, Peter Saisanas, who reported on the page size and MSI interrupt issue with nouveau on G5 PowerMacs and supplied a working kernel for it, was also the individual who reported on the broken modesetting bug I am discussing in this post. Kernel versions starting after 3.18.16 started to showcase problems attempting to extract the FCODE ROM / DCB block for PPC machines' GPUs through the machine's Open Firmware (OF) device tree.

What are these FCODE ROMs and DCBs?  FCODE ROMs are essentially Open Firmware expansion image ROMs containing bytecode as well as PPC native code that include the necessary graphics device drivers and information for both boot-up and run time. It is one of the ways Apple closely tied the hardware with its software back in the day.

On the other hand, DCB stands for Data Control Block, which is at its very core just a type of data structure that describes the dataset in a program. In the context of our situation, it is just essentially the information about the graphics card's VBIOS and how and where to load it.

This is only part of the story though.  The question was why was it not extracting these two things properly? Turns out that the VBIOS within OF on PowerMacs does not contain a PCIR section (this holds information about the PCI expansion ROM), which the nouveau driver's VBIOS parser now requires by default.  The actual GPU PROM contains a PCIR section, but that is still separate from the OF VBIOS.

So with a PPC system unable to load this data, the kernel has a hard time communicating properly with your graphics card.  Which in turns means the Nvidia card's power and capabilities are not being fully utilized. And as a result of that, the end user ends up still using the nouveau driver, but with completely software rendered graphics.  This can be and usually is quite the disappointment in terms of performance on our old PPC machines.

The Workaround

The work around is quite simple and straightforward fortunately and will likely be the means for several users to at least have the 2D driver working until the patch hits mainline nouveau and works it way down into a later release of nouveau in Debian.  That is unless you want to try and install the patch of which I will discuss later.

Essentially, all that is needed is for you to download the x86 VGA BIOS ROM for your specific Nvidia card and configure (force) your system to load that firmware for your graphics card at boot up.  I will break it down in a few more steps though for the sake of simplicity.

1. Shutdown your system and pull out the graphics card to see exactly what manufacturer and BIOS your card consists of so you know what version you should download.

2.  Browse out to Tech Power Up's VGA BIOS database.  Search for and download the appropriate firmware for your card using the info you obtained earlier from the markings on the card.

3.  Once downloaded, rename it to something simple and related to your Nvidia card version.  For example, I used GeForce_7800_GS.fw for my Nvidia card. 
mv BFG.7800GS.256.051221.rom GeForce_7800_GS.fw

4.  Copy this file to your /lib/firmware/ directory.  You will need root permissions to do this.
sudo mv GeForce_7800_GS.fw /lib/firmware/

5. Add a line similar to below to your desired kernel(s) in your /etc/yaboot.conf file.
append="options nouveau config="NvBIOS=GeForce_7800_GS.fw"

6.  Apply the changes per usual.
sudo ybin -v

6. Reboot and once again enjoy 2D acceleration.


The Fix

Peter Saisanas reported a few days ago that a patch was created via a cloned code repository of the existing nouveau driver that should hopefully eventually hit mainline soon.  I thought it would be sort of interesting to view what changes were made in the commit to resolve the issue.

A direct link to the specific patch can be found here.  From the developer Ilia Mirkin's notes, the patch essentially forces the system to always accept the OF VBIOS.  The only changes made according to the commit were within the priv.h, shadow.c, and shadowof.c files. I thought it would be interesting to look and dissect some of those changes (mostly the ones I can figure out with a quick glance). Follow along with the highlighted changes you see within the link to the patch/commit above and you should be able to see some of what I am talking about.  I was going to post the code, but could not make it format and display in a clean and easily readable fashion as it would just squish everything into one line.

For the header file, two easily noticeable changes are two bool (true or false) variables that were added for the nouveau driver to be aware of whether or not the VBIOS it is parsing contains a PCIR section and another indicating whether the VBIOS checksum should be ignored or not.  A third size variable is declared as well that as we will see later holds the size of the OF VBIOS and image it has read. Pretty straightforward.

As for the edits in the other two files they are a bit more complex, but not much.  In shadow.c, an additional if statement is added to handle the situation where a PCIR section is NOT present. Also, an if statement below that was moved so that it was nested in the else statement in the above if else logic that is there for handling different situations that would result in debugging and error reporting.  After that you can see some additional logic added to an if statement to tell the nouvea driver to ignore invalid checksums.

Last, but not least, there is shadowof.c, which is probably the most difficult in terms of understanding the changes. First, a new header file (core/pci.h) was included. Based on name alone, I have a feeling this header defines the interface through which linux can communicate with the PCI bus and devices on a system. I am not entirely positive about the length calculation addition, but I do know a new of_size function has been created that simply returns the size of the data that has been extracted from OF and set inside of a size variable later on in the code.  Here, the two bools referenced earlier are set to true, which again basically forces the nouveau driver to always accept the image extracted from OF.  The rest is not as straightforward.  It would probably help tremendously to peruse some of the other code within the driver.

According to Peter, he was able to install the patch, but not without some additional edits to shadowof.c.  I have yet to attempt it myself, but will do so here in the next few days and post the required changes needed to install this latest patch.

Hopefully, you, the readers, have read this post and are taking away some new knowledge of nouveau, loading of roms, and reading code, as well as learned some new terms related to your PPC computers.  Once again, it is encouraging that these bugs are receiving attention and being fixed. I still strongly believe we can eventually reach a point where we can have 3D acceleration fully working on our Nvidia cards with the nouveau driver. It just involves us using our voice on the web, filing bug reports, testing the latest and greatest, and learning other ways we can help with and in development.

If you have any questions or additional comments about what I have covered here, I encourage you to drop a comment or email me directly.  Or if I am just flat out wrong about something, tell me as well as I would hate to be spreading false information.

HTTPS is now availible here


Recently, Google added an HTTPS option to all Blogger blogs, and I am of course choosing to enable it here.  So to use this blog with a secure and encrypted connection, you can bookmark this link, or simply add an 's' manually after http in your browsers address bar.


The advantages Google gives for using this new encrypted option:

  • It helps check that your visitors open the correct website and aren’t being redirected to a malicious site.
  • It helps detect if an attacker tries to change any data sent from Blogger to the visitor.
  • It adds security measures that make it harder for other people to listen to your visitors’ conversations, track their activities, or steal their information.


So please...  use this if you feel the need, and enjoy more security and privacy here.  If you link to us, please feel free to add https to the address you link to.

Let me know if you have any issues with it, or any thoughts you want to share on the matter.

Progress on Debian Bugs


Peter Saisanas left an update on Debian's PowerPC mailing list reporting that a patch has been created to fix a bug that broke nouveau modesetting for Nvidia GPU users (bug applies to kernels > 3.18.16).  The patch hasn't been made official yet, but you can view the original bug report here.

Clementine and xfburn had nasty PowerPC bugs, or perhaps just 32-bit bugs, that have now been fixed.  The fixed xfburn is in Testing and the fixed Clementine as of now is in Sid.  So if you haven't gotten Clementine to play files and wanted to enjoy its Spotify, Last.fm, or Soundcloud plugins, now's your chance.

In Iceweasel news, the bookmark folder bug and customization bug are fixed in version 41.0.1 in Experimental.  So now Iceweasel appears back to its normal, healthy self.

Also, there's an r128 patch in this report that I haven't gotten around to testing.  It fixes some breakage in the Stretch version of the driver, so Rage 128 users may want to check it out.

I suppose it wouldn't be a Debian bug reporting party if there weren't some unacknowledged bugs, and on the front I left two kernel bug reports (an appletouch trackpad bug and an Apple Motion Sensor bug).  They haven't even been tagged, though the appletouch bug might have been fixed—I'm having trouble reproducing it.  Possibly related:  the appletouch trackpad driver performs much smoother with the latest kernel update in Sid.

Finally, if anyone wants to test the new pbbuttonsd in Experimental, see if you can duplicate this bug report.  The suggested fix didn't work for me.

And if you want to literally shoot bugs, there's always MacBugs!

G5: Temperatures & Fan Speeds Part I


Hopefully most of you with G5 PowerMacs now have Debian up and running on your system and with little to no hassle. I would now like to take a few posts to cover the temperatures and fan speeds these machines should run at on average and under heavy load while also just covering general items relating to monitoring these items.  This first post will cover just general agenda regarding the temperatures and fan speeds related to your G5.  Follow up posts to this topic will be more in-depth.

The G5's case itself is made of a anodized aluminum alloy that is combined with multiple system fans (most had up to 9!) and designated thermal zones to provide optimum cooling. Another thing to keep in mind regarding the cooling of these systems is that the different models had different means of cooling the system. Most G5 models simply used the traditional CPU heat sink method and built-in fans, such as the ones that you will see residing next to the CPU.  Certain high end models used a liquid cooling system (LCS), which tended to be prone to coolant leaks.  This led Apple to release models with a revised LCS to overcome the issues, but these can be harder to come by and seem to be few and far between. From what I have learned, only the 2.5 GHz Dual Processor (June 2004), 2.7 GHz Dual Processor, and Quad-Core G5 models had the LCS instead of the traditional CPU heat sink.

If you have a system temperature and fan speed utility installed within your OS X/Debian drive or partition, you will quickly learn that these G5 PowerMacs have quite a few hardware sensors built in you can use for monitoring which thrills me for a number of reasons. Temperature and fan RPM information can help you quickly spot current potential issues with certain devices in your system and help you pro-actively address and/or prevent possible issues down the road. Overall, they can help you increase the longevity of your G5 for years to come.  Speaking of system maintenance, I would encourage all G5 owners to check out this post from Cameron Kaiser on the topic.  Very detailed and insightful and I would say it applies in general for owners of other PPC machines as well in many regards.

Let us first review the safe operating ranges in terms of the general temperatures for our G5 PowerMacs as recommended and prescribed by Apple.  Below are links to the technical specifications for each of the 5 generations of G5 PowerMacs released by Apple along with the safe operating temperatures for both storage (not system storage, but storage in terms of its external environment) and the system as a whole.

Original 2003 Series -
  • Operating temperature: 50° to 95° F (10° to 35° C)
  • Storage temperature: -40° to 116° F (-40° to 47° C)

June 2004 Series
  • Operating temperature: 50° to 95° F (10° to 35° C)
  • Storage temperature: -40° to 116° F (-40° to 47° C)

Late 2004 Series -
  • Operating temperature: 50° to 95° F (10° to 35° C)
  • Storage temperature: -40° to 116° F (-40° to 47° C)

Early 2005 Series -  
  • Operating temperature: Not available
  • Storage temperature: Not available

Late 2005 Series -
  • Operating temperature: 50° to 95° F (10° to 35° C)
  • Storage temperature: -40° to 149° F (-40° to 65° C)

As you can see, the safe temperature ranges are quite similar across each generation. Not too much of a surprise there.  If you take a look at each of those documents linked above, you will also notice safe humidity percentage ranges and I would encourage you to review those as well because where you store and run your G5 is also an important consideration to keep in mind. I myself keep my running in the basement where it is generally much cooler but also more damp, so I keep a small dehumidifier running during times of high humidity.

So with these numbers in mind and available for reference, let us discuss the different pieces of software we have at our disposal for monitoring the system's various temperature and fan sensor values under both OS X and Linux.

OS X
  • Hardware Monitor (10.4 or Later) - Only gives temperature readings and still requires payment for full application access.
  • Temperature Monitor - By the same authors as Hardware Monitor. Basically an older version of Hardware Monitor that is a free download.
  • QuickFans - Another utility by the Cameron Kaiser for G5s, but may also work on G3 and G4 machines. However, this utility may or may work correctly though according to his notes, so use at your own risk.
  • iStat Pro - Well known and heavily used widget that is my personal favorite and go to sensor monitoring application.  Lightweight and available at the hit of a few buttons.
  • XRG - Have not personally tried this one, but it looks quite interesting as it also includes GPU monitoring as well. Only available for OS X 10.5 in terms of PPC support.
  •  
Linux (Debian)
  • Conky - A utility many of us are probably familiar with. Incredibly powerful and adaptable. Requires a bit more legwork to start reading available sensors, but it is possible as I have wrote about here.  I would recommend downloading the version available from the official Debian repositories. It does not actually have the native ability to obtain these values but gives you the tools to use other tools to output them. Makes sense right?
  • lm-sensors - I cannot vouch for this either, but supposedly others have been able to make it work with different PPC machines in the past. I am willing to give it a shot myself. Their official site would not load, so I have linked to its Wikipedia page.
  • sensors-applet - According to their page, "Gnome sensors applet is an applet for the gnome panel that displays readings from hardware sensors, including temperatures, fan speeds and voltage readings."  I see it includes support for lm-sensors so should provide similar results. No experience with this one either.

So not a whole lot to choose from, but perhaps that is a good thing? Anyways, my next couple of posts will cover some of my own actual readings using some of the utilities mentioned in this post and how they compared with each other. If you are aware of other utilities and methods at our disposal for obtaining these values, please share as well and I will add them to the lists above.

What would be really sweet was if we could build our own custom utility for Linux for gathering this PPC sensor specific system information across the different models.  Its certainly possible and I would be more than willing to help tackle it.  Let me know your thoughts!

Other than, no update yet on the Nouveau driver situation for G5s, but my hope and willingness to resolve the issues are strong.  I have actually started to write up another post on how to upgrade to Nouveau's latest drivers for testing purposes for when the time to test the fix does (and it will) come.  It is not as straightforward as one would think.

Three years!


We turned 3 today, and more than a lot has happened here since I started this place back on August 11, 2012.

This blog has transitioned from a sole author (me) to currently having five authors in total, and is now transforming into a place where some of the the greatest minds in the PowerPC community are collaborating together.

I have really enjoyed sharing this place with others, and I can never thank all four of the other authors enough.  Those four being Mark (fiftysixk), Dan, Brock (B-rock) and Herminio (rican-linux).  You're all appreciated more than I could ever possibly convey.

Also, lets not forget Dr.Dave.  He was with us for much of 2013, and most of his posts still exist here.  Thanks again, Dave.

A big thanks to all the readers/followers of this blog for sticking around for these three years to read what we have to say.

Here is to another strong three years, and then another three after that, and so on...

G5: Simple Dual Monitor Setup


Since my last post dealt with graphics, I thought I would continue on that same subject although this time the topic should be a little more straightforward.

Before I start though, I would like to provide a quick update for Nvidia card users.  As promised, I poked the Nouveau developers about the 64K page size issue by commenting on the existing bug that was filed a couple of years ago.  I am happy to report that one of the developers has replied stating that he is planning to untangle the vm (virtual memory) mess in the coming weeks where he also plans to address the page size issue for 64-bit PPC machines. You can follow the bug here. Consider this another giant step forward for us G5 owners!  I have offered to help in any way and have recently cloned the appropriate nouveau repositories to start parsing through the code myself and to install the latest version of the drivers for testing. I will keep you all updated.

Okay onto my regularly scheduled content. One of the many fantastic things about using a G5 PowerMac is that most of its supported graphics cards included dual head support of some kind.  If you are one of the lucky to have two monitors to put to use, I would highly recommend it when using your G5 as the extra screen real estate definitely makes a difference.  Not only that, the G5 has more than enough horsepower to drive both displays without eating up hardly any system resources. I myself have a flashed Nvidia FX4500 card with 512 MB of VRAM that includes two DVI heads. Along with that, I have two excellent 20" Apple Cinema Displays to plug into each head.  These monitors support a maximum resolution of 1680x1050 and the results are magnificent.

Now that I at least have a working 2D accelerated desktop, I have managed to successfully get a dual monitor setup going as well as found a way to make the setup persistent across reboots.  As we all know, there are many ways to accomplish a task in Linux and so with that in mind here is the simple setup I have configured to make this work on my G5.

The first thing you will want to do is install the graphical wrapper for xrandr called Arandr:

sudo apt-get install arandr

Once installed, you can find this utility under your Preferences menu.  When opened, you will see square boxes for each of your detected displays as well as their identification names. For example, mine are called DVI-I-1 and DVI-I-2 as can be seen from the screenshot below.  Your output IDs and rectangle sizes will vary depending on video card and monitors in use.


To configure your desired layout, simply drag each monitor to its desired position, which is likely how you have them setup on your desk/stand (i.e. to the left and right of each other, but again, your setup may differ).  Once in place, simply click the green button with the arrow pointing to your right to apply the layout and put it to the test.  Under the hood, this layout is actually a constructed xrandr command that gets called, but more on that in a minute.

If the results are satisfactory, you will want to save the setup by going to Layout -> Save As.  The default directory to save it under is your .screenlayout folder in your home directory.  I would recommend leaving it that location.  The resulting file is actually a shell script, so the file extension should show .sh and if you view the permissions of the file it should be executable.

As mentioned above, the file only really contains the xrandr call that was constructed via your graphical layout you created.  My particular layout ended up as follows:

xrandr --output DVI-I-1 --mode 1680x1050 --pos 1752x0 --rotate normal --output DVI-I-2 --mode 1680x1050 --pos 0x0 --rotate normal

Now that you have a shell script with the saved xrandr command that will create your desired dual monitor layout and configuration, you can apply it at any time by opening the shell script within Arandr and applying it or manually running the script within a terminal.

But wait? Why would you always wanting to be doing this manually?  We have the power of automation at our fingertips.  A good place to have this script run automatically at login is (you probably guessed it) your autostart file.  For me, mine is located at ~/home/.config/lxsession/LXDE/autostart. I added the following line to the file and saved the changes:

/home/br0c0l1/.screenlayout/DualAppleCinemaDisplays.sh &

To test the changes out, simply restart your X display manager. For LXDE users, that can be done by restarting the lightdm service.  Or better yet, just logout and back in.  If all else fails, do a full reboot.

And so from now on, when you login to your G5 Linux install, you should automatically have your dual monitors configured in your desired layout.  Enjoy the extra screen real estate!



If you run into any issues or have other ways of accomplishing this same task, feel free to leave a comment below.