Friday, December 19, 2014

Am I Getting Hot or Cold?

Yes. A post on monitoring your PowerBook's temperatures when running Debian or similar variations of Linux. As mentioned in a previous post, I am a big fan of Conky, which I utilize to show me several pieces of information regarding my PB and other PowerPC systems at any given time. Conky shows me such things as CPU, battery, and memory usage, as well as the capacities of each plus disk space usage across all partitions, up and down network statistics on all interfaces, and top process CPU consumers. I should note that right now, when completely idle with no GUI applications running, Conky states CPU is at 1%, which I see as very ideal. Usually it's Conky taking up a majority of that 1% of CPU.

The only thing I was missing was a way to monitor temperatures that are reported by the machine's included sensors. PowerPC portables have a history of running quite warm. Obtaining this same information in OS X is incredibly easy using a dashboard widget such as iStat Pro. Still being incredibly new to many things Linux and even PowerPC, I had to start doing a little bit of research to see if or where this information could be stored for retrieval. After perusing the different Conky options, I came to the conclusion that the desired information could not be natively retrieved using any existing Conky options as most deal with the (ugh) Intel architecture.  If I'm wrong, please let me know either through the comments belows or via email if you don't feel like publicly shaming me.

One way to start was to run the lsmod command, which would provide me with a list of loaded kernel modules.  One of those sure had to be doing something temperature/fan related?  Well, a few stuck out at me including, ic2-powermac, although it was not being used by anything, but I ran into this module when doing some research online.  The other one in particular was therm_adt746x, but again was not being used by any drivers. I'll be doing some more reading of these modules in the near future.

Luckily, I also discovered a couple of the sensors and output I could retrieve from various files under the /sys/devices/temperatures folder. I simply did a search of the file system using locate temperature. There were only two sensors listed along with a few other configuration files that I have yet to investigate any further.

For each sensor, there were 3 relevant text files (actually 4 for sensor1): sensor[#]_limit, sensor[#]_location, and sensor[#]_temperature. Sensor 1 also included a sensor[#]_fan_speed file. I ran cat on each of the 3 files (again 4 for sensor1), just to obtain some sort of idea of what information it would provide. Here is a quick overview:

  •     fan_speed – provides the current speed of the fans in RPMs
  •     limit – specifies the upper limit of the temperature that the sensor can reach before I assume either you start to have issues or the fans kick in
  •     location - specifies the location that the sensor is monitoring the temperature for
  •     temperature – this file provides a single number, which happens to the latest temperature reading in degrees Celsius (converting this to Fahrenheit should be trivial)
According to the locations, one sensor was for the CPU_BOTTOMSIDE and the other PWR_SUPPLY_BOTTOMSIDE. My understanding (again please correct me if I am wrong) is there should be other additional sensors on the PowerBook that we could pull values from. If there are, I'd love to figure out how to do just that. For example, on the OS X side, when looking at temperatures in iStat Pro, it also provides temperature values for CPU top, battery, trackpad, and HD. Perhaps there is some additional documentation somewhere covering this sort of information?

Great, so how can I customize Conky to pull in these values and output them to the grid of information I have running on my desktop? Well, one of the first ideas that came to mind was using a shell script that essentially grabs the temperatures and fan RPM values from the corresponding files and assigns each to a variable that can then be output by Conky. Perhaps there is an easier way to do this?

Yes there is. Here is where exec object comes in handy. This particular object will let you specify a shell command you'd like to run and output.  If you want to have the command ran at your own set intervals, use the execi command instead, but be aware that the interval value you set must be lower than your configured update_interval (mine is set to 1.0 second) for Conky.  So for each sensor I added the following line:

Bottom CPU Temperature: ${exec cat /sys/devices/temperatures/sensor1_temperature}

Battery Temperature: ${exec cat /sys/devices/temperatures/sensor2_temperature} 

According to the man pages for Conky, running shell commands within Conky tends to be more resource intensive.  Personally, I have seen a small average of about a 1% increase in CPU consumption, but that could be to other configuration changes I've made recently to the PB.  These two additional lines in my Conky configuration file worked and do as they are intended, so in some ways a success.  Here's a screenshot:


One last thing I would like to share about Conky.  If you want to disable any sort of flickering Conky may be experiencing, add double_buffer yes to your list of options. Makes everything look like it is running much smoother. I was going to post a link to my conky.conf file somewhere, but decided if somebody was interested in taking a look at it, I send it to them via email.

I know I've barely scratched the surface on how all of these sensors work, but it's a start. One thing I haven't quite figured out is how often the temperatures are being updated in those specific files, so the quest for answers and understanding continue!

Hopefully you enjoyed this post and can use it as a starting pointing for doing your own temperature/fan speed monitoring on your PowerPC machine(s) or even as a gateway to other great ideas for information that can be displayed by Conky. 

I still have yet to finish the post on my PowerBook 1400CS (waiting on a few more parts) as well as the introduction to Clang on PowerPC. The latter is a post I am taking extra care to refine before I put it out there in the wild.

Sunday, December 7, 2014

Don't Push My PBButtons

So I wanted to cover something I ran into when first installing and configuring my Debian distro that almost drove me over the edge.  Now as you read on and discover the former source of my misery, you may laugh at its minuteness, but I'm quite particular about configurations and making sure things work exactly as I wanted them to, which as you can probably guess is never easy as you'd like it to be.  However, they (who are they?) say Linux is all about being able to customize everything to your liking. 

The problem was with configuring the G4 PB's eject key to work as you'd eject, I mean expect.  That is, upon pressing the eject button, it would eject any CD or DVD you currently had inserted into your system if any.  Just as if I was still using good ole Mac OS X.  Sounded like a piece of cake.  Every other key on the keyboard did exactly what it said it would do including the volume up, volume down, and brightness keys.  However, whenever a disc was inserted, I had to revert to using the probably better known eject command line tool, which is simple enough, but I'd still like to have the key working as well.

Still being in the infancy of my foray into using Linux (and Linux on PowerPC), I started to research how certain keys were mapped in Debian and other Linux variations on PPC hardware.  I quickly learned certain specific key mappings worked through what software is known as pbbuttons. This runs as a background daemon and can be restarted with the usual restart methods at your disposal. It has a configuration file stored in the /etc directory. Full path is /etc/pbbuttonsd.conf.  Being in the /etc directly, the file will require root/sudo privileges to edit.

The configuration file has a number of customizable options that are way beyond the scope of this post, but as always, I encourage you to peruse the file and make adjustments where you see fit.  It includes such settings as the default values for the brightness values at login/startup, different configurations for when on battery power, and default values for sound and volume.

Anyways, the specific section we were looking for was the [MODULE CDROM] that allowed you to customize which keyboard key to act as the eject key, the delay when pressing that key and which CD/DVD device it was to work with. Right away, I learned from the config file that eject was mapped to the key 161.  Okay, that's nice, but what actual key on the PowerBook's keyboard does that actually map to exactly?  So... more research, which taught me another handy command line utility (honestly, what command line tool isn't?) called xev. Pretty straightforward tool. Just type xev and it will open a new window that intercepts events such as moving a window, resizing a window, or clicking on something, and spits out information regarding that particular event. For example, you can punch any one key on the keyboard and it will print out a number of pieces of information regarding that key.  When I hit the escape key, the utility printed back the following information.

KeyRelease event, serial 46, synthetic NO, window 0x2800001,
    root 0x121, subw 0x0, time 2053168, (639,-2), root:(840,578),
    state 0x10, keycode 169 (keysym 0x1008ff2c, XF86Eject), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False


I changed the keycode value accordingly, but sadly, no go. Long story short, the keycode returned by the utility is not correct and the 161 was actually the value for the eject key as was originally hoped.  So why was it still not working?

Well the only other configuration option that could be the issue was the CD/DVD device it was mapped to. I double checked and it was pointed to /dev/cdrom.  Sounds correct, but I decided to change directories over to the /dev directory to make sure such a device did in fact exist. I ran my alias command for 'ls -alh' to list out the contents of the directory as well display ownership and permissions among other things.
lrwxrwxrwx   1 root root           3 Dec  7 14:15 cdrom -> sr0

Almost right away I noticed in the permissions that the advanced permissions flag (first character in the list of permissions) was set to l, which indicates it is a symbolic link.  So moving my eyeballs further to right, the listing indicated that cdrom was a symbolic link to /dev/sr0.  I immediately updated the conf file to use the actual sr0 device instead of the symbolic link.  I saved the changes and restarted pbbuttonsd.  And what do you know, the key finally worked! Victory!

Here is the full posting of the CD module section if you are interested.
# [MODULE CDROM]
dev_CDROM             = "/dev/sr0"
EjectCDKey            = 161
EjectCDKeyDelay       = 0


In short, you need to map the CD/DVD drive to the actual /dev/[device name] as symbolic links will NOT work. I thought I would share this little tidbit of information in hopes that it helps somebody else someday.  I'll wrap it up here though and continue working on a few other posts I am putting together, including my work on my PowerBook 1400CS, installation of Debian Jessie on a G4 Quicksilver and working with the Clang compiler on PowerPC architecture.  Comments are welcomed!