Another Useful Script - Better Brightness

Hello All! I know it hasnt been all that long since I last posted but I have another addition to my useful Linux scripts, randoScripts. Here is the previous post regarding this repo: linky! This script is particularly useful on Debian based laptops. If you have one in your possession I am sure that you have noticed that a fresh boot of the system blasts the screen brightness to the max. This script makes it so the brightness is set to a lower value on boot using the rc.local  script.

rc.local Is a script that by default does nothing and is executed last of all the startup scripts. Our plan is to edit this script to lower the screen brightness.

LETS START!

Step 1

All of my scripts are on Github:

$git clone https://github.com/kd8bny/randoScripts.git

The first thing to do is figure out what brightness value works for you. So in order to accomplish this set your display using your function keys or under Brightness & Lock in your settings menu.

Once you have found the desired setting run this command:

$cat /sys/class/backlight/acpi_video0/brightness

IMPORTANT:

If you finish this tutorial and it didnt work for you, you may need to use

/sys/class/backlight/intel_backlight/brightness

instead. For me both worked just fine, however different values were used.

Anyway, the cat command should spit out a number. The number varies depending on your display. Mine happened to be 34 so I will use that in my examples.

If you would like to practice with values via terminal before settling use this:

$echo VALUE | tee /sys/class/backlight/acpi_video0/brightness

Where VALUE is the number you want to use.

Step 2 

 Go ahead and open up the rc.local file and place the value you want in the location of VALUE_HERE. The script should now look like this:

#!/bin/sh -e

#

# rc.local

#

# This script is executed at the end of each multiuser runlevel.

# Make sure that the script will "exit 0" on success or any other

# value on error.

#

# In order to enable or disable this script just change the execution

# bits.

#

# By default this script does nothing.

sleep 1

echo 34 > /sys/class/backlight/acpi_video0/brightness

exit 0

The sleep is somewhat important in this case by waiting until the OS is completely loaded before changing the values.

Step 3

Next move the script into the proper location if you didn’t edit your own.

$sudo mv rc.local /etc

And to enable it we have to make it executable

$sudo chmod +x /etc/rc.local

Fini!

After a reboot you should now see that your screen will start at your desired value. I am considering editing the script to remember the last screen value. Not sure if its worth it.

Question??

I would really like to keep this repo going with many useful scripts. They show the real power of the Linux OS and your control over it.

Would an automated installer be a nice feature to have? Giving the user choices of scripts they may like to have.
Let me know in the comments.


**The customary for those who care
   Ubuntu 14.04, rc.local

Useful Linux scripts

Hey All! I know I havent been around of recently due to an extremely busy life. However here I am once again with something more useful for everyone! My new item on the table is a collection of Linux scripts (mostly bash) that I use everyday. Some of the collection include trim support, Google Drive, and xbind. So lets start!!!


First!!! All of these scripts can be found on Github. Linky

$git clone https://github.com/kd8bny/randoScripts.git

 FSTRIM

If anyone owns a solid-state drive (SSD) trim support is a basic requirement. The basic issue is that an SSD can write pages of memory but only delete blocks. Blocks of memory consist of many pages. i.e. (page << block) For a much more detailed explanation read here. However as of this moment Linux does not support trim automatically, but it is easily added to cron tasks. In case you are a Linux n00b cron tasks are located the system and are executed on a regular basis.
Your choices of cron are:

• Hourly
• Daily
• Weekly

The script will execute whenever the system is free and calls cron. Now for fstrim I personally call this weekly, monthly might even be a better option. As soon as trim is run your files are permanently removed, this means you will NOT be able to recover anything that has been trimed. All that is required of the user is to copy the script into the correct cron folder.

$sudo cp trim /etc/cron.weekly/

BOOM! complete :) If you would like proof that is executes a log is created:

$cat /var/log/fstrim.log

 IMPORTANT!!!: Read README.md if you are using an LVM partition under EXT4.

Google Drive (grive)

As a Linux user you may know that Google has failed to provide a native drive client for us. This means you cant keep files synchronized on your drive and computer without doing so manually. Fortunately the group at The Fan Club saw the issue and provided us with grive. Grive is a 3rd party sync tool specifically for Linux. Despite how awesome this application is, it is missing an automatic synchronize. For this very reason I decided to create a cron bash script to take care of that, hence syncGrive. This script is capable of handling multiple accounts as long as they are under a single directory.


This script uses the power of the grive application by The Fan Club. To add it:

$sudo apt-add-repository http://www.thefanclub.co.za/how-to/ubuntu-google-drive-client-grive-and-grive-tools

$sudo apt-get update && sudo apt-get install grive

After the application is installed copy my srcipt to cron.

$sudo cp trim /etc/cron.hourly/

I personally run this hourly do to my extreme use of Google Drive, but choose what works for you the best. 

 IMPORTANT!!!:

1. The script assumes the directory is "~/grive"
1. If not change the directory in line 3
2. By default grive does not delete removed files from the directory, however the script does. (README.md)
1. To remove this comment: line 9:: rm -r .trash >> $LOG 

BOOM! complete AGAIN! :) If you would like proof that is executes a log is created:

$cat /var/log/syncGrive.log

xbindkeys

xbindkeys is a part of xautomation that allows you to re-purpose  extra buttons on your mouse or keyboard in Linux. I see no real reason to cover this again in this exact same blog. Here is the link to the previous write-up. Linky

pi2go Updates

So it really has been awhile since I last posted, this has seriously been a busy year. However I feel like starting strong again and posting a few new features I put in pi2go. I am really liking how the project is turning out. New features keep coming to me and I lack the time to program them. If your're unfamiliar with the project check this out: http://kd8bny.blogspot.com/2013/06/pi2go-is-working-100.html

Anyway here is what's new:

OBDII Rewritten!

If you were wondering "didn't he rewrite this already?" You would be correct, however a good friend of mine (c0nrad) pointed out a better way to write this code. A little background knowledge of QT points that it is a system based on events. In laymans terms:

     Event1 happens -> Event2 happens -> QT process events -> Event3 happens

Only Event1 and Event2 are processed. Event3 doesn't process until QT once again processes its events. This enacted by a process of signals and slots within QT.

So how does the code work?

    def ODBII(self):
        """Starts to read the ODB data"""
        self.stopOBD = not self.stopOBD
        while not self.stopOBD:
            self.ui.obdButton.setText("Stop")
            OBDvalues = pi2OBD.pi2OBD().OBDread() 
            self.OBDsignal.emit(OBDvalues)
            PyQt4.QtCore.QCoreApplication.processEvents()
            
        self.ui.obdButton.setText("Start")
        self.OBDsignal.emit(OBDvalues)

        return
The first important line is the use of emit(). Emit does exactly what you would think, it sends the signal "OBDsignal" with the values of OBDvalues. The signal is classified in earlier within the class

OBDsignal = QtCore.pyqtSignal([list], name='OBDsignal')

self.OBDsignal.connect(self.updateGUI)

The connect statement is extremely important in this case. It tells QT if the signal "OBDsignal" is emitted it will run the function "updateGUI." This function does exactly that and updates the LCD values on the GUI.

Back to the original code snippet. After the signal is emitted the function "updateGUI" runs. Then QT processes the events in the very next line. The main downfall with forcing QT to process events is that the UI doesn't respond on user response but rather when the program processes manually.

So I lured you here with promises of new features......well here is the main new one:

Maintenance Logs!

Now I'm really happy with this feature, I think it will be incredibly useful to every user. The idea is you have the ability to log all your standard maintenance tasks into one single log. This way you will never forget when you last did an oil change. 

This feature also directly writes to an excel file to be read at any time. Ideas to come include pulling the last update directly to the GUI and the ability to search for specific tasks within the log.

Also! I think I forgot to mention that I finally added the clock thanks to the QWT library in python. I will write on that once I use it a little more.

Well I think thats all the updates for this session. Too many projects but I would like to keep this one going. 

If you would like to follow, please do: https://github.com/kd8bny/pi2go

As always

**For those that care written in Python2.7 utilizing pyQt4 over pySerial. Issue tracker

Become a key binding pro using xbindkeys

Hey all this time around Im going to show you how to set up key bindings using xbindkeys. I found the need for this after picking up a new mouse for my desktop, Logitech MX pro. I gotta say this is one beautiful mouse; darkfield laser, frictionless scrolling, too much. However it came with a few extra buttons not supported by default in Ubuntu, so of course I had to fix it. Now the following process should work on any Debian based system and any system using the xautomation package. So...... lets get started

STEP 1: Install all the packages
     Complete this using your favorite package manager. I will use aptitude in my examples.

 $ sudo apt-get install xbindkeys xautomation

STEP 2: Setup the default xbindings
    To make the necessary config file enter the command below.

$ xbindkeys --defaults > $HOME/.xbindkeysrc  

STEP 3: Find your keys
    This step works for not only a mouse, but also any key combo on your  keyboard.

    Lets run the event catcher. You can use either xev or xbindkey command. Use the -k option to catch a single event. Use the -mk option to collect multiple.

    $ xbindkey -k

If completed correctly the terminal will display something like:

"(Scheme function)"
    m:0x10 + c:248
    Mod2 + NoSymbol

This is a random button on my laptop which has no function..... till now :P

STEP 4.1: Lets edit  the config file
Use your favorite editor, I will show gedit in this example.

 $ sudo gedit .xbindkeysrc

I highly recommend removing all of the default emulations from the file. Otherwise some of your favorite shortcuts will be remapped. (About line 34 and above.) If not you can always fix it later.

Now just copy and paste your event from earlier into the file. Now, the line that reads "(Scheme function)" is the command to be run. In this example I would like it to open my calculator, being its location on the num pad.

"gnome-calculator"
    m:0x10 + c:248
    Mod2 + NoSymbol

This works a little differently when working when emulating keyboard shortcuts. Keep reading.

STEP 4.2: If you want to emulate a keyboard shortcut, i.e. use one button to "press" multiple, we need to use the xautomation package from earlier. In my example I use the thumb button on my mouse to open the unity dash and to open the window spread. The shortcuts are Super and Super+w respectively. To emulate keyboard commands we use the command "xte". Here is my command for the dash:

"xte 'key Super_L'"
b:13 + release

Use the "key" descriptor when there are no subsequent button presses. This command claims the the left super key. You could also use "Super_R" which is the right key. The "b:13" refers to the physical button of the mouse. Finally the "+ release" is very important. This assures that your finger has released the button before executing the command.

The next example is to open the window spread. This is very similar to the previous example. The main difference here is the use of the "key*" command. These descriptors assure that the middle button is pressed before the Super key is depressed.

"xte 'keydown Super_L' 'key w' 'keyup Super_L'"
b:10 + release

Just for reference here is what my file looks like.

 # For the benefit of emacs users: -*- shell-script -*-
###########################
# xbindkeys configuration #
###########################
#
# Version: 1.8.5
#
# If you edit this file, do not forget to uncomment any lines
# that you change.
# The pound(#) symbol may be used anywhere for comments.
#
# To specify a key, you can use 'xbindkeys --key' or
# 'xbindkeys --multikey' and put one of the two lines in this file.
#
# The format of a command line is:
#    "command to start"
#       associated key
#
#
# A list of keys is in /usr/include/X11/keysym.h and in
# /usr/include/X11/keysymdef.h
# The XK_ is not needed.
#
# List of modifier:
#   Release, Control, Shift, Mod1 (Alt), Mod2 (NumLock),
#   Mod3 (CapsLock), Mod4, Mod5 (Scroll).
#
# The release modifier is not a standard X modifier, but you can
# use it if you want to catch release events instead of press events

# By defaults, xbindkeys does not pay attention with the modifiers
# NumLock, CapsLock and ScrollLock.
# Uncomment the lines above if you want to pay attention to them.
#################################################################

#Thumb Button
"xte 'keydown Super_L' 'key w' 'keyup Super_L'"
b:10 + release

#Zoom Button
"xte 'key Super_L'"
b:13 + release

#Calculator
"gnome-calculator"
    m:0x10 + c:248
    Mod2 + NoSymbol

##################################
# End of xbindkeys configuration #
##################################

I hoped I was able to help! Have fun modding!

**The customary for those who care
   Ubuntu 13.10 saucy salamander, xbindkey

GPS opinions in pi2go??

Hey all, I've decided to embrace Thanksgiving break and have been cranking away at pi2go. So far I have added some better functionality as far as threading goes and started working on adding GPS functionality.

My question to you.......What are some good features to add in a GPS tab?

Here is a basic layout I have so far:

What should I add? What should I take away?

So far I am thinking of:
- Logging data (I have a cool idea :) )
- Direction changes
- Raw stats (latitude, longitude, altitude, etc)

Thanks!!!!

If you are curious on the project, here are some links.
- pi2go
- github
- Not to mention other posts 

**For those that care written in Python2.7 utilizing pyQt4 all for the Raspberry Pi

Alt GCC android build

Have you ever had the thought of "Hey GCC has some room for improvement in my android kernel build?" Well of course you did, even if you didnt know it. One of the most well known GCC tool chains is Linaro. This tool chain includes many optimizations over GCC. Needless to say I wont bother you with too many details. Lets just say that a built kernel with an alt GCC tool chain gives android many performance improvements.

Now to the fun part. How does one do such a thing? For my builds I use the SABERMOD toolchain. It includes much of Linaro with a few more optimizations. Linky's below:

Linaro 4.8 and SABERMOD 4.9

Now within your ROM's working directory

$ cd <working dir>/prebuilts/gcc/linux-x86/arm

Unpack whichever tool chain you would like to use.

Next!

$ sudo gedit build/envsetup.sh
  
Look for the following line (line 155)

 # The gcc toolchain does not exists for windows/cygwin. In this case, do not reference it.

    export ANDROID_EABI_TOOLCHAIN=

    local ARCH=$(get_build_var TARGET_ARCH)

    case $ARCH in

        x86) toolchaindir=x86/i686-linux-android-$targetgccversion/bin

            ;;

        arm) toolchaindir=arm/arm-linux-androideabi-$targetgccversion/bin

            ;;

        mips) toolchaindir=mips/mipsel-linux-android-$targetgccversion/bin

            ;;

        *)

            echo "Can't find toolchain for unknown architecture: $ARCH"

            toolchaindir=xxxxxxxxx

            ;;

    esac

This is the directory to your tool chain change it to your new tool chain location. For example my line 155 reads

 arm) toolchaindir=arm/sabermod-4.9/bin

because that is the name of my directory in "prebuilts/" .

After making those changes you you are ready to build the android. Continue with lunch or a build script if provided.

Good Luck!!

**As always for those who care
   Ubuntu 13.10, PAC-rom 4.3, SABERMOD4.9

 

I'm not dead!!

This is just to let you also know I am not dead. Rather merely running out of free time. So here is a list of things Ive been up to and will write about in the near future.

- Analog to digital Conversions
- Pulse Width Modulation
- Assembly Language
- Verlilog Language
- Gate Logic
- Opamps (probably soon due to an exam)
- LaTex ( Soon because it is soooooo helpful for technical writing)
- Some secret stuuf I cant mention until it is published.
- Building custom Android ROM's

and

- pi2go is getting some cool GPS tracking and touchscreen features

Until then, if you want to hear about any of these topics let me know!