The orange box Pi2 powered tablet is shown running Netsurf on NetBSD in Figure 1. It’s always so hard to get good pics of screens in photos like this. It really looks much clearer in reality (versus this pic).
Some notes about the WiFi setup on the orange box:
The system recognized the WiFi adapter (usually that’s the case with any Realtek on any OS). But, the network didn’t come up immediately via the config in /etc/rc.conf. For a little time I was manually bringing the network up with /usr/sbin/wpa_supplicant. Finally, I read the following email:
The part that made things work, for me, was in /etc/rc.d/dhclient:
- load_rc_config $name
- sleep 10 #this line added
- run_rc_command “$1”
The author of the email has an explanation for what he thinks is going on. Anyway, I’m good with his solution – cuz I no longer have to manually setup the network (which is a pain when you want to log in via remote ssh). I’ll deal with the ten second delay.
For my /etc/rc.conf file, I used what I found on the wiki (or close to it):
- wpa_supplicant_flags=”-B -i urtwn0 -c /etc/wpa_supplicant.conf”
The “-nw” option specifies no wait on dhclient, and the “-B” wpa flag option specifies that wpa should be run as a daemon. I’m showing only the WiFi and dhclient setup. I’ve put config for a firewall and some other things in the file as well.
Apparently, starting things manually allowed enough extra time to elapse so that the network worked when done that way. When run automatically, via the scripts, there wasn’t enough time (according to the theory in the email anyway).
An /etc/wpa_supplicant.conf (if it’s ~same as the wiki default) looks similar to what is shown in blue:
Default (on the wiki and on some systems) is shown in blue.
The default setup doesn’t have the network hidden (the scan_ssid=1 line). Some people prefer to use the bssid=xx:xx:xx:xx:xx:xx line in place of the ssid (where the xx values are replaced appropriately). The light gray lines show some of the options people use in replacement of, or in addition to – the defaults. None of this is advice, and I’m not a WiFi security expert. Some other known options are shown in the light gray color. These are options that may or may not enhance the WiFi setup, but I’m not recommending any of them (nor the omission of any of them).
The wpa_supplicant.conf file that is shown in the wiki (and is approximately what is shown in the blue font, above) – uses the defaults for unstated options, which a person may or may not want. For instance, there are other things that can be added to the configuration. It can be forced to use WPA2 rather than WPA, and AES encryption rather than TKIP (the latter of which is not considered very secure). The default setup will pick what “works” – but the result may not be the most secure choice (it might use TKIP for instance). I’m not making any suggestions for what should be used, and am not claiming to be the expert, but I am noting that the defaults probably should be used only where security is not an issue, and that may not be very many places.
I’m not putting my exact config on this page, because I had to futz with it, and it’s not giving my all that I want. For instance, it’s working with AES encryption on unicast, but not multicast traffic. So wpa_supplicant is a work-in-progress for me, at least on Pi+NetBSD. I’m using some of the gray colored option lines, but ain’t saying which.
Audio on the NetBSD, Pi2 powered tablet:
The next big thing to put into the Orange Box tablet was audio. Hey – I need my tunes! It was pretty simple really, although after my experience with NetBSD using Bluetooth 3.0 – I wondered if there might be a hitch. No hitch at all was found, and the Orange Box now plays NetBSD powered tunes. To do this deed, I performed the following:
I installed a USB audio dongle that has the CMedia chipset. NetBSD recognized it immediately, and the proper kernel module was loaded, and the device appeared as /dev/audio1 in /dev.
I adjusted the mixer volume (it defaults to full volume if this isn’t done). The mixer is the really old-time one, per the following example:
- mixerctl -d /dev/audio1 -a -v
- mixerctl -d /dev/audio1 -w outputs.speaker=98,98
The first line causes the mixer control to list all of the possible things that can be tweaked. The second line sets the volume, (left and right channels) per one of the items listed when line 1 was executed.
Being a good open source sound person, I loaded an ogg audio file to test:
nice -n4 ogg123 -d oss -o dsp:/dev/audio1 -o buffer-time:200000 –audio-buffer 10000 ./testaudio1.ogg
The Pi2 plays audio very well on NetBSD when using this command line. Without the buffer stuff, audio seems to lag a little bit occasionally. I should add that I used pkgsrc to build aoaudio, portaudio, oss, and of course the ogg utilities. The utilities can be built with just aoaudio instead of flac, if you want just ogg files (which I do).
BTW, for ogg vorbis afficionados, here’s a few tips:
The ogg123 playline can be used with multiple ogg vorbis files, i.e.,
nice -n4 ogg123 -d oss -o dsp:/dev/audio1 -o buffer-time:200000 –audio- buffer 10000 myaudio*.ogg
Another thing about ogg vorbis files is that they can be concatenated:
cat oggaudiofile1.ogg oggaudiofile2.ogg oggaudiofile3.ogg > allthreeaudiofilesinone.ogg
Then playing just that one (all-in-one) file can be done:
nice -n4 ogg123 -d oss -o dsp:/dev/audio1 -o buffer-time:200000 –audio- buffer 10000 allthreeaudiofilesinone.ogg
Ogg123 will list each item that has been concatenated onto the file, playing them all in succession, with individual stats displayed for each one, written to a new standard output line as the file plays.
Note: the author does not have a recent, applicable background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.
Note: This author and site is not affiliated with the Raspberry Pi in any way. For information about those projects visit http://www.raspberrypi.org “Raspberry Pi” is a trademark of the Raspberry Pi Foundation. NetBSD is trademarked by the NetBSD Foundation, Inc, and the operating system can be found at http://www.netbsd.org. This author and site has no affiliation with NetBSD. Netsurf is a project that resides at http://www.netsurf-browser.org and is not affiliated with this site in any way.
Netsurf is a product of the people at http://www.netsurf-browser.org, and is GPL licensed by them (except for the included graphics such as shown in the photo (in figure 1) relative to icons, etc – and they are MIT licensed). In the event that the GUI layout is copyrighted, then figure 1 becomes a derivative work, and must be distributed with the same license (GPL).