Sunday, December 8, 2013

Some Debian tricks

Now that I'm back using Debian, I'm finding there are new tricks I've needed to learn since the way repositories are run have changed.

Adding an Ubuntu PPA to sources.list


Often a current package binary exists for Ubuntu via PPA, but not for Debian.  The quick fix is to just add the PPA as a source to your /etc/apt/sources.list :

Go to https://launchpad.net/ubuntu/+ppas‎ and search for the package you are interested in.

Once on the package page click on the "Technical details about this PPA" link and choose the Ubuntu version that best corresponds to the Debian release you are using.  Change this if you see dependency problems.

Add the resulting lines to your sources.list file.  Then in a terminal:

sudo apt-get update

You will see an error that says something like "public key is not available: NO_PUBKEY  [TheKey-NumbersAndLetters]".  

Adding a new public key

To add the key type the following:

sudo gpg --keyserver pgpkeys.mit.edu --recv-key [TheKey-NumbersAndLetters]
sudo gpg -a --export [TheKey-NumbersAndLetters] | sudo apt-key add -

Then try to update again

sudo apt-get update

Now you should be able to install the package via apt-get or your package manager.

Enabling Debian Sponsored packages:


Search for the package at http://mentors.debian.net/packages/index

if it exists, add the following line to your /etc/apt/sources.list

deb-src http://mentors.debian.net/debian unstable main contrib non-free

then at a command line

sudo apt-get update
sudo apt-get build-dep [packageName]
sudo apt-get source -b [packagName]
sudo dpkg -i *.deb

If you gt any errors at the build-dep step, just install those dependencies.


Auto-installing reccomended dependancies:

apt install packagename --install-recommends






Sunday, November 24, 2013

log of Semplice modifications

I've done a ton of configuration since installing Semplice Openbox and it's getting hard to keep track of everything I've done, so I'm going to try to keep track in this post:

installed apps:

  • p7zip-rar - 
    • rar 3.0 files won't open var unrar
    • usage: 7z x
  • ice-weasel
    • chrome crashes a lot for me so I don't trust chromium
  • yate
    • great app to make and take phone calls from Google voice
  • light-lock
    • xscreensaver is hideous and the dev doesn't want it fixed.
    • uses the same screen for unlock as lightdm
  • geany
    • a decent programming text editor
  • simple-scan
    • best easy to use scanning software
  • guake
    • dropdown terminal  (might delete if I like tilda better)
  • tilda
    • dropdown terminal
  • Cairo-dock
    • a lightweight dock I like better than docky
  • ARandR
    • Multi-monitor location configuration

Uninstalled:
  • Openbox-metapackage
    • result of removing xscreensaver


Modified Config files and Scripts:

  • ~/.config/openbox/autostart
    • touch pad delay while typing:
      • syndaemon -K -i 0.5 -R -d  &
    • added yate, tilda, and cariro-dock
  • ~/.config/tint2/tint2rc
  • ~/.conkyrc
  • /usr/share/X11/xorg.conf.d/50-synaptics.conf
  • /etc/lightdm/lightdm-gtk-greeter.conf
    • I am not a fan of Semplices default background; choose something less abrasive.
    • Set it to /usr/share/backgrounds/default.png so that updating which picture is default.png updates both login and desktop at the same time


Monday, November 11, 2013

Video Card Bench-marking (Debian / Mint / Ubuntu / Arch / Manjaro)

Now that one of my rigs kicked it I have a fair amount of spare equipment kicking around that I need to benchmark against what I currently have installed in some old rigs.  Moreover, I fear that on some systems, the built-in motherboard graphics might actually be faster than the AGP cards I have installed because I only installed them to have S-video out or video capture. 

I've been trying do document all my cards with my cell camera, but I quickly forget which one is ins which machine,  so the executing the following at the command line  will print out relevant rendering info:

glxinfo | grep render

Unfortunately, the above command only work for kernels 3.6 or newer and Arch uses 3.4 so if you haven't upgraded your kernel, you'll need to dig through the results of the following:

lspci 
Next, many distros (especially Debian based ones) come with glxgears installed which can give you a rough measure of preform-ace in fps, but it may be tied to monitor settings, so it's just a good first quick test:

glxgears

In theory these are better bench mark packages, glmark2 glmark2-es2 chromium-bsu, gltron. But glmark packages had canvas errors, and the last two packages are games that don't automatically spit out the fps.  Moreover, I had a lot of installation / execution issues across platforms with these, so no promises here.

Specific Issues:
GeForce FX 5200: Installing NVidia propriety driver 96 and 173 and 310 under Bodhi Linux failed
  • resolution to drop to an unusable size
  • xorg.conf is deprecated and thus install guides to edit it aren't helpful
  • removing the driver and any xorg.conf and reinstalling nvidia-common restores graphics
  • 310 shouldn't work, but jockey recommends it after 173 has been installed.

Quadro2 Pro: There are conflicting reports of which driver works for this card; I've seen NVidias readmens say 173, 96, and 73.  I've yet to try 73.



Thursday, October 3, 2013

Google drive for linux - Pros and Cons of Insync

Background:

I've been hopeful about Insync for years, but until about a 9 months ago it wasn't ready for everyday use.

I'd been a beta tester since at least 2011 as I really wanted to get my company off of our Dropbox subscription and move to Google cloud storage as there were always collisions between files that were being collaboratively worked on and shared in Dropbox, and SVN was too complicated for my CEO.

Beta experience:

Versions prior to 0.08 were really unstable, and Google's revision control would often make a mess out of things.  0.08 cleaned up most of this and by version 0.09 it was rock solid! and I was syncing 3 Google accounts (work, household, and personal).  When I got the warning that I'd have to pay, but that I'd actually have to re-download everything to up grade I knew I wanted to opt out until that wasn't the case (I was syncing over 7 GB of files across 3 computers).   I figured my next employer could pick up the tab of purchasing the version 1 client on the machine they'd assign me, and I'd try it then, and if it was way better or the 0.09 client messed up to the point where I needed to re-download everything anyway I'd upgrade.   Moreover they claimed the version 1.2 client was slated to allow an upgrade with out a full download.

Unfortunately, around this time Insync was added to the Ubuntu repositories, and during a routine software updates I was upgraded to the version 0.10 beta client that had a 15 day limit before a pro account was needed.  Worse yet, it was missing some core dependencies and was not functioning.  And when I tried to downgrade things just got so messed.  I posted in the insync forms and they, of course, recommended the new paid 1.0 client.  Moreover I couldn't even find the 0.09 beta client packages to try a reinstall on my own.  I was a bit upset about how I was forced into an upgrade, but as I was working on resumes couldn't afford to waist any more time trouble shooting and finally bought a license for one of my accounts.

That said, I've utilized support a few more times since the upgrade, so I can't help but feel like paying for a license was the right move.

Moreover, support is supper responsive, and other than getting screwed by the Ubuntu repo maintainer, I have no other complaints.

The new client:

Thew new client is rock solid and integrates well Ubuntu based distributions.  I like the mate client.  The arch client still needs some work.  In Openbox if you leave notifications on they tend to take over your screen (are way to large).  Also the documentation for installing Insync required aggregating a bit information first (I'm new to arch and don't fully grasp AUR yet).  Yes, there is still an occasional bug, but an upgrade to the latest client no longer requires a full re-download of your file system and usually fixes most problems.

See my post here for how to install insync in Arch.

For debian systems, just use apt-get or synaptic.



Wednesday, September 18, 2013

Touch pad deactivation while typing and palm detection


I was having the same issue with my ASUS K55A touch-pad has the same issue whether under Arch Linux, or Ubuntu, and I imagine this applies to a lot of other touch-pads out there.  I'm running Openbox in Arch and Semplice (Debian Sid)  Mate in Ubuntu, but this should work for enlightenment, Gnome or any other desktop you might use. 

Set up palm detection:

Turn on palm detection, in a terminal type:
$ synclient PalmDetect=1

Set the maximum width that should be interpreted as a finger instead of a palm.  I choose 4, most how-tos use 10, it's good to do a bit of guess and test here:
$ synclient PalmMinWidth=4
 
Then, set the minimum height of a palm vs a finger:
$ synclient PalmMinZ=50 

Finally, under Ubuntu, 3 finger middle click is not enabled by default, so if you want to enable it use:
$ synclient TapButton2=3 TapButton3=2

In theory, this should enable 2 finger tap for middle click, and 3 finger tap for right click, but in Ubuntu 13.04 the resulting behavior is exactly the opposite.  Therefore, if you prefer 2 finger tap for middle click use:
$ synclient TapButton2=2 TapButton3=3 

To make this permanent once you have found the correct settings, save them into 50-synaptics.conf which is located at /usr/share/X11/xorg.conf.d/50-synaptics.confin  Debian/Ubuntu (Semplice) and at /etc/X11/xorg.conf.d/50-synaptics.conf in Arch Linux based distros, (the first "InputClass" part is for the multi-touch middle click fix, which is already enabled in Arch so you shouldn't need to add it):

Section "InputClass"
    Identifier "touchpad catchall"
    Driver "synaptics"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Option "TapButton1" "1"
    Option "TapButton2" "2"
    Option "TapButton3" "3"
    Option "HorizTwoFingerScroll" "on"
    Option "VertTwoFingerScroll" "on"
EndSection


#synclient PalmDetect=1
Option "PalmDetect" "1"
#synclient PalmMinWidth=4
Option "PalmMinWidth" "4"
#synclient PalmMinZ=50
Option "PalmMinZ" "50"

Actually turning the touch-pad off:

While this solution is almost perfect.  It still really annoyed me that there wasn't a software delay of say a 0.5 second between when the last key-press was registered and when the touch-pad is active.  The Arch linux wiki on touch-pads gives some hints here as well, however, getting it to work was as straight forward as above.  Moreover, when I attempted to run the recommended script, multi-touch gestures were disabled for the remainder of my login session, or in other instances the touch-pad just stopped working all together.

As it turns out, if I run the script before executing the palm detection script then it actually seems to work.  However the script on the arch wiki it's not an ideal example.  A friend of a friend recommended the following instead, and after reading the syndaemon man file I'd have to agree:

$ syndaemon -K -i 0.5 -R -d 

The arch wiki claims that if you save this command to your  ~/.xinitrc file to have it executed automatically at your next log-in.  However when I did this I was unaware that the command must happen before the launch of the desktop (exec DESKTOP.session command).  After playing around with a ton of other config files and learning a ton about the SLiM display manager I finally realized that the command just needed to be moved further up the file as commands after the desktop launch wont be run until the desktop is quit.

I hate touchpads; jummpy zig-zaging pointer/cursor, and disabling the touch pad while typing

I hate touch-pads.  Yes, they have gotten better, especially with muti-touch functionality.  However I really love the GNU/linux middle click to paste highlighted text, and three finger middle click lacks the accuracy one really wants to place a line of text in a specific spot.  The dislike of touch-pads seems to be genetic, father once made his company replace his touch-pad with a trackball (it was modular so it could easily be swapped out), but I digress.

Currently I'm experience 2 different touchpad issues on my ASUS K55A under Ubuntu with Mate and Manjaro / Arch linux with Openbox that seem generic enough to not make a specific blog for my laptop.

Issue 1: Jerky mouse pointer behavior
The first is a really crazy issue where I when to visit the girlfriends family and suddenly my touch-pad was going haywire.  Turns out my the house I as in had lower quality power (probably due to their heavy use of CFL bulbs) and my power adapter was generating EM interference with the touch-pad because of it.  Many forums claim this is due to a faulty power supply, and Dell, Apple, and HP have replaced their afflicted user's adapters.

-- Follow-up: after much testing it's definitely due to power quality issues.  Non-OEM charges continuously replicate this experience.

Issue 2:  Touch pad active while typing, causing accidental clicks and focus changes
This section turned out to be longer than I expected, and I'm still updating it, so it has been moved to a separate post:
http://add4jhf.blogspot.com/2013/09/touch-pad-deactivation-while-typing-and.html