The Goggles, They Do Something
There is really very little hardware setup to do. Just plug in the VGA and USB plugs to your machine. As I mentioned before, the USB port is used to power the display as well as to send audio to the goggles (it's also how you would access the accelerometer). Here is the relevant syslog output I got when I connected the VR920 to my Ubuntu machine:
Sep 14 19:51:01 moses kernel: [13069.884651] usb 6-1: new full speed USB device using uhci_hcd and address 2 Sep 14 19:51:01 moses kernel: [13070.101323] usb 6-1: configuration #1 chosen from 1 choice Sep 14 19:51:02 moses kernel: [13070.291377] usbcore: registered new interface driver hiddev Sep 14 19:51:02 moses kernel: [13070.361931] usbcore: registered new interface driver snd-usb-audio Sep 14 19:51:02 moses kernel: [13070.397112] generic-usb 0003:1BAE:0002.0001: hiddev96,hidraw0: USB HID v1.00 Device [Icuiti Corp. VR920 Video Eyewear] on usb-0000:00:1d.0-1/input3 Sep 14 19:51:02 moses kernel: [13070.397155] usbcore: registered new interface driver usbhid Sep 14 19:51:02 moses kernel: [13070.397162] usbhid: v2.6:USB HID core driver Sep 14 19:51:02 moses pulseaudio: alsa-util.c: Cannot find fallback mixer control "PCM" or mixer control is no combination of switch/volume. Sep 14 19:51:03 moses pulseaudio: alsa-util.c: Device hw:1 doesn't support 2 channels, changed to 1. Sep 14 19:51:03 moses pulseaudio: module-alsa-source.c: Your kernel driver is broken: it reports a volume range from 0 to 0 which makes no sense. Sep 14 19:51:03 moses pulseaudio: module-alsa-source.c: Your kernel driver is broken: it reports a volume range from 0.00 dB to 0.00 dB which makes no sense.
So pulseaudio does appear to see the audio mixer, and even though it throws some strange errors in syslog output, the sound worked fine. From the output, I can tell that it sees it as the hw:1 ALSA device. I also saw a new /dev/dsp1 device, and the device even showed up in my GNOME sound properties window, so I could select the device from there.
The screen itself is detected without any extra effort on my part and shows up in xrandr:
greenfly@moses:~$ xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 VGA connected (normal left inverted right x axis y axis) 1024x768 60.0 800x600 60.3 640x480 59.9 720x400 70.1
You certainly can use xrandr to toggle whether the display is on, but you also can configure it in the default GNOME Display Preferences window (Figure 2). Personally, I set up a quick xrandr script to toggle the goggles on when I wanted to use them:
#!/bin/sh if [ -f /tmp/.goggles_on ] ; then xrandr --output VGA --off & echo "Goggles Off" | osd_cat --shadow=2 --align=center ↪--pos=bottom --color=green --delay=2 ↪--font=lucidasanstypewriter-bold-24 --offset 40 & rm /tmp/.goggles_on else xrandr --output VGA --mode 640x480 --below LVDS echo "Goggles On" | osd_cat --shadow=2 --align=center ↪--pos=bottom --color=green --delay=2 ↪--font=lucidasanstypewriter-bold-24 --offset 40 & touch /tmp/.goggles_on fi
In this configuration, the goggles act as a 640x480 screen below my regular desktop, and I can drag windows there just like with any other monitor.
The main thing to realize when you use the VR920 like a regular monitor is that even though the display supports 1024x768 input, the actual screens go up to only 640x480, and anything higher resolution gets scaled to fit. For my uses, I stayed with 640x480. Honestly, at that resolution, the screen worked pretty well as an extra screen on my desktop, and I moved IRC windows and other small terminals over to it.
The main limiting factor for how useful the screen is on a regular desktop is the resolution, but nearsightedness aside, I thought it actually was a pretty slick way to have IM, IRC or a terminal window always in your field of view. As a sysadmin, I also can see how it might be useful to tail logfiles in that screen or possibly put all of your monitoring applets there. Just realize that if you arrange the goggles so you can look up to view them and look down to view your regular screen, you won't necessarily be able to use your peripheral vision to see changes in the goggles—you'll have to look up every now and then. Also, I don't think it would work quite as well for programs like The GIMP or for word processing or anything else that might need more screen real estate.
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- LiveCode Ltd.'s LiveCode
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide