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

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

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.

• Install the Arduino software

  sudo yum install arduino
  

• Edit udev rules so that you have permission to talk to the serial port. To do this I added the following line to /uetc/udev/rules.d/60.rules:

  KERNEL=="ttyACM*", MODE="0666"
  

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:

• In order to prevent the controller from going out of scope and getting deleted, I added it as an attribute to the Main object (i.e. self.controller).
• I am manually iterating the mainloop. This is so that I do not have to create any gtk stuff. I recently discovered this technique and I use it in command line tools that do not require X11 or a $DISPLAY environment variable set.

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.

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

Autologin

Create a file called /etc/gdm/custom.conf

[daemon]
AutomaticLoginEnable=true
AutomaticLogin=YourUserName
TimedLoginDelay=0

Display

Links:

• http://www.mjmwired.net/kernel/Documentation/arm/OMAP/DSS
• http://www.omappedia.com/wiki/Bootargs_for_enabling_display

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.

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.

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).

User Interface Issues

• You cannot setup triggering options beyond the simple state==0 or state==1. This makes it hard to sync to events of interest. This is my biggest complaint. Makes it hard to do more than just simple debugging.
• The zoom level resets after every acquisition. Quite a pain given that events of interest can take a while to find again. This issue is also related to the lack of complex triggering options given that even if the view didn’t reset, I will still have to scroll around to find my event.
• The UI is sluggish to zoom and pan. This is annoying and further exacerbates the view reseting issue previously mentioned. This is my second biggest complaint.
• You cannot zoom in indefinitely, and even worse, you cannot zoom in adequately to see even 25ns clocks. This is quite annoying. I sampled a 25MHz clock at 100MHz and would like to see the clock up close. I realize that there will be some frequency beating between the 25MHz clock and 100MHz sampling rate, and I can live with that, but I still want to be able to zoom in and put some cursors down at the clock transition edges and make sure my clock is running as I expect. Instead I can only zoom in close enough to see a very high frequency signal, but nothing sufficient for what I want.
• It asks to save a file everytime you press play to capture some data. 90% of the time I am taking setup data and I want it as quickly as possible. For the 10% of the time I take data I care about (after I have it setup and framed the way I want), then it would be nice to click a “Save As” button and save the raw data somewhere. Otherwise, I would prefer it save to a temp file that I don’t have to manage or know about. I would rather click to save the data permanently after I know the data is what I want. Don’t bother me a priori with a popup box.
• Download and process time take too long. I count around 12 Mississippi’s (seconds). This is not a show a stopper, but annoying. They must not be using USB 2.0 high speed. I am not familiar with the Future Technologies USB-Serial chip they are using, but they would be well served by going with a chipset that supported high speed option as this would make it around 10 times faster and much more bearable.
• This one is a nit-pick, but the application installer creates a new root menu in the GNOME “Applications” menu list. Perhaps it should install in the FEL “Electronics” menu or “Other”.
• I don’t need a CD or a carrying case and would prefer not to pay for them.

Hardware Issues

There is crosstalk issue. I plugged in a low frequency signals into channel 0 (FV) and channel 1 (LV) and a 50MHz clock into channel 2 (CLK). The clock beats as expected against the 100MHz sampling rate, but it corrupts channel 0 and channel 1 as you can see in this screen shot.

Disconnecting channel 2 probe from the clock and connecting it to ground solves the problem. The following is screen shot shows what channel 0 and channel 1 should look like in the previous capture.

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.

lsusb -v -s 001:080 output

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)

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.