If eth0 has an external network connection and you want to NAT your eth1 connection, you can use the following commands (as root):
echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
You can use the -modulate option to change the hue of an icon, but it does not, for some unknown reason, preserve the icons alpha channel. So here is the command line option to change the hue of an icon while preserving the alpha channel:
convert icon.png -modulate 100,100,50 -alpha off icon.png -compose CopyOpacity -composite PNG32:output.png
The last option to the modulate option changes the hue. Change it from 50 to whatever you want to get the hue you want. A value of 100 will leave the hue unchanged.
From the image magick documentation:
The hue argument causes a “rotation” of the colors within the image by the amount specified. For example, 50 results in a counter-clockwise rotation of 90, mapping red shades to purple, and so on. A value of either 0 or 200 results in a complete 180 degree rotation of the image. Using a value of 300 is a 360 degree rotation resulting in no change to the original image
I have been wishing for Garmin to support Linux with their Communicator Plugin for quite some time. In fact, I have even considered writing the firefox plugin to enable Linux support several times, but just haven’t been able to find the time to do it, plus maintain it, etc. So I have been using Garmin Connect in a virtual windows machine. It has been painful, but the other options were even less appealing to me.
Yesterday, however, while looking into adding Garmin Communicator support into Routometer, I did yet another Google search to see if someone else had written a Linux plugin, and what do you know, but YES. Check it out at Linux Garmin Communicator Plugin.
I tested it out. Fortunately it supports my watch, the Forerunner 305. I downloaded the RPMS and they installed without issue. I went to about:plugins with Firefox, and sure enough it was there. I went to Garmin Connect and the first message it gave was browser not supported. I restarted Firefox, and that error went away. The next problem, however, was that it said no devices were detected. I had long ago added ‘garmin_gps’ to my modprobe blacklist, and looking at the RPMS it seems to create an blacklist conf file for you. I was not sure the problem, so I looked into Garmin Tools command line programs to see if I could figure it out. Running ‘garmin_get_info’ returned nothing. So I unplugged and replugged in my Garmin Forerunner 305. Running ‘garmin_get_info’ this time produced a screen full of information. I returned to Garmin Connect and this time it detected my device. I clicked to upload new activities. The watch beeped a couple times and then the progress bar on Garmin Connect froze. So I returned to the command line and tried the ‘garmin_save_runs’ command. That downloaded everything just fine. So I reloaded Garmin Connect and tried uploading again. This time it made it through. I did not have any new runs on my watch, however, so it wasn’t a complete test.
I decided to go on a run just to test it out. I went on a short 4 mile loop. Upon returning I plugged it in and tried uploading. Everything seemed to work. It found the one new run and appeared to upload it. When I clicked the “Activities” link, however, to view it, it wasn’t there. Maybe I didn’t let it finish uploading. In retrospect I can’t be sure what I did, but the run was not there. So I tried uploading again. This time, however, it WORKED!!!! Below is my first run uploaded to Garmin Connect using Firefox on Linux. While the first try was not flawless, I could not be happier. Thanks to all those who have worked on it. Now I can add support for uploading hand-drawn courses in Routometer directly to your Garmin.
Here are some notes on things I did to get Arduino working on Fedora Linux:
sudo yum install arduino
/uetc/udev/rules.d/60.rules:
KERNEL=="ttyACM*", MODE="0666"
I needed a GstController to control the alpha channel on a video crossfade. The gstreamer documentation makes it look easy, but it actually tripped me up for quite some time. I am using the python bindings, and they have some subtlies that took me some time to figure out.
First, I got the general usage out of the Pitivi source code. To create a controller, you do the following:
controller = gst.Controller(alpha, "alpha")
controller.set_interpolation_mode("alpha", gst.INTERPOLATE_LINEAR)
controller.set("alpha", 0, 0.0)
controller.set("alpha", 5*gst.SECOND, 1.0)
In the above example, alpha is the element to be controlled. This causes the alpha property on the alpha element to linearly change from 0.0 to 1.0 over the course of 5 seconds.
After adding the above code snippet to my application, however, it did not work. To debug it, I ended up checking out the gstreamer source code and after tracing things through using printf()’s, I finally discovered that my controller was getting attached to the alpha as I wanted but then it was getting detached almost immediately thereafter. That made me realize that in python I needed to hold a reference to the controller for the duration of the stream. I was letting the controller variable in the above example go out of scope, at which point it had no more references and therefore got deleted and removed from the alpha element. So the solution was to hold a reference to it as shown below in the example of a video crossfade:
import os, time
import gobject
import pygst
pygst.require("0.10")
import gst
class Main:
def __init__(self):
src1 = gst.element_factory_make("filesrc")
src2 = gst.element_factory_make("filesrc")
src1.set_property("location", "/home/lane/test1.mp4")
src2.set_property("location", "/home/lane/test2.mp4")
dec1 = gst.element_factory_make("decodebin2")
dec2 = gst.element_factory_make("decodebin2")
alpha1 = gst.element_factory_make("alpha")
alpha2 = gst.element_factory_make("alpha")
self.controller = gst.Controller(alpha2, "alpha")
self.controller.set_interpolation_mode("alpha", gst.INTERPOLATE_LINEAR)
self.controller.set("alpha", 0, 0.0)
self.controller.set("alpha", 5*gst.SECOND, 1.0)
mixer = gst.element_factory_make("videomixer")
queue = gst.element_factory_make("queue")
color = gst.element_factory_make("ffmpegcolorspace")
sink = gst.element_factory_make("autovideosink")
pipeline = gst.Pipeline("pipeline")
pipeline.add(src1, src2, dec1, dec2, alpha1, alpha2, mixer, queue, color, sink)
def on_pad(comp, pad, data, element):
sinkpad = element.get_compatible_pad(pad, pad.get_caps())
pad.link(sinkpad)
dec1.connect("new-decoded-pad", on_pad, alpha1)
dec2.connect("new-decoded-pad", on_pad, alpha2)
src1.link(dec1)
src2.link(dec2)
alpha1.link(mixer)
alpha2.link(mixer)
mixer.link(queue)
queue.link(color)
color.link(sink)
self.pipeline = pipeline
def start(self):
self.running = True
bus = self.pipeline.get_bus()
bus.add_signal_watch()
bus.enable_sync_message_emission()
bus.connect("message", self.on_message)
self.pipeline.set_state(gst.STATE_PLAYING)
def on_exit(self, *args):
self.pipeline.set_state(gst.STATE_NULL)
self.running = False
def on_message(self, bus, message):
t = message.type
if t == gst.MESSAGE_EOS:
self.on_exit()
elif t == gst.MESSAGE_ERROR:
err, debug = message.parse_error()
print "Error: %s" % err, debug
self.on_exit()
loop = gobject.MainLoop()
gobject.threads_init()
context = loop.get_context()
m = Main()
m.start()
while m.running:
context.iteration(True)
Some things to note in the above code:
controller from going out of scope and getting deleted, I added it as an attribute to the Main object (i.e. self.controller).$DISPLAY environment variable set.It took me an amazingly long amount of time to figure this one out, but here is a simplified python script to perform a video crossfade in gstreamer using the gnonlin package.
import os, time
import gobject
import pygst
pygst.require("0.10")
import gst
gst.MILLISECOND = gst.SECOND / 1000
def get_crossfade(duration):
# To crossfade, we add an alpha channel to both streams. Then a video
# mixer mixes them according to the alpha channel. We put a control
# on the alpha channel to linearly sweep it over the duration of the
# crossfade. The returned bin should get placed in a gnloperation.
# The reason to put the alpha and final ffmpegcolorspace conversion
# in this bin is that are only applied during the crossfade and not
# all the time (saves some processing time).
bin = gst.Bin()
alpha1 = gst.element_factory_make("alpha")
alpha2 = gst.element_factory_make("alpha")
mixer = gst.element_factory_make("videomixer")
color = gst.element_factory_make("ffmpegcolorspace")
bin.add(alpha1, alpha2, mixer, color)
alpha1.link(mixer)
alpha2.link(mixer)
mixer.link(color)
controller = gst.Controller(alpha2, "alpha")
controller.set_interpolation_mode("alpha", gst.INTERPOLATE_LINEAR)
controller.set("alpha", 0, 0.0)
controller.set("alpha", duration * gst.MILLISECOND, 1.0)
bin.add_pad(gst.GhostPad("sink1", alpha1.get_pad("sink")))
bin.add_pad(gst.GhostPad("sink2", alpha2.get_pad("sink")))
bin.add_pad(gst.GhostPad("src", color.get_pad("src")))
return bin, controller # return the controller otherwise it will go out of scope and get deleted before it is even applied
class Main:
def __init__(self):
dur1 = 5000 # duration (in ms) to play of first clip
dur2 = 5000 # duration (in ms) to play of second clip
dur_crossfade = 500 # number of milliseconds to crossfade for
# we play two clips serially with a crossfade between them
# using the gnonlin gnlcomposition element.
comp = gst.element_factory_make("gnlcomposition")
# setup first clip
src1 = gst.element_factory_make("gnlfilesource")
comp.add(src1)
src1.set_property("location", "/home/lane/work/sshow/src/test1.mp4")
src1.set_property("start", 0 * gst.MILLISECOND)
src1.set_property("duration", dur1 * gst.MILLISECOND)
src1.set_property("media-start", 0 * gst.MILLISECOND)
src1.set_property("media-duration", dur1 * gst.MILLISECOND)
src1.set_property("priority", 1)
# setup second clip
src2 = gst.element_factory_make("gnlfilesource")
comp.add(src2)
src2.set_property("location", "/home/lane/work/sshow/src/test2.mp4")
src2.set_property("start", (dur1-dur_crossfade) * gst.MILLISECOND)
src2.set_property("duration", dur2 * gst.MILLISECOND)
src2.set_property("media-start", 0 * gst.MILLISECOND)
src2.set_property("media-duration", dur2 * gst.MILLISECOND)
src2.set_property("priority", 2)
# setup the crossfade
op = gst.element_factory_make("gnloperation")
fade, self.controller = get_crossfade(dur_crossfade)
op.add(fade)
op.set_property("start", (dur1-dur_crossfade) * gst.MILLISECOND)
op.set_property("duration", dur_crossfade * gst.MILLISECOND)
op.set_property("media-start", 0 * gst.MILLISECOND)
op.set_property("media-duration", dur_crossfade * gst.MILLISECOND)
op.set_property("priority", 0)
comp.add(op)
# setup the backend viewer
queue = gst.element_factory_make("queue")
sink = gst.element_factory_make("autovideosink")
pipeline = gst.Pipeline("pipeline")
pipeline.add(comp, queue, sink)
def on_pad(comp, pad, element):
sinkpad = element.get_compatible_pad(pad, pad.get_caps())
pad.link(sinkpad)
comp.connect("pad-added", on_pad, queue)
queue.link(sink)
self.pipeline = pipeline
def start(self):
self.running = True
bus = self.pipeline.get_bus()
bus.add_signal_watch()
bus.enable_sync_message_emission()
bus.connect("message", self.on_message)
self.pipeline.set_state(gst.STATE_PLAYING)
def on_exit(self, *args):
self.pipeline.set_state(gst.STATE_NULL)
self.running = False
def on_message(self, bus, message):
t = message.type
if t == gst.MESSAGE_EOS:
self.pipeline.set_state(gst.STATE_NULL)
self.on_exit()
elif t == gst.MESSAGE_ERROR:
err, debug = message.parse_error()
print "Error: %s" % err, debug
self.on_exit()
loop = gobject.MainLoop()
gobject.threads_init()
context = loop.get_context()
m = Main()
m.start()
while m.running:
context.iteration(True)
I struggled to get the smpte transitions working using the smpte plugin element and never got it. Using the smptealpha plugin element, however, I was able to get transitions working using the same approach as the crossfade example above. All I had to do was create a new function:
def get_smpte(duration, transition=1):
# To crossfade, we add an alpha channel to both streams. Then a video
# mixer mixes them according to the alpha channel. We put a control
# on the alpha channel to linearly sweep it over the duration of the
# crossfade. The returned bin should get placed in a gnloperation.
# The reason to put the alpha and final ffmpegcolorspace conversion
# in this bin is that are only applied during the crossfade and not
# all the time (saves some processing time).
bin = gst.Bin()
alpha1 = gst.element_factory_make("alpha")
smpte = gst.element_factory_make("smptealpha")
mixer = gst.element_factory_make("videomixer")
color = gst.element_factory_make("ffmpegcolorspace")
bin.add(alpha1, smpte, mixer, color)
alpha1.link(mixer)
smpte.link(mixer)
mixer.link(color)
smpte.set_property("type", transition)
controller = gst.Controller(smpte, "position")
controller.set_interpolation_mode("position", gst.INTERPOLATE_LINEAR)
controller.set("position", 0, 1.0)
controller.set("position", duration * gst.MILLISECOND, 0.0)
bin.add_pad(gst.GhostPad("sink1", alpha1.get_pad("sink")))
bin.add_pad(gst.GhostPad("sink2", smpte.get_pad("sink")))
bin.add_pad(gst.GhostPad("src", color.get_pad("src")))
return bin, controller
Now I can call this function get_smpte() place of the get_crossfade() function and get an smpte transition instead. Works great so far.
Here is nice summary of package manage commands at Ubuntu for Fedora Users.
Install Ubuntu according to BeagleBoardUbuntu.
For network, edit /etc/network/interfaces to include
auto usb1 iface usb1 inet dhcp
Then restart networking. Then run
apt-get update
For X
apt-get install xfce4 gdm xubuntu-gdm-theme xubuntu-artwork xserver-xorg-video-omap3
To run
apt-get install python-gst0.10 gstreamer0.10 gstreamer0.10-plugins-good
For development:
apt-get install gcc libxext-dev libtool autoconf automake pkg-config python-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev git libgdk-pixbuf2.0-dev libpng-dev
For extra:
apt-get install rsync emacs openssh-client midori apt-file
Create a file called /etc/gdm/custom.conf
[daemon] AutomaticLoginEnable=true AutomaticLogin=YourUserName TimedLoginDelay=0
Links:
For display, you edit the boot.cmd file in the uboot directory on the boot partition. The dvi_mode variable syntax is (taken from drivers/video/modedb.c):
Valid mode specifiers for @mode_option: * *x [M][R][- ][@ ][i][m] or * [- ][@ ] * * with , , and decimal numbers and * a string. * * If 'M' is present after yres (and before refresh/bpp if present), * the function will compute the timings using VESA(tm) Coordinated * Video Timings (CVT). If 'R' is present after 'M', will compute with * reduced blanking (for flatpanels). If 'i' is present, compute * interlaced mode. If 'm' is present, add margins equal to 1.8% * of xres rounded down to 8 pixels, and 1.8% of yres. The char * 'i' and 'm' must be after 'M' and 'R'. Example: * * 1024x768MR-8@60m - Reduced blank with margins at 60Hz.
There have been several occasions where I have needed to control the power state of my monitor (LCD or CRT) programatically. One time was for a custom LCD digital picture frame that I made. I wanted to turn off the LCD after a certain timeout period and turn it back on whenever a motion sensor produced an event. For that project I used the “xset” command line program and used a command like:
xset dpms force <on|off>
to turn it on and off. That worked, but this time around I wanted to do it programmatically rather than dropping to a system shell. I downloaded the source code for xset and found they were interfacing to the DPMS X11 extension. So I downloaded the source to libXext and found the DPMS API. It is a simple API, so I created some Python bindings to it and have published the results over at github. You can checkout the python-dpms project page over at github or download the source tarball and build it.
It is simple to turn on and off the monitor from python now:
import dpms, time d=dpms.DPMS() time.sleep(1) # this is necessary to prevent your last key press that launches this from waking the monitor right back up d.ForceLevel(dpms.DPMSModeOff) # turn monitor off d.Info() #d.ForceLevel(dpms.DPMSModeOn) # turn it on
You will need to save this to a file and run it non-interactively because the interactive shell will cause it to wake up instantly. When you run it non-interactively, it will turn off your monitor and then you can press any key to wake it back up.
Here is the README file from the project:
ABOUT
=====
This is python bindings to the DPMS X11 extension module for controlling
your monitor power savings state.
The DPMS interface lets you control the power level of your monitor
(On, Standby, Suspend, or Off). It is a simple interface that lets
you get/set timeouts of inactivity to enter these states or you can
force it to enter any of the states.
See example.py on how to use it. This file should be sufficient on how
to use it. It first shows how to query all the different settings and
then shows how to set them.
See also 'man xset' for a program that lets you modify the DPMS state
from the command line.
INSTALL
=======
Install libXext and python development packages installed. For
example, on RedHat/Fedora:
yum install libXext-devel python-devel
On Ubuntu:
apt-get install libxext6-dev python-dev
Then run:
python setup.py build
Then as root, run:
python setup.py install
That's it. Now run:
python example.py
to test it out.
The included example.py shows how easy it is to use:
import dpms
d = dpms.DPMS() # to use the current display, or alternatively DPMS(":1")
# print up the display
print "Display :", d.display()
# query extension, should return True as the first element
print "Query Extension :", d.QueryExtension()
# query Capable, not sure what it does
print "Capable :", d.Capable()
# query current version
print "Version :", d.GetVersion()
# query the current state of things
(level, enabled) = d.Info()
print "DPMS enabled :", enabled
if(level == dpms.DPMSModeOn):
current_level = "On"
elif(level == dpms.DPMSModeStandby):
current_level = "Standby"
elif(level == dpms.DPMSModeSuspend):
current_level = "Suspend"
elif(level == dpms.DPMSModeOff):
current_level = "Off"
else:
current_level = "Unknown (%d)" % level
print "Current Level :", current_level, "(", level, ")"
# query the current timeout settings
(standby, suspend, off) = d.GetTimeouts()
print "Timeouts"
print " Standby :", standby
print " Suspend :", suspend
print " Off :", off
# We have queried everything, now we will set everything back to its
# current state. We set back to the current state so as not to alter
# any state and so that you can see examples of setting state.
# set the timeout settings
d.SetTimeouts(standby, suspend, off)
# enable/disable DPMS
if(enabled):
d.Enable()
else:
d.Disable()
# force DPMS to a certain level
d.ForceLevel(level)
# if you wanted to force the monitor off, you could
#d.ForceLevel(dpms.DPMSModeOff)
# to force it back on
#d.ForceLevel(dpms.DPMSModeOn)
# You can also suspend or standby
#d.ForceLevel(dpms.DPMSModeSuspend)
#d.ForceLevel(dpms.DPMSModeStandby)
If you run python example.py, you will see output like:
Display : :0.0 Query Extension : (True, 0, 0) Capable : True Version : (1, 1) DPMS enabled : True Current Level : On ( 0 ) Timeouts Standby : 0 Suspend : 0 Off : 0
So just like that I can now turn on and off the monitor from my python programs. If you are not using python but C/C++, the /usr/include/X11/extensions/dpms.h shows how simple the API is, so don’t be afraid to use it.
I am a fan of reducing cost and complexity of test equipment by pushing the UI to the PC to make the test equipment headless. In this vein, however, I was previously disappointed in the purchase an ELAN USB oscilloscope. It claimed Linux support, but after much hoop jumping, I never got their java app working on linux. I ended up running it in a virtual machine running windows, and even then the experience was not great. That is story for another post, though. For this post I am going to provide my initial feedback on the ChronoVu USB Logic Analyzer LA-8 that I purchased on Ebay for $189.00.
The primary reasons I picked the ChronoVu amongst the other several options (see Comments at this link from SparkFun.com for additional competitive products) was that it sampled at 100MHz and the app ran on Linux without java. I downloaded the app prior to purchasing to give it a test run and noticed that it used QT for widgets, so I was happy that the performance had a chance at being adequate on Linux.
Amazingly, the setup on Linux (or at least Fedora 13) was quite seemless. I am used to futzing with everything from udev rules to 64b/32b issues to compiling kernel modules to etc. when using these sort of fringe products that claim Linux support, but everything worked out of the box on my Fedora 13 Linux install. The lsusb output is shown at the end of this post for those interested. It basically enumerates as a serial device and on my Fedora 13 machine, it appears on device node ‘/dev/ttyUSBX’ with correct permissions so that I can use it without root access (in other words, udev rules exist and work without issue). The application seems to detect and find the correct ttyUSB devnode to use, so I am not sure how it would behave with multiple units plugged in, but I do have other usb-serial devs on ttyUSB nodes and it has never been confused or had issues with that. That was a refreshing experience that shows they are serious about linux and not just releasing crippled linux support for marketing reasons.
My initial experience was to debug an I2C problem I was having. I flipped into a precanned I2C setup on the application, hooked up my probes, and pressed play. It asked for a file to save the data to (which I now find a bit annoying). It then downloaded and processed the data. That takes more time than I would like, but the precanned I2C bus analysis worked well and performed a deserialization of the data correctly. All that worked without any issue. Kudos to ChronoVu. It was a better experience than I was expecting based on my previous experience with a piece of USB test equipment.
While the initial experience was positive, after using it, there are several user interface issues that still keep this device in a class below dedicated logic analyzers. The sad thing is that these are primarily software issues. I hope ChronoVu takes notice because if these are addressed, then it will be a happy day for me when I can replace a many tens of thousand dollar machine that is the size of a desktop PC and requires its own cart with a sub $200 pocket sized piece of equipment. They have already taken a major step to that end, but it is not quite there (yet).
If I had to guess, there is a significant inductance on the ground connection between the units and the ground bounce induced by the high frequency clock is causing this problem. It is hard to blame this one on them without some more futzing, so for now, I will only hook up to the clock when I slow everything down to debug.
Bus 001 Device 080: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 ChronoVu
iProduct 2 ChronoVu LA8
iSerial 3 CV100528120813
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 ChronoVu LA8
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
Recently I ssh’d into one of my servers using the command ’ssh -X hostname’ from the client. I then tried to launch an X11 application but received the error:
Gtk-WARNING **: cannot open display:
I then found the DISPLAY environment variable was blank. A little searching around and I found that the I needed the xauth program installed. A
yum install xorg-x11-xauth
on the server did the trick. Now when I ssh in using the -X option, X11 applications run fine.