2016-04-27I am on SlackwareARM on my Raspberry Pi 2 and have the PiNOIR camera connected to it. At first I thought it should be pretty easy to accomplish, but it turned out to be trickier than I thought.
At first, I couldn't find reliable information whatsoever, but after some more specific search terms I found a solution that worked.
All these steps are meant to be executed by root
Step 1 - download and install raspberry pi userland tools
git clone "https://github.com/raspberrypi/userland.git"
Step 2 - apply permissions to devices
usermod -a -G video
chmod 0660 /dev/vchiq
chgrp video /dev/vchiq
echo 'SUBSYSTEM=="vchiq",GROUP="video",MODE="0660"' > /etc/udev/rules.d/10-vchiq-permissions.rules
Step 3 - Modify library paths
echo "/opt/vc/lib" >> /etc/ld.so.conf
Step 4 - create a file called /etc/profile.d/videocore-paths.sh and edit it like this:
# For root users, ensure that /opt/vc/sbin is in the $PATH.
if [ "`id -u`" = "0" ]; then
echo $PATH | grep /opt/vc/sbin 1> /dev/null 2> /dev/null
if [ ! $? = 0 ]; then
# Add videocore utilities to system $PATH:
Step 5 - make it executable
chmod a+x /etc/profile.d/videocore-paths.sh
Step 6 - modify config.txt
echo "gpu_mem=128" >> /boot/config.txt
echo "start_file=start_x.elf" >> /boot/config.txt
echo "fixup_file=fixup_x.dat" >> /boot/config.txt
echo "disable_camera_led=1" >> /boot/config.txt
Please make sure that your config.txt has the new values in it and then reboot and enjoy :)
If everything worked, you can try:
raspistill -o test.jpg
to test if it really worked. If it tells you something about permissions, make sure your user is in the video group.
2016-03-09Today I ran in some strange difficulties. After setting up my NFS server on Slackware I tried to mount the shared directory on my Slackware client, which worked flawlessly. Unfortunately, this was not the case on a different machine running ArchLinux. The /etc/exports file on my server looks like this:
After activating and enabling the needed rpc and nfs parts with systemctl on that Arch box, I tried to mount the shared directory the same way I did on Slack. But for some reason it took the Arch box about 20 seconds to mount the directory. On the server side, the following errors occured in dmesg:
[83130.174026] NFSD: Unable to create client record on stable storage: -110
After searching this error line on google, I couldn't find any real help. My question in #archlinux on IRC remained unanswered. After some fiddling around with different settings, I finally found the solution. It seems that ArchLinux tries to mount the remote nfs directory with nfsv4, but the Slackware server uses nfsv3. After adding vers=3 to the mount options in fstab it finally worked and the error disappeared. The fixed fstab line now looks like this:
SERVER:/mnt/hd /mnt nfs vers=3,user,noauto,rsize=8192,wsize=8192 0 0
Additionally, I couldn't find out where ArchLinux sets his default mount options for NFS volumes. When mounting without any options it sets many options by itself, which really annoys me. But at least it works now. It bugs me out though that even if I explicitly changed the filesystem type to nfs in fstab, it tries to use nfsv4 at first. That sucks. Hard. I guess all this is systemd-related, another reason to hate it.
2016-02-24I've been using urxvt for quite a long time now. When I was on Arch, setup was a little easier though. Now in Slackware, I have to build the package from Slackbuilds, which works pretty well with sbopkg.
Unfortunately, the termcap file is missing or was not patched into my local termcap file. Because of this, my Home- and End-keys didn't work. Another thing that annoyed me was the missing Ctrl+L option. On most Linux terminals this should clear the screen, in urxvt it happened to produce a simple newline, which is not what I want.
After some research and thought, I remembered that /etc/inputrc had something to do with it. I had a slight clue, that I had to change something there. The new parts I added to it looked like this:
# for urxvt
With these 2 lines added, the Home- and End-Keys work as expected again. Now, let's move on to the second matter, the Ctrl+L problem. To tell my system about the capabilities of urxvt, I had to add these lines to /etc/termcap:
# Reconstructed via infocmp from file: /etc/terminfo/r/rxvt-unicode
# (untranslatable capabilities removed to fit entry within 1023 bytes)
rxvt-unicode|rxvt-unicode terminal (X Window System):\
After I added this lines to my termcap file, everything works just fine.
2016-02-18Well, HELLO there! :)
Since my previous blogging suite didn't fit my needs anymore I felt the need to rewrite it. This is the result and it is called freki.
To get a clue what freki does and what it is, you may want to visit my github page. Inside the repository you will find everything you need if you want to try it. Freki doesn't need anything to run except Perl itself, which was one of my goals. My previous attempt to do such a thing was bazinga which now is obsolete (for me).