DD-WRT is a Linux based alternative Open Source firmware suitable for a great variety of WLAN routers and embedded systems. The main emphasis lies on providing the easiest possible handling while at the same time supporting a great number of functionalities within the framework of the respective hardware platform used.

You can check whether a device is supported by DD-WRT or not by checking the device’s model name in the database of supported routers. If you are like me and prefer to read an overview of the wireless N devices instead of querying a database, there is a page in the project’s wiki that lists all these devices.

After checking the technical specifications of several routers on their manufacturer web sites, it is quite clear that at this moment there are not many wireless N routers & ADSL2+ modem combos that are fully supported by DD-WRT. In my case that won’t be a big problem, but I’d really like the device to have a DSL port so as to keep the number of devices around the house at a minimum. But anyway, this is not a big deal.

Some other things I’d consider a plus for such a device are:

1. Support for Wireless Client Mode by the manufacturer’s firmware
2. Support for a VPN Server by the manufacturer’s firmware

I know that these functions are available anyway if the DD-WRT firmware is used, but, if the default firmware supported these functions, it would definitely make a difference for me. Another useful feature would be the existence of a USB port, but this would greatly limit the available supported devices, so this is not a mandatory feature.

So, if anyone has a suggestion for such a router or if you own one, please let me know about your experience with it. I am particularly interested for devices that are 100% supported by the DD-WRT open source firmware.

Related Articles

• Viceo Backend for SANE with libusb support
• Software that detects violations of open source licenses
• Creative PC-CAM 750 on Fedora 10
• Creative PC-CAM Series webcams in linux
• Howto: DHCP Server (dhcpd) Configuration

The problem most likely to hit you with one of these drives is very slow write performance. This is caused by improper logical-to-physical sector alignment. OS’s like Linux use 4K blocks (or multiples of 4K) to store data, which matches well with the physical sector. However, nothing restricts you from creating a partition that starts on an odd-numbered 512-byte logical sector. This misalignment causes a performance hit since the drive has to read and rewrite the 4K sectors with whatever 512-byte slices changed.

The article author continues with a test he performed on two identical WD Green drives containing one partition. On the first drive he used fdisk defaults for the partition boundaries, while on the second drive he manually aligned the partition. The results show that a misaligned drive can be up to 3 times slower than a properly aligned one.

…I formatted both drives using the command “time mke2fs /dev/sdc1″ (and sdd1).

/dev/sdc, which was aligned, took 5m 45.716s to format.
/dev/sdd, which was not aligned, took 19m 53.609s to format.

That’s a difference of greater than a factor of three!

The article author conducted several other tests. This is a very good read. Read the full article.

Related Articles

• Howto: Run VMWare on a Physical Windows Partition
• Effective data wiping with a single complete overwrite
• Partition images with Partimage and Partimaged
• Hard disk upgrade on an old motherboard
• Windows 7, OpenSolaris – put to the test

Refering to the myth, the author of the article writes:

One of the reasons behind this idea is that the positioning of a hard disk drive’s head is not precise enough to ensure that the data is overwritten with new information from the exact same byte.

A study, published on December 2008, claims that tests performed on both last and older generation hard drives have shown that recovering even a single byte of data after a complete overwrite is practically impossible.

Security researchers from Heise Security, who have reviewed the paper presented at last year’s edition of the International Conference on Information Systems Security (ICISS), explain that a single byte of data can be recovered with a 56 percent probability, but only if the head is positioned precisely eight times, which in itself has a probability of occurring of only 0.97%.

Since I was one of those who believed the statement about the multiple overwrites, I found the article very interesting. I haven’t read the study itself though.

Related Articles

• Partition Misalignment Slows Down 4096-Byte Sector Hard Disks
• How to create a single file of Sphinx based documentation
• Choosing a format for data backups – tar vs cpio
• Shred changes default number of passes to 3
• The Complete Fedora Kernel Headers

As mentioned previously, as soon as the device is plugged into the USB port, GNOME mounts its internal flash memory.

Looking at dmesg output as root:

# dmesg
usb 3-1: new full speed USB device using uhci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
usb 3-1: New USB device found, idVendor=041e, idProduct=4013
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: Creative PC-CAM 750
usb 3-1: Manufacturer: ViewQuest Technologies INC.
Linux video capture interface: v2.00
gspca: main v2.2.0 registered
gspca: probing 041e:4013
gspca: probe ok
gspca: probing 041e:4013
usbcore: registered new interface driver sunplus
sunplus: registered
gspca: disconnect complete

As you can see, despite the fact that the webcam has been recognized by the gspca-sunplus driver, gspca loses control of the webcam. This happens because GNOME (gvfs) has mounted its memory. Obviously, the device cannot operate as a webcam while its internal memory is mounted.

To list the currently mounted block devices by gvfs run the following command as your currently logged in user:

$ gvfs-mount -l
Drive(0): CD-RW/DVD±RW Drive
Drive(1): Mass Storage Drive
...
...
Mount(0): Creative Technology, Ltd PC-Cam 750 -> gphoto2://[usb:003,002]/

So, there it is. The gphoto2 driver has been used to mount the device’s flash memory.
To unmount it run (as the currently logged in user):

$ gvfs-mount -u gphoto2://[usb:003,002]/

Replace the usb port reference according to your gvfs-mount -l output.

Alternatively, you can unmount all devices mounted by the gphoto2 driver with the following command:

$ gvfs-mount --unmount-scheme gphoto2

Now, the camera’s memory shouldn’t be listed in gvfs-mount -l output.

All you have to do now to get to webcam-mode is reload the gspca-sunplus module.

As root:

# /sbin/modprobe -vr gspca-sunplus
# /sbin/modprobe -v gspca-sunplus

Running dmesg we confirm that the gspca-sunplus module controls the device

# dmesg
...
...
Linux video capture interface: v2.00
gspca: main v2.2.0 registered
gspca: probing 041e:4013
gspca: probe ok
gspca: probing 041e:4013
usbcore: registered new interface driver sunplus
sunplus: registered

Also, the ls command shows that our v4l device has been created:

# ls -l /dev/video*
lrwxrwxrwx  1 root root     6 2008-12-08 15:49 /dev/video -> video0
crw-rw----+ 1 root root 81, 0 2008-12-08 15:49 /dev/video0

That’s it. As a user, run cheese and say hello to yourself!

This should work for all other digital-camera / web-camera combo devices as well, provided that you use the appropriate gspca driver as shown in the dmesg output.

Your feedback is welcome.

Related Articles

• Creative PC-CAM Series webcams in linux
• Access gvfs mounts from the command line
• A different approach…HAL
• Viceo Backend for SANE with libusb support
• Blanking a rewritable CD/DVD in GNOME

Driver History

Here goes some brief history about the driver.

The E3 driver was initially developed by Steven Ellis (http://viceo.orcon.net.nz/). 0.6 was the last released version (2002), which lacked support for libusb. It seems that Steven abandoned the development of the driver at that point. Until a few days ago, the 0.6 release was what I had considered as the latest available version of the E3 driver.

What I missed, was the fact that Jimmy Nguyen had modified the 0.6 driver and had added support for libusb. I had spent countless hours searching the web in the past but I could not locate such a release of the driver. Anyhow, Jimmy’s patch was released in 2004 for sane-backends-1.0.14.

The rest has been already described above.

Supported Devices

This driver works with USB scanners equipped with the E3 chipset. Some of these scanner models (if not all) are the following:

• Genius Vivid Pro USB
• Primax Colorado USB 19200
• Visioneer OneTouch 7600
• Visioneer OneTouch 6100
• IBM IdeaScan 2000 USB
• LG Electronics Scanworks 600U

Download

I have modified the original patch in order to make it work with sane-backends-1.0.18 and also wrote a SPEC file for RPM packaging. Using a package will greatly simplify the installation procedure.

Here follows a list of files you can download:

RPM – sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm

RPM package of Viceo backend. Requires sane-backends-1.0.18. Installs the Viceo backend only and will not touch any other files. Please read the Installation and Configuration sections for instructions.

DEB – TODO

A DEB file for debian-based distributions is not currently available. You can still generate a deb package from the RPM using alien. In order to convert the the RPM package to a DEB, use alien like: alien -k sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm and a deb package will be generated for you. You can install the DEB package with: dpkg -i sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.deb. Please note that this procedure has not been tested.

SPEC – viceo.spec

Required if you need to build the RPM package.

Patch – sane-backends-1.0.18-viceo.diff.gz

New Viceo backend patch for sane-backends 1.0.18. Note, that in addition to the required modifications in order to make this patch suitable for sane-backends-1.0.18, this diff does not include the modifications of the core SANE file sanei/sanei_usb.c. Everything seems to work just fine without having to patch any core SANE file.

Patch – viceoDriver4Sane1.0.14.tar.gz

Old package with Viceo patch for sane-backends 1.0.14 and some notes by Jimmy Nguyen about the release. Reading them is recommended.

All versions are available from the development web site’s download area.

Installation

Using the RPM or DEB package (see above for info) is the recommended method of installing. This package has been built in Fedora 8, but, since it is rather generic and does not contain any Fedora-specific information, it should work on any RPM-based distribution.

Using the RPM

The package sane-backends-1.0.18 is a dependency. Make sure you have installed it.

# wget http://www.codetrax.org/attachments/download/42/sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm
# rpm -ivh sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm

Please make sure you read the Configuration section for instructions on how to setup the scanner.

Manual installation

This information has been written with as much detail as possible, if you still have questions, please use the forums.

Note: The compilation of the backend should be performed by a regular user and not root.

First, download and extract the required packages. Although the sane-backends-1.0.18 package is used, we will only use it in order to build the Viceo backend.

$ wget ftp://ftp.sane-project.org/pub/sane/sane-backends-1.0.18/sane-backends-1.0.18.tar.gz
$ tar -xzf sane-backends-1.0.18.tar.gz
$ wget http://www.codetrax.org/attachments/download/41/sane-backends-1.0.18-viceo.diff.gz
$ gunzip sane-backends-1.0.18-viceo.diff.gz

Patch the sane-backends source code:

$ patch -p1 -b -d sane-backends-1.0.18/ < sane-backends-1.0.18-viceo.diff

Change to the sane-backends source code top-directory:

$ cd sane-backends-1.0.18/

We only care to build the Viceo backend, so set the BACKENDS environment variable to “viceo“.

$ export BACKENDS=viceo

Compile the backend:

$ ./configure --prefix=/usr --sysconfdir=/etc
$ make

We perform an installation in a temporary directory (1_test_install). This will help you pick up the correct files for the manual installation later. Also, you do not need root privileges for this.

$ mkdir 1_test_install
$ make DESTDIR="$PWD/1_test_install" install

Now, SANE and the viceo backend have been temporarily installed in the 1_test_install/ directory.

The following actions need to be performed by root or you can use sudo.

Make sure that sane-backends has been installed using your distribution’s package manager. Then copy the following files to the proper locations:

# cp 1_test_install/etc/sane.d/{e1.ini,lut.plg,viceo.conf} /etc/sane.d/
# cp 1_test_install/usr/lib/sane/libsane-viceo.so.1.0.18 /usr/lib/sane/

Finally, create a needed symbolic link to libsane-viceo.so.1.0.18.

# ln -s /usr/lib/sane/libsane-viceo.so.1.0.18 /usr/lib/sane/libsane-viceo.so.1

Update the library database. Run:

# ldconfig

That will be it.

SANE Configuration

The scanner configuration needs to be performed by root or you need to use sudo
The first thing to do is to add the viceo backend in /etc/sane.d/dll.conf. Note that the RPM will not do this, so you need to perform this step manually. Either add the work “viceo” (without quotes) at the end of /etc/sane.d/dll.conf or use the following command:

# echo "viceo" >> /etc/sane.d/dll.conf

If your scanner is not connected, please do so now.

Run the following command:

# sane-find-scanner

Your scanner should be identified:

[...]
found USB scanner (vendor=0x0461 [Primax], product=0x0360 [Colorado USB 19200]) at libusb:002:003
[...]

Take a note of the vendor and product codes and add a line using the following format to /etc/sane.d/viceo.conf:

usb <vendor> <product>

For me, that line inside /etc/sane.d/viceo.conf should be:

usb 0x0461 0x0360

Now list the available imaging devices. You scanner should be listed:

# scanimage -L

And this was the device listing:

device `viceo:usb 0x0461 0x0360' is a Visioneer Genius ColorPage-Vivid Pro USB flatbed scanner

Scanning

You can use the scanner either from the command-line or from within GIMP, provided that you have installed the xsane-gimp package.

If you use the scanner from the command line, wherever a device name is needed, use the device name that scanimage -L lists. For example:

# scanimage -d "viceo:usb 0x0461 0x0360" --mode Color --format=tiff --resolution 200 > z_out.tiff

Alternatively, you can set the following environment variable:

# export SANE_DEFAULT_DEVICE="viceo:usb 0x0461 0x0360"

Please read the SANE documentation for more information.

Licensing

The viceo backend is accompanied by two files which were included in the drivers for Windows, e1.ini and lut.plg. Although, you, as the owner of the hardware may use these files since you have paid for them, it is unclear whether there is a problem or not with distributing these files separately from the Windows driver package. The fact that these files are available from the home of the E3 driver v0.6, and are also included in sane-backends-1.0.14-viceo.diff, has led me to the conclusion that there is no problem in distributing these files. So, they are included in the my modified patch and RPM package. Please note that the aforementioned files e1.ini and lut.plg have neither been released nor distributed under the terms of a free license, eg GPL, so they are not free software.

Conclusion

Although the scanner is pretty old, it performs quite well. The driver won’t let you use resolutions over 600dpi, but I guess this is acceptable.

This article has been written in a fast pace. I have tried to provide as much detail as possible. If you still need help, please use our forums for your questions.

Happy scanning!

Related Articles

• pdf2email CUPS Backend
• Meld…
• Creative PC-CAM Series webcams in linux
• DD-WRT support for Wireless N Routers
• Kernel 2.6.17 and lirc_gpio driver

The issue

Last weekend, I decided to replace the two 10-year-old Quantum hard disks, which have heroicly powered my home server for the last years, with a newer Serial ATA hard drive. The goal was to buy more drives and build a RAID 5 environment, if all went well with the first HDD. The motherboard is an old QDI Brilliant 1s (440BX chipset) board using the “latest” beta BIOS. Serial ATA controllers are not on this mobo’s feature list, so I bought a Serial ATA controller PCI card – Sunix SATA2100 – together with the drive. I should mention that I bought both items from a local retailer. The controller’s package had a penguin on it, so I thought that the linux kernel would have no problems working with the controller’s chipset. I was badly misled! The card’s chipset, INITIO INI1622, is not supported by the kernel.

So, I had that card replaced for another SATA controller from eQuip. I don’t really remember the model, as I returned this card as quickly as possible, because it was not compatible with the motherboard’s PCI specification and the pc froze while on the “Verifying DMI pool data...” boot stage. Apart from that, the card’s chipset (by Silicon Image) was recognized properly by the linux kernel – I had it checked on another machine.

So, I had to return that card too. The retailer did not sell any other brands, but would not refund me either! So, I decided to buy an IDE ATA 133 controller instead. This was a Sunix card, but there was no clear information on the box about which model was inside. On the back, there were two small pictures of the 4700 (yellow board – iTE 8212F chipset) and the 3710 (green board – sil0680 chipset) models. On the front, there was a big picture of the 4700 model. Anyone who would have seen the box would bet that the included card was the 4700. But to my surprise, the card that was inside the box was neither 4700 nor 3710, but the 3700 model which carried the sil0680 chipset. This was a dissapointment as the 4700′s iTE chipset is better, but the important thing for me at that moment was that the card was working correctly under Linux. After this incident with the card’s package, I guess the best practice before buying a product from Sunix is to verify the package contents before you give away your money. Apart from the misleading box, I’d say that the card is of good quality and that it will definitely work with your old motherboards.

Although I had decided to settle with the IDE ATA 133 controller and use it with a Western Digital ATA 133 compatible HDD on the old machine, I still had the SATA hard disk from my initial purchase. I decided to use that disk on another pc, but still needed a PCI SATA controller. Fortunately, the second PC’s motherboard was not that old, so the only problem I had to face was if the controller’s chipset was supported by the Linux kernel. Of course, I wouldn’t buy such a card from the initial retailer again, so I went to a Media Market store and purchased a CN-033 SATA 2-port PCI card by Sitecom (chipset by Silicon Image – too lazy to check its exact model right now). It works flawlessly with the Linux kernel and the overall quality of the card and of the included cables was by far better than the quality of the cards by Sunix or eQuip. Of course I tried this card on the old motherboard too, but it would not go past the “Verifying DMI pool data …” stage either.

Hardcore Games with Hardware

So, the IDE ATA 133 PCI Controller from Sunix was supported by the kernel and everything seemed all right, but there were still some serious incompatibility issues with the QDI BX440 motherboard that needed to be addressed before I would be able to install Fedora 7 on the new hard disk. In short:

1. The QDI motherboard could not boot from any hard disk connected on the PCI controller.
2. It was required that a hard disk was connected to the onboard IDE channel, otherwise the pc froze at the f’n “Verifying DMI pool data ...” stage, like it happened with the other cards.
3. Even if there was a hard disk connected to the onboard IDE controller, the motherboard could not boot from the CD-ROM drive if another hard disk was connected to the PCI IDE controller.
4. The hard disk which I intended to use on that machine would not work if it was connected to the onboard IDE controllers. It seems that the ATA 133 HDD had difficulties working on an old ATA 33-only channel.

Under such complicated conditions, the only way to install a Linux distribution on a hard disk of newer technology than my old Quantums, was to:

1. Disconnect the Western Digital hard disk from the PCI controller and leave an old Quantum HDD on the onboard IDE channel.
2. Adjust the boot device sequence, so that the mobo boots from the CDROM device.
3. Install Linux on the old HDD.
4. Power-off and connect the newer HDD on the PCI controller.
5. Move the Linux installation from the old HDD to the new one.

The move of the Linux installation would be possible by following the steps of a tutorial like the “Hard-Disk Upgrade HOWTO“, if old-school partitions were used, or, in the case of LVM partitions, the move could be easily performed with the following procedure:

1. Having connected the new HDD, I would initialize the free space as a physical volume, so it could be used in an LVM setup.
2. Then I’d add this new physical volume to the existing Volume Group, eg: vgextend volume_group /dev/sdb
3. Finally, I would use the pvmove utility in order to move the data from the old physical volume (on the Quantum HDD) to the new physical volume (WD HDD), eg: pvmove sda sdb

One may think of other ways too, but these will do. For those of you who do not feel very comfortable with moving your installation around, read on…

Smart Boot Manager

One may wonder why I didn’t use Smart Boot Manager, which can boot the machine from any connected device, instead of doing all of this monkey stuff.

The reason is simple. The smart-boot-manager image, which is available from the project’s website, does not work for me. I tried to boot that image in qemu without success. On the other hand, smart-boot-manager images are all over the web, but… would you ever write an image, which has been downloaded from Mr.Unknown‘s home page, to your server’s hard disk Master Boot Record? I would never do that, even if I had to do twice as much monkey stuff as I have described above!

Fortunately, I soon found out that a smart-boot-manager image is included in a source that I can fully trust; in the Ubuntu ISO image, under the install directory, you will find: sbm.bin

This worked OK under QEMU:

# qemu -m 64 sbm.bin

So, after all this, here is what I did in order to install Fedora 7 directly on the new hard disk, which was connected to the PCI IDE controller.

1. First, I removed the HDD from the PCI controller and left only the HDD on the onboard IDE controller.
2. I set the boot sequence so that it boots from the cdrom.
3. I used the Ubuntu CD in order to get to a console.
4. I wrote the smart boot manager image to the Quantum hard-disk with: dd if=sbm.bin of=/dev/hda
5. Powered-off the system and connected the new HDD to the PCI controller.
6. I adjusted the boot sequence so to boot from the HDD on the onboard controller.
7. Put the Fedora Rescue CD in the CDROM drive.
8. Reboot the machine. At the Smart-Boot-Manager menu, I selected the CDROM option.
9. IU performed a network installation and used 100MB of the HDD on the onboard controller for the /boot partition and the new disk for the rest of the system partitions using LVM.

Hardware manufacturers have managed to transform me to a monkey for a couple of days. I have wasted time and money and I still cannot decide about who I am supposed to blame for this mess.

PS: It seems that the good old Quantum HDDs will stay on duty ;)

Related Articles

• Always use a block device label or its UUID in fstab
• UDEV
• Smart Bookmarks in Epiphany
• Change the console resolution
• How to create a Windows bootable CD with mkisofs

The K320i Features

For the regular feature listing, please visit the manufacturer’s website.

What I will describe here is how to get a list of the phone capabilities that are available over the USB and the Bluetooth interfaces under the Linux operating system.

This post is being written in a very fast pace. I’ll add much more detail when I have enough free time.

Preparation

1. Connect the phone to the computer using the USB cable.
2. Connect a Bluetooth USB dongle that works with your distro to your computer.
3. Turn on Bluetooth on the phone.

Over the USB Interface

Once the phone has been connected to the computer with the USB cable, two device nodes, /dev/ttyACM0 and /dev/ttyACM1, should be created. Unless you have adjusted the permissions on these devices so you can manage them from a regular user account, use root to browse the phone capabilities over the USB interface:

# obexftp -t /dev/ttyACM0 -X

Connecting...failed: connect
Still trying to connect
Connecting...done
Receiving "(null)"...< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE Capability SYSTEM "obex-capability.dtd">
<!--
 XML Coder, (C) 2001 Sony Ericsson Mobile Communications AB
-->
<capability Version="1.0"><general><manufacturer>Sony Ericsson</manufacturer>
<model>K320i</model>
<sn>XXXXXXXXXXXXXXXXXX</sn>
<sw Version="XXXXXXXXXXXXXXX" Date="XXXXXXXXXXXX"/>
<language>EN</language>
<memory><memtype>DEV</memtype>
<location>/</location>
</memory>
</general>
<service><name>Folder-Browsing</name>
<uuid>XXXXXXXX-XXXXXX-XXXX-XXXXX-XXXXXXXXXXXX</uuid>
<version>1.0</version>
<object><type>x-obex/folder-listing</type>
</object>
<ext><xnam>Pictures</xnam>
<xval>Folder=/Pictures</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>Camera Pictures</xnam>
<xval>Folder=/Picturesimage/camera_semc/100MSDCF</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>Videos</xnam>
<xval>Folder=/Videos</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>Cam. Video Clips</xnam>
<xval>Folder=/Videos/camera</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>Sounds</xnam>
<xval>Folder=/Sounds</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>Ringtones</xnam>
<xval>Folder=/Sounds/ringtones</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>VideoDJ</xnam>
<xval>Folder=/Sounds/videodj</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>Themes</xnam>
<xval>Folder=/Themes</xval>
<xval>MemType=DEV</xval>
</ext>
<ext><xnam>Others</xnam>
<xval>Folder=/Other</xval>
<xval>MemType=DEV</xval>
</ext>
</service>
</capability>
done
Disconnecting...done

The phone’s serial number and some other info has been replaced by Xs.

As you can clearly see, there is nothing to get excited about over the USB interface. It seems that by using the openobex utilities over the USB interface all I can do is transfer files etc.

Over the Bluetooth Interface

Here you will use two utilities, hcitool and sdptool. Both are part of the bluez-utils package in Fedora.

First, scan for your device, so to get its hardware address (replaced by Xs here):

# hcitool scan
Scanning ...
        XX:XX:XX:XX:XX:XX       GNOT

Then browse the available phone services that are available over the bluetooth interface:

# sdptool browse XX:XX:XX:XX:XX:XX

Browsing XX:XX:XX:XX:XX:XX ...
Service Description: Sony Ericsson K320
Service RecHandle: 0x10000
Service Class ID List:
  "PnP Information" (0x1200)
Service Name: Dial-up Networking
Service RecHandle: 0x10001
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100
Service Name: Serial Port
Service RecHandle: 0x10002
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 2
Service Name: HF Voice Gateway
Service RecHandle: 0x10003
Service Class ID List:
  "Handfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0101
Service Name: HS Voice Gateway
Service RecHandle: 0x10004
Service Class ID List:
  "Headset Audio Gateway" (0x1112)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 4
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0100
Service Name: OBEX Object Push
Service RecHandle: 0x10005
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 5
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100
Service Name: OBEX File Transfer
Service RecHandle: 0x10006
Service Class ID List:
  "OBEX File Transfer" (0x1106)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 6
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX File Transfer" (0x1106)
    Version: 0x0100
Service Name: OBEX SyncML Client
Service RecHandle: 0x10007
Service Class ID List:
  UUID 128: XXXXXXXx-xXXXXXXXXXXXXXX-XXXXXXX-XXXXXXx
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 7
  "OBEX" (0x0008)
Service Name: OBEX IrMC Sync Server
Service RecHandle: 0x10008
Service Class ID List:
  "IrMC Sync" (0x1104)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 8
  "OBEX" (0x0008)
Profile Descriptor List:
  "IrMC Sync" (0x1104)
    Version: 0x0100
Service Name: NAP service
Service Description: NAP description
Service RecHandle: 0x10009
Service Class ID List:
  "Network Access Point" (0x1116)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 15
  "BNEP" (0x000f)
    Version: 0x0100
    SEQ8: 0 6 dd
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Network Access Point" (0x1116)
    Version: 0x0100
Service Name: Mouse & Keyboard
Service Description: Remote Control
Service Provider: Sony Ericsson
Service RecHandle: 0x1000a
Service Class ID List:
  "Human Interface Device" (0x1124)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 17
  "HIDP" (0x0011)
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Human Interface Device" (0x1124)
    Version: 0x0100

Please note, that it is still possible to retrieve this list by using obexftp:

# obexftp -b XX:XX:XX:XX:XX:XX -X

But, I prefer sdptool‘s output.

Now this is becoming interesting! As you can see, over the BT interface the phone can be used as a modem, one can connect to its serial interface and execute AT commands, transfer files to and from the phone, synchronize the data with the data on the computer (IrMC and SyncML), it can act as a Network Access Point (NAP) or can be used as remote control.

Actually, what I did not manage to do is to establish a working network connection between the mobile phone and the computer (over the BNEP interface). All other things seem to work fine.

I’ll publish separate articles about how to accomplish all these tasks and I’ll also look for any info about how to create a Personal Area Network (PAN) between the phone and the computer. What seems to be the problem is how to trigger the phone so that it gets an IP address from the LAN’s DHCP server. Anyway, I don’t have enough time for this right now, but it is in my TODO list.

Related Articles

• Send a text file as SMS with a Sony-Ericsson mobile
• Mailing List Manager
• Add files to Totem playing list from Nautilus
• Drupal Tip: List a node’s taxonomy terms inside a Block
• Organizing Mailing List messages with Evolution

Anyway, this is the graph that shows the CPU fan go down… I must admit that the fan did try to continue doing its job :-)

(This image is hosted on Yahoo! Flickr)

Fortunately, I replaced the faulty fan with another one and this issue was resolved without any further problems. Maybe it’s time to re-consider any other monitoring software alternatives.

Related Articles

• Spamassassin FH_DATE_PAST_20XX test buggy in 2010
• Use the Alternatives System to switch to a custom Firefox release

Prerequisites

In order to use LIRC you will need the necessary hardware components, a remote control and an infrared receiver. LIRC supports a lengthy list of such devices. You can check if your equipment is supported at this page.

Next thing is to download the latest stable LIRC package from the project page and configure it properly for your equipment. For this article I’ll use the traditional way of compiling and installing software, so some such experience is required from your part. Of course, if you are into package building, you can build your own RPM or DEB package.

Configure, Compile, Install

Extract the LIRC package in a temporary directory (~/tmp/):

# tar -xzvf lirc-X.X.X.tar.gz -C ~/tmp/

The most important part of the LIRC pre-compilation configuration is the choice of the appropriate driver for your hardware. For more info check the LIRC Documentation. Normally, if you know your hardware, change to the directory where you have extracted the LIRC package and issue the following command in order to check which driver name you should use:

# ./configure --help

Next, configure the package for your system. Because some kernel modules are built together with LIRC, you will need to have the kernel development package (eg kernel-devel) for your running kernel installed. To configure LIRC issue the command:

# ./configure \
--prefix=/usr \
--with-x \
--with-transmitter \
--enable-sandboxed \
--with-moduledir=/lib/modules/$(uname -r)/extra/lirc \
--with-kerneldir=/path/to/kernel/headers \
--with-driver=DRIVER

Substitute DRIVER with the appropriate driver name and edit the path to your kernel headers/sources in the --with-kerneldir option. Note that the --with-kerneldir option can be safely omitted.
We use the --enable-sandboxed option, so that the installation script does not try to create any device nodes for LIRC. An UDEV rule, that we will create later on, will take care of this.

If the configuration script fails due to missing dependencies, make sure you have all the necessary development tools, libraries and kernel headers installed in your system. Just read carefully the on-screen error messages to see what is missing.

After this configuration is finished, you will see a message in your terminal about which LIRC module will be used. Take a note of the module name, as you will need it later on.

NOTE: On Fedora, I was not able to build the required lirc_gpio module. My IR receiver is attached on my KWorld TV tuner card, so this module was absolutely needed. In such a case you will probably want to read my post about the The Complete Fedora Kernel Headers.

Next, proceed to the LIRC compilation:

# make

and installation. This step is needed to be done as root:

# make install

If for any reason you want to uninstall all LIRC files, from within our current directory, issue the command:

# make uninstall

Special Note: Before you update your system kernel at some later time, you will need to uninstall LIRC. After the kernel upgrade, you will have to repeat the previous configuration, compilation and installation steps, so that the LIRC module is built for your new kernel.

The final step is to create an UDEV rule, so that the LIRC devices are created properly and with appropriate permissions.

Create a text file, named 10-lirc.rules, in the /etc/udev/rules.d/ directory and add the following to it:

KERNEL=="lirc[0-9]*", NAME=="lirc%n", GROUP=="disk", MODE=="0660"
KERNEL=="lirc0", SYMLINK=="lirc"

Finally, make sure you add the users you want to have access to the LIRC server to the group disk. Alternatively, if you want all the users to be able to access LIRC, then modify the MODE in the UDEV rule above from MODE=="0660" to MODE=="0666".

That’s it.

The LIRC Server Configuration

It seems that the LIRC daemon (lircd) does not load the default module (driver) automatically when it starts, so this module should be loaded manually.

To load the appropriate module and the LIRC server at boot time, all you have to do is to add the following lines to the /etc/rc.d/rc.local file. As root:

modprobe MODULE_NAME
lircd

Substitute MODULE_NAME with the module name you had taken a note of when configuring LIRC. For me, it would be lirc_gpio. The LIRC daemon, by default, uses the driver that was defined during the LIRC pre-compilation configuration.

The LIRC daemon also needs a configuration file (/etc/lircd.conf), which contains the proper addresses of your remote control’s buttons. The LIRC package contains some ready made remote configs, but I suggest you create your own. Read on…

The Remote Control Configuration file

In this section we will create a configuration file for our remote control by using an utility named irrecord, which was built together with the rest of the LIRC components. Since irrecord is a lircd client, the LIRC daemon needs to be running prior to using this tool.

So, as root, load the appropriate LIRC module and start the daemon:

# modprobe MODULE_NAME
# lircd

Now, change to a temporary directory and start irrecord:

# irrecord REMOTE_NAME

REMOTE_NAME is the remote control config file that will be created in the current directory. This will also be the name of your remote control that will be used within the created file. If you need to change it, do it by hand after this operation is finished. All you have to do is to follow the on-screen instructions. Generally, you will be asked to give names for the remote control buttons and to press each one of them.

After you are finished, copy the REMOTE_NAME file into /etc/, naming it lircd.conf. As root:

# cp REMOTE_NAME /etc/lircd.conf

Kill the running lircd instance and start the daemon again, so that it uses the new configuration:

# killall lircd
# lircd

Applications and LIRC Support

There are three kinds of applications:

1. Those which could and actually have been built with LIRC support. These act as LIRC clients when there is a running LIRC daemon.
2. Those which do support LIRC, but have not been compiled with the LIRC support enabled.
3. Those which do not support LIRC at all.

Generally, most multimedia applications, video and audio players, TV viewers and FM tuner applications, support LIRC. Also, many applications provide a method (separate utility or options) to send commands to a running instance of the application. This is particularly useful for programs that belong to the 2nd and 3rd categories. LIRC provides an utility, called irexec (LIRC client), which can be used to execute any command we want. This way, those applications can be controlled with the remote control through LIRC.

In order to use our remote control with a certain application, we have to create a configuration file that contains the mappings between the remote control’s buttons and the commands that will be executed when each button is pressed.

This file can be:

• named .lircrc and placed in the user’s home directory.
• named lircrc (without the period in front of the name) and placed in the /etc/ directory for system-wide configuration.

Information about this file’s format can be found in the relevant section of the LIRC Documentation.

Quick Tests

Here are some sample .lircrc files, so that you can test your installation. Make sure you have loaded the proper LIRC module and you have started the LIRC daemon. Save one of them as .lircrc and place it in your home directory.

Special Note: In the following sample config files, substitute the remote control name with the name you have used for your own remote control and the button name with a name of any of your own remote control’s buttons.

The first two samples will work with Xine and MPlayer respectively. These two players are usually built with LIRC support and, when launched, they act as LIRC clients.

Load Xine and press the specified button on your remote control. It should toggle between full-screen and window-mode.

# .lircrc - XINE sample test
begin
    prog = xine
    remote = KWTV878RF
    button = ZOOM
    config = ToggleFullscreen
    repeat = 0
end

Use the following config with MPlayer.

# .lircrc - MPLAYER sample test
begin
    prog = mplayer
    remote = KWTV878RF
    button = ZOOM
    config = vo_fullscreen
    repeat = 0
end

For applications that are not LIRC clients themselves, but which provide a method to send commands to a running instance of the application, the configuration is a bit different. The LIRC client irexec is used in these cases. When you press a button on the remote control, irexec executes the specified command. This requires that irexec is running. Start it as a user:

# irexec

Save the following as .lircrc and launch TVtime. The specified button on the remote control should toggle between full-screen and window-mode.

# .lircrc - TVtime sample test
begin
    prog = irexec
    remote = KWTV878RF
    button = ZOOM
    config = tvtime-command TOGGLE_FULLSCREEN
    repeat = 0
end

To start irexec and have it run in the background, start it as shown below:

# irexec &

To kill it:

# killall irexec

Some hints for more complicated configurations

Here are some hints for those of you who need complicated setups.

Toggle Buttons

You can create toggle buttons, for example you can set the same button to Play or Pause a video stream, by setting two config = command directives. They will be executed in turns. For example:

# Toggle button example
begin
    prog = irexec
    remote = remoteA
    button = buttonA
    config = play_command
    config = pause_command
    repeat = 0
end

Using this configuration, when buttonA is pressed for the first time, the play_command is executed. The second time buttonA is pressed, the pause_command is executed.

Modes

Let’s assume that you want to control many applications with your remote control. Some of them are LIRC clients and some are controlled through irexec. You can define various modes (groups of button to command mappings), one for each application.

First of all, read the .lircrc format page from the LIRC Documentation very carefully.

Keep in mind the following rule:

Each time you start a LIRC client and there is a mode within your configuration with a name equal to the application’s name, then this mode is automatically entered.

This means that if there is a mode named mplayer inside .lircrc and you start the mplayer program, which is a LIRC client, then the mplayer mode is automatically entered and only the button mappings that exist within this mode are functional.

Save the following as ~/.lircrc, substitute the remote control name and button names with your own, and start irexec:

# Example with modes
# MAIN BEGIN (irexec mode) - Application Selection Mode
# ---------------
begin irexec
    begin
        prog   = irexec
        remote = KWTV878RF
        button = 1
        # Start TVtime
        config = tvtime --window &
        # Enter tvtime mode
        mode = tvtime
    end
    begin
        prog   = irexec
        remote = KWTV878RF
        button = 2
        # Start Totem player and play DVD
        config = totem dvd:/ &
        # Enter totem mode
        mode = totem
    end
    begin
        prog   = irexec
        remote = KWTV878RF
        button = 3
        # Start Xine and play DVD
        config = xine dvd:/ --hide-gui &
        # Enter xine mode
        mode = xine
    end
end irexec
# ---------------
# MAIN END (irexec mode end)
# APP MODES BEGIN
# ---------------
# tvtime mode
begin tvtime
    begin
        prog = irexec
        button = POWER
        config = tvtime-command QUIT
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = irexec
        button = ZOOM
        config = tvtime-command TOGGLE_FULLSCREEN
    end
end tvtime
# totem mode
begin totem
    begin
        prog = irexec
        button = POWER
        config = totem --quit
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = irexec
        button = ZOOM
        config = totem --fullscreen
    end
end totem
# xine mode
begin xine
    begin
        prog = xine
        button = POWER
        config = Quit
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = xine
        button = ZOOM
        config = ToggleFullscreen
    end
end xine
# ---------------
# APP MODES END

I hope this example is clear enough. What is going on here is that when irexec (LIRC client) is executed, then the irexec mode is entered. When you press button "1", then TVtime is launched and the tvtime mode is entered. When you press the "POWER" button, TVtime quits and the irexec mode is entered etc. etc.

Furthermore, even if you do not start irexec, when you launch any LIRC enabled application, like Xine, MPlayer, Gnomeradio etc, then the appropriate mode will be entered automatically and you will be able to control this application remotely.

As you have probably already read in the LIRC Documentation, you can modularize this configuration by keeping each application mode in a separate file. Just don’t forget to include those separate files by adding a line like the following in ~/.lircrc. For example:

include ~/.lirc/tvtime.lircrc

Final Notes

Maybe you will need some time to familiarize yourself with the .lircrc format and probably more time reading the LIRC documentation, but you will be satisfied with the result.

For information about what commands are available for each application, please refer to the application’s documentation, project web site or support forum.

Also, if you need more information or support for LIRC, please ask your questions in relevant web forums. I have written all I know in this guide, so I am afraid I cannot help you more.

LIRC can do more things, for example it can be used to transmit IR signals or to connect to other LIRC servers accross the network. These have not been covered, not only because I consider such info as "too much" for a new user, but also because I have not been able to devote any time to experiment with these features.

This guide was written while using a Fedora 4 system.

Further Reading

You should read:

1. The LIRC Manual (Documentation)

Related Articles

• Kernel 2.6.17 and lirc_gpio driver
• The Complete Fedora Kernel Headers
• Creative PC-CAM Series webcams in linux
• Build a single native kernel module
• How to Disable IPv6 in Fedora and CentOS

1. Download the spca5xx driver source from here and extract the archive in a directory.
2. If you do not have the development tools installed, just do a:

   # yum groupinstall "Development Tools"

3. You also need to install the kernel sources:

   # yum install kernel-devel

4. Change to the directory where you had previously extracted the driver and run

   # make

5. The following installs the kernel module, so that the webcam is properly detected when plugged in. You will be prompted for the root’s password. So, run:

   # su -c "make install"

6. Plug the camera in.

This device functions as a webcam and a digital camera. However, the spca5xx driver supports it only as a webcam, meaning that it is registered as a video4linux device when plugged into the system. The retrieval of the pictures stored in the camera’s internal memory should be done using gphoto2 or gthumb-import. Actually, they do not work for my pc-cam 750. The cause of this may be gphoto2′s experimental support for the Creative PC-CAMs or a conflict with the spca5xx driver. Anyway, I care very little about it as this is not my primary digital camera, but I think I’ll try to investigate this issue when I have some time to spare.

I am writing all this just to say that if a gthumb-import dialog shows up as soon as you plug the camera in (this is controlled by GNOME’s Removable Drives and Media settings), just ignore it and hit Cancel. For me, if I try to import the stored pictures, it gives an error and additionaly the device is not registered as a V4L device, so I need to unplug and replug the device or unload and reload the spca5xx module.

Normally, your webcam’s device node should be /dev/videoX, where X is a number which depends on how many V4L devices are currently registered into the system.

Now, you can fire up gnomemeeting and start using the webcam. Alternatively, you may want to use spcaview to test the various driver settings. You can download this from the driver’s project page. Just compile it and use it like this:

# ./spcaview -d /dev/videoX

Check the included README file for further usage info.

Moreover, the spca5xx driver’s README file contains useful information about the module’s supported options. You can set these options in /etc/modprobe.conf, so that they are applied every time the module is loaded. For example, you could set:

options spca5xx GRed=217 GBlue=300 GGreen=224 gamma=4

If you ever need to uninstall the driver module, just change to the driver’s source directory and run:

# su -c "make uninstall"

Keep in mind that every time you upgrade your kernel, you will need to recompile and reinstall the spca5xx module. I may provide a spec file in a future update of this blog post, so that you can easily create an RPM package of this module.

This post will also be updated with notes about picture retrieval from the camera’s internal memory.

Have fun!

Related Articles

• Creative PC-CAM 750 on Fedora 10
• Kernel 2.6.17 and lirc_gpio driver
• Build a single native kernel module
• Logwatch and Dovecot 1.x series in FC5
• How to configure and use LIRC