OpenBSD, NetBSD and libusb-1.0

There is OpenBSD support in libusb.git. Since NetBSD and OpenBSD should have quite similar USB codes, I think that it should work under NetBSD as well.
Therefore I tried the following dirty patch to enable libusb-1.0 experimental support for NetBSD using the OpenBSD backend.
Take note FreeBSD has its own libusb-1.0 implementation which should be more mature than the OpenBSD backends of libusb-1.0 which is very recent.

diff --git a/configure.ac b/configure.ac
index ebbc107..71aad37 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,17 @@ case $host in
       AC_CHECK_HEADERS([poll.h])
       AC_DEFINE([POLL_NFDS_TYPE],[nfds_t],[type of second poll() argument])
       ;;
+*-netbsd*)
+       AC_DEFINE(OS_OPENBSD, 1, [OpenBSD backend])
+       AC_SUBST(OS_OPENBSD)
+       AC_MSG_RESULT([OpenBSD])
+       backend="openbsd"
+       threads="posix"
+       THREAD_CFLAGS="-pthread"
+       PC_LIBS_PRIVATE="-pthread"
+       AC_CHECK_HEADERS([poll.h])
+       AC_DEFINE([POLL_NFDS_TYPE],[nfds_t],[type of second poll() argument])
+       ;;
 *-mingw*)
       AC_MSG_RESULT([Windows])
       backend="windows"

And indeed it seems to work under NetBSD (tested with a NetBSD 5.1 VirtualBox VM under Mac OS X Lion)

localhost$ sudo ./listdevs
04d8:fa2e (bus 0, device 2)

I also tested libusb-pbatard's xusb example.

localhost$ sudo ./xusb -d 04d8:fa2e

Opening device...
speed: Unknown

Reading device descriptor:


Reading device descriptor:
           length: 18
     device class: 0
              S/N: 3
          VID:PID: 04D8:FA2E
        bcdDevice: 0001
  iMan:iProd:iSer: 1:2:3
         nb confs: 1

Reading configuration descriptors:
            nb interfaces: 1
             interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 2
  Class.SubClass.Protocol: 00.00.00
      endpoint[0].address: 01
          max packet size: 0020
         polling interval: 00
      endpoint[1].address: 81
          max packet size: 0020
         polling interval: 00
interface[0].altsetting[1]: num endpoints = 2
  Class.SubClass.Protocol: 00.00.00
      endpoint[0].address: 01
          max packet size: 0040
         polling interval: 00
      endpoint[1].address: 81
          max packet size: 0040
         polling interval: 00

Claiming interface 0...

Reading string descriptors:
  String (0x01): "Travis Robinson"
  String (0x02): "Benchmark Device"
  String (0x03): "LUSBW1"

Releasing interface 0...
Closing device...

Interesting discussions about Linux

http://fossforce.com/2011/08/top-10-things-linux-users-dont-understand/

The post itself is not that interesting and kind of dumb. But the comments sections are much more interesting. The best comment is from "linuxlover" on August 12th, 2011 at 11:05 am.

I use both Windows and Linux and kind of neutral. Windows has many problems. Linux has many problems as well. Linux has many advantages. Windows has many advantages as well.

********* Quote "linuxlover" *****************
Advantages of Linux
1. App bugs will get fixed when a new student takes over from the one that graduated and got a job.
2. The packaging chaos will get fixed, since the Darwinian process works (only needs a few million years).
3. The desktop chaos will get fixed for the same reason.
4. Linux distros will stop competing with each-other and start focusing on Microsoft.
5. Ubuntu’s 80,000 open bugs will make them releasing when ready instead of every 6 months.
6. Instead of dozens of half-finished programs for a given application, there will be 1-2 really excellent ones.
7. Unity may get modified to be effective for monitors over 800 pixels.
8. Compiz may get fixed for high-speed window updates.
9. A serious standards body will develop and enforce sensible standards (packaging, desktop, libraries, binary API, GUI API).
10. If you are having problems, you can choose from hundreds of distros that will have different problems.

I actually use and enjoy Linux, but let’s face the problems honestly.
**********************************************

Arch Linux Gnome 3 with Nvidia Driver Problem Workaround

I have some problems with Gnome 3 (Gnome Shell) with the Nvidia 3. The main thing is that sometimes texts will get corrupted when you scroll down a website under Firefox. It can take some efforts to to click some links in Firefox for some websites (like the links below any LinuxToday articles). The first link is there, but when you scroll down and try to click it, it disappeas and the text below that becomes corrupted. Most likely it is an Nvidia driver problem but I have updated to the latest version from Arch. And I do not have such a problem under Ubuntu 11.04 with Unity.

In the end the workaround provided in Arch Forum works, press ALT+F2 and type "r" and then everything is fine.

Quote from that Arch Forum article:
"Have you tried Alt+F2 to open a command prompt then entering r ? I think I get the same thing you get when I come out of suspend and r at the command prompt resets the Gnome Shell and fixes the problem. I'm also using the closed source Nvidia driver."

Notes added on 17 July 2011: it still does not work well, still has the garbled text problem. So I just switched to the Fall Back mode by default.

Notes added on 21 July 2011: it seems that the latest NVidia driver improved on the issue (275.19-1 version) but I still see text corruption when scrolling with a mouse under Firefox and Gnome 3.

Gnome 3 and Gnome Shell First Impression

I just updated my Arch Linux installation and it has Gnome 3 by default. I followed the Arch Wiki about Gnome 3 for the installation and it went smooth.

As for the first impression, it is at least much better than Ubuntu Unity interface. For one thing, it does not have the annoying Global Menu. However, I still prefer the old Gnome 2 interface. Anyway, the new interface is at least tolerable, not like Ubuntu Unity. I think I can get used to it soon even though I still miss the Gnome Panel Applets.

I tend to think Unity is one way for Ubuntu to differentiate it from other Linux distros, let's wait and see if that really pans out well for Ubuntu or not.

Notes added on 17 July 2011: however, the problem is with the Nvidia driver. Gnome 3 just does not work well with the Nvidia driver right now under Arch Linux. So I have to switch back to the Fall Back mode.

Ubuntu 11.04 -- Unity Interface is not usable

I have just updated my Ubuntu 10.10 installation to 11.04. To be honest, I do not like the new Unity interface. I would say the old Gnome interface is much easier to use. Windows 7 is also way better. I might be able to get used to it in the future, but for now I will go back to the classic desktop and wait for Ubuntu to fix the Unity interface.

Major problems:
1) The launcher is basically useless, the autohide works too well so that it does not come out when I need it from time to time.
2) Software center is getting better but I still prefer Synaptic. Anyway, Synaptic is still there.
3) There is no "Show Desktop" icon. This is not that bad but still I prefer to have it.
4) I miss the gnome-panel applets.
5) I do not like the global menu. This is the most annoying feature. I do not have a Mac and I am not used to this "feature".
6) I do not quite like Dash, I prefer the old Gnome menu system where I can access the applications with less mouse clicks.

Anything I like about Unity? Nothing!

I think Unity will be like KDE 4 when it was first launched (I still do not install KDE now) and it will take some time for Ubuntu to fix it. Maybe Ubuntu Unity can get usable next year, say 12.04.

Anyway, there seems to be a good guide for those who want to use Unity.
http://castrojo.tumblr.com/post/4795149014/the-power-users-guide-to-unity

Edits on 1 May 2011:
After disable the global menu and fix the launcher to never hide and add some common application to the Launcher, the Unity Interface is at least tolerable again.

Still need to find a way to move the maximize/minize/close buttons to the right when application is maximized. When it is not maximized, the buttons are on the right which is fine, but they move to the left when the application is maximized. This is quite annoying.

Notes on 17 July 2011:
Enabled the global menu for a while and still does not like it very much, but it can be tolerable now. And I keep the maximize/minimize/close button to the default left side now.

So Unity interface is usable now, but still not that good.

OpenUSB is alive again

After a long gap, Michael Lewis just announced the release
of OpenUSB 1.1.1.

Website: http://sourceforge.net/projects/openusb.

Highlights of the release:
1) Removed the HAL/DBUS dependency for hotplug events.
2) Improved kernel version checking for the bulk continuation flag.
3) Improved support for zero byte transfers
4) Changed the maximum control transfer size to 4096

According to Michale, these changes are primarily in response to making OpenUSB compatible with the latest distributions.

Compared to libusb-1.0, OpenUSB is not used by many projects. However, it does have two advantages compated to libusb-1.0. It also claims to have better multi-threading support.
1) Hotplug support
2) Solaris support

libusb-1.0 is more widely used and the Windows backend will bring even more users for libusb-1.0. However, it is also good to see that OpenUSB is still alive. If Windows support for OpenUSB is done within a reasonable timeframe, then it would be even better.

Python and USB HID Device

(This is my post to pyusb mailing list on 27-April-2011)

Just a summary for the situation.

Firstly you may want to see if you really want to use
a generic HID device, in most cases, you can use
a custom device and then use libusb0.sys or winusb.sys
as the driver under Windows and then use pyusb with it.

Using a custom device will also make it possible to use
pyusb under Mac OS X. Recent Mac OS X makes it
very difficult (or impossible) to detach the kernel HID driver.
In that case, it is not possible to use libusb (0.1 or 1.0)
and thus pyusb with the device.

So if you really want to use pyusb and care about
cross-platfrom, then you should forget about generic
HID device and use a custom device instead.

If you really need to use HID device, there are a few
options.

1) If you only cares about Linux, then you can use
pyusb with no issues. libusb under Linux can detach
the kernel HID driver.

2) If you only care about Windows, you may want
to look at pywinusb.
http://code.google.com/p/pywinusb/

3) If you really want to use pyusb under Windows with the
HID device, you can use libusb-win32 filter driver for
that particular HID device. Please use the latest
libusb-win32 for this purpose. And take note this is
not a recommended solution.

4) If you want to have cross-platform support for the
HID device, then you need to look at HIDAPI and
use the python binding for it. Take note the python
binding for HIDAPI is not mature yet.
http://libusb.6.n5.nabble.com/Opinion-HID-and-Windows-back-end-td3716872.html
http://comments.gmane.org/gmane.comp.python.pyusb.user/749

5) Another option under Windows is to use the HID branch
of the libusb-pbatard git repo or older version of libusb-pbatard
(up to pbr332). This is not recommended as the official stand
of libusb-1.0 admin is not to support HID native backend under
Windows.

libftdi and OpenOCD binary download

libftdi-0.18 and libftdi-1.0 binaries and OpenOCD git binaries download
http://code.google.com/p/picusb/downloads/list

I have uploaded some Windows (32bit and 64bit) binary of libftdi and OpenOCD to my Google Code picusb page. Most of them are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting them to be built under Windows, you may want to try out the binaries I built.

Ubuntu 10.10 Installed

Ubuntu 10.10 installation on my Acer desktop is rather smooth. I was using upgrade install for the 10.04 LTS release. Since there is an empty partition this time (giving up FreeBSD), I am using fresh install this time. Firstly I downloaded the ISO, installed it to an 8GB USB Flash Disk, boot the USB drive, played a bit with the live session. Then I installed it to the empty partition. It was a very smooth process.

Still the open source Nvidia driver is quite flaky (even the font it not clear) for my old shared Nvidia graphics card, so I opted to install the proprietary driver which is much more usable. After switching to a normal theme (to be able to close the window from the upper-right corner) and disabling the visual effect and installing a bunch of software packages, I am in business. Thanks to the fast broadband (16Mbps) and fast Ubuntu Singapore mirror, the whole process is actually not long.

As for the first impression, I have not yet noticed any real difference. It is just quite smooth.

MinGW Win32 installation to build libusb-1.0 Windows Backend

libusb-1.0 Windows backend currently supports Cygwin, MinGW and MinGW-w64, MSVC and WDK as the building tool. Cygwin, MSVC and WDK are more straightforward to install under Windows. But MinGW and MinGW-w64 are less straightforward.

One way to solve this issue is to use cross-compile under Linux. Leading Linux distros have MinGW and even MinGW-w64 packages. And the auto-tools (automake, autoconf, libtool) are normally installed under Linux. For MinGW-w64 build, one think to take note is that you probably need to update the libtool to 2.2.8 and later. Ubuntu 10.04 still ships an older version of libtool which does not recognize 64bit library properly.

Native build with MinGW/MSys from MinGW.org is really not that difficult once you have the base system and auto-tools installed. Pete Batard has a blog entry talking about the setup.
http://pete-tech.blogspot.com/2010/07/installing-mingw-w32-on-windows-system.html

I just checked again and now it seems MinGW people has recognized the problem and come up with a new automatic installer for the MinGW/Msys base system installation. The name is mingw-get. It is currently in alpha but rather usable. I just used it to set up a new MinGW/MSys base system under Windows 7 32bit.

mingw-get can be downloaded from MinGW Sourceforge site.
http://sourceforge.net/projects/mingw/files/

Once you have the base system, you need to install auto-tools for MinGW (not the MSys version). The auto-tools may need some MSys dependency packages as well (eg: perl, crypt, etc). After that, it is quite simple to build libusb-1.0 Windows backend.

As for MinGW-w64 64bit build, it is similar. You can download the 32bit MSys base system and MinGW-w64 64bit Windows binary snapshots from its Sourceforge website.
http://sourceforge.net/projects/mingw-w64/files/

Alternatively, you can get 64bit binary from the following website (only for 64bit Windows).
http://www.drangon.org/mingw/

After that, you still need to get 32bit auto-tools installed. I recommend you to use the ones from MinGW.org and not the ones from MinGW-w64 sites as I have encountered problems with them.

If you are more adventurous, you can try the multilib option to build 32bit and 64bit using the same toolchain. Pete has a blog entry for this. I have not tried this and will probably not try this myself.
http://pete-tech.blogspot.com/2010/07/compiling-mingw-w64-with-multilib-on.html

There is an existing package WPG System64 which include multilib based MinGW-w64 and all the tools (and more) to build libusb-1.0 Windows backend. However, we found out that the MinGW-w64 compiler included is a bit outdated that the output is not compatible with the current MinGW-w64 compile. So it is not recommended any more.

Upgrade to Ubuntu 10.04 LTS 64bit

Today I upgraded one of my desktop partition from Ubuntu 9.10 64bit to 10.04 64bit. The upgrade process is relatively smooth. Download from local Singapore mirror is quite fast. Installation is not that fast (more than 2 hours for 2700 packages, no KDE, just Gnome). But all in all the process is quite ok.

Just a minor glitch -- I was not using Network Manager but wicd. Prior to the upgrade, I uninstalled wicd and did not install Network Manager. Therefore, after reboot, I did not have the wired network. Still two commands away, I had the network up again (sudo ifconfig eth0 192.168.1.110; sudo route add default gw 192.168.1.1). Then I installed Network Manager and next reboot my wired network is automatically up.

BTW, the mirror seems to have problem with one qt4 package right now (libqt4-xmlpatterns). So I had to uninstall it before the upgrade.

The default theme has the window buttons in the left side. I still prefer them to be on the right side. So I change the theme back to Human.

Ubuntu 9.10 x64 for the Asus K40ID Notebook

Today I installed Ubuntu 9.10 64bit for the new Asus K40ID notebook. It was relatively a smooth process with only one problem related to X.

Firstly I shrunk the Windows 7 data partition (Asus keeps OS in C and others in D, with another hidden Fat32 recovery partition) with Windows 7's built-in disk manager. It was a nice add-on since Vista. Then I boot the install CD (cum Live CD), check everything is fine (including X and wireless). Then I partitioned the empty disk (swap, Linux1 and Linux2). Linux 2 is empty now since Ubuntu 10.04 LTS is on the way. Then I installed Ubuntu 9.10 x64 to the Linux1 partition. Everything is fine. However, after reboot, the screen just flickered and could not go into X. So I had to boot into recovery mode, used the wire connection, installed the Nvidia proprietary driver.

After that, I have no issues any more. X is fine. Wireless is fine. The Fn key also seems to function well. Sound is fine.

picusb Google code page updated

http://code.google.com/p/picusb/

I have created this page quite some time ago. But I did not put anything inside. Now I will start to put some contents inside, mainly related to some open source codes related to USB PIC MCUs.

Some files for download:
http://code.google.com/p/picusb/downloads/list

Quirky and dpup beta first impression

Quirky Linux (http://bkhome.org/blog/?viewCat=Quirky) and Debian Lenny based Puppy dpup (http://www.dpup.org) seem to be actively developed and based on the Puppy Linux philosophy. Both are based on Woof but are based on T2 and Debian Lenny respectively. There are other Woof Puppy based on Slackware and Ubuntu but none of them seems to be as mature as Quirky and dpup.

I tried Quirky 0.02 and now I am running Quirky 0.03. One of the issue is that the default selected Xorg nv driver is not working for my Nvidia 620i/Geforce 7050 integrated graphics and I have to use Xorg vesa driver. Moreover, I am not able to install the Nvidia proprietary driver as it complains that it is not able to load the kernel driver. But it is not too bad, I am still able to reach full resolution of 1280x1024 (16bpp now) on my LG L1750SQ LCD monitor whereas distros like Ubuntu can not reach this resolution without using the Nvidia proprietary driver. It is also quite fast. I feel it is faster than Puppy 4.3.1.

From what I see, dpup is less matured even though it is supposed to be one of the leading V5.x Puppy. I feel it is slower than Quirky.

Nice Chinese Support Package for Puppy Linux

This website (Home of Chinese Puppy Linux Developer) has a nice Chinese support package for Puppy Linux. Maybe it is more meant for the users in mainland China since it makes all the menu items in Chinese.
http://puppy.cnbits.com/

Veket and Puppy Linux Installed

Recently I was reading some positive review of veket Linux in some Chinese forums. veket Linux is mainly distributed P2P network and supported by the forum. It is based on Puppy Linux. Today I tried veket 2.39 and 3.11. veket 2.39 is more stable and included the development tools. V3.11 seems to be more similar to Puppy Linux 4.3.1 which I also installed.

Puppy Linux seems to be a good distribution for Live CD and Live USB and I tried both option before installing them to the hard disk. I use the frugal installation option (for both veket and Puppy) so the installation option is really simple. Adding them to grub (under Ubuntu 9.10) is also very easy.

veket has good Chinese support. I copied the fonts into Puppy so that I can browse Chinese website from Puppy.

For my Acer desktop PC, both veket 2.39 and Puppy 4.3.1 run fine and quite fast.

Ubuntu 9.10 64bit Installed

I have not really tried to use 64bit Linux with the exception of an short and aborted experiment with Ubuntu 6.06 64bit. Now that 64bit OS becomes more popular and I think I will give it a try. Ubuntu 9.10 64bit is the nature choice since I am at home with Ubuntu after using it since 5.04.

The fresh installation (using ext4) was a very smooth process. The installation cd is also a live cd. So I could try it out before real installation. The live cd could not run at full resolution with my Nvidia card but this was expected. With the proprietary driver from Nvidia, the display worked fine.

For the fresh boot, X did not work, complaining the module nvidia did not exist. That was not a problem. I boot with the vesa server and then install the proprietary driver and reboot, X worked fine again.

Flash player is no longer a problem with this latest Ubuntu 64bit OS. So that is a good sign.

Media (mp3, xvid coded avi, rmvb, etc) playing with Totem and VLC is in general fine as well even though some old RMVB file are still a bit problematic.

Firefox occasionally still crashed and that is again expected by me. It is the single most often used and most often crashed program for me under Linux.

I have some programs (gputils, sdcc, openocd, pk2cmd and some other libusb related programs like pyusb and lpcusb) and recompiling them is in general quite simple. I could not find old glib-1.2 related packages in the repository but I will try later (Edit: download glib-1.2 and gtk-1.2 related packages from Ubuntu 9.04 x86_64 and they seem to work fine for Ubuntu 9.10 x86_64).

So in general, Ubuntu 9.10 64bit seems to work fine for me now.

Ubuntu 9.04 to 9.10 upgrade is smooth

Yesterday evening I tried to upgrade Ubuntu 9.04 to 9.10. It was a very smooth process, 1700+ packages were upgraded, some obsolete packages were removed, and after a reboot, Ubuntu 9.10 was installed without an issue. It runs smooth and all the common applications run well (Firefox, media players, OpenOffice, wine, common development tools, Samba client, etc). iBus is now included and I like it better than SCIM for Chinese input.

Restore Default Gnome Panels In Ubuntu

Yesterday I was trying Ubuntu Netbook Remix under Ubuntu 9.04 for my desktop. It somehow crashed quite often and not usable at all. I used the desktop-switcher (which comes with the ubuntu-netbook-remix packages) to set it back to the normal Ubuntu Gnome Desktop. It did not work well. The Gnome panel was in a strange state. Then I uninstalled Ubuntu Netbook Remix related packages. Things became worse. Normal gnome session became a empty desktop with only the background image. I had to go back to the termail (CTRL-ALT-F1), restart gdm and use LXDE instead.

Google came to rescue again. The following website has the instructions on how to restore the default gnome panel and it works for me. After three commands, I am back in business.
http://www.watchingthenet.com/restore-panels-in-ubuntu-back-to-their-default-settings.html

gconftool --recursive-unset /apps/panel
rm -rf ~/.gconf/apps/panel
pkill gnome-panel

Piklab Wiki Page USB Port Permission Archive

The following content was originally from Piklab Wiki page. But Sourceforge has retired the Wiki.
The URL was: http://piklab.wiki.sourceforge.net/USB+Port+Problems
The following is the text version.

You need to have read and write access to the port (serial, parallel or USB).
Some distributions do not grant read/write access to regular users by default.
Some additional information written by Linus Walleij regarding interaction
between "libusb" and "udev"/"hotplug" is provided here.
http://piklab.sf.net/files/libusb_udev_hotplug.txt


For distributions using "hotplug" (Fedora Core 4, Ubuntu 5,...)
The following procedure may be used, to be able to connect to the ICD2/Pickit programmers
as a regular user on those distributions, using hotplug [thanks to Xiaofan Chen]:

* Add the following to /etc/hotplug/usb.usermap:

pickit 0x0003 0x04d8 0x0032 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
pickit2 0x0003 0x04d8 0x0033 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
icd2 0x0003 0x04d8 0x8000 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
icd21 0x0003 0x04d8 0x8001 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000

* Add hotplug scripts "pickit", "pickit2", "icd2", "icd21" in /etc/hotplug:

#!/bin/bash
if [ "${ACTION}" = "add" ] && [ -f "${DEVICE}" ]
then
echo "changing ${DEVICE}" >> /tmp/debug-hotplug
chown root "${DEVICE}"
chgrp microchip "${DEVICE}"
chmod 660 "${DEVICE}"
fi

* Create group "microchip" and add your username to this group.


For distributions using "udev" (Debian Sid, Ubuntu 6,7,8,...)
The following procedure may be used to be able to connect to the ICD2/Pickit programmers
as a regular user on distributions using udev [thanks to David Williams]:

* Create file /etc/udev/rules.d/026_microchip.rules:

#PICKit
SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="0032", MODE="0660", GROUP="microchip"
#PICKit2
SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="0033", MODE="0660", GROUP="microchip"
#ICD2
SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="8000", MODE="0660", GROUP="microchip"
#ICD21
SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="8001", MODE="0660", GROUP="microchip"

* Create a group named "microchip" and add your username to this group:

sudo addgroup microchip
(Note: for Arch Linux, it is "groupadd".)
sudo gpasswd -a your_user_name microchip


Similarly for Suse/OpenSuse and Arch Linux and newer version of Ubuntu
http://usbpicprog.org/?page_id=13
[Thanks to Robert Currie]

#PICKit 1
ATTR{idVendor}=="04d8", ATTR{idProduct}=="0032", OWNER:="root", GROUP:="microchip",MODE:="0660"
#PICKit 2
ATTR{idVendor}=="04d8", ATTR{idProduct}=="0033", OWNER:="root", GROUP:="microchip",MODE:="0660"
#ICD2
ATTR{idVendor}=="04d8", ATTR{idProduct}=="8000", OWNER:="root", GROUP:="microchip",MODE:="0660"
#ICD21
ATTR{idVendor}=="04d8", ATTR{idProduct}=="8001", OWNER:="root", GROUP:="microchip",MODE:="0660"
#PICDEM FS USB Bootloader
ATTR{idVendor}=="04d8", ATTR{idProduct}=="000b", OWNER:="root", GROUP:="microchip",MODE:="0660"


For distributions using "PolicyKit" (Fedora 9,10,...)
The following procedure may be used to be able to connect to the ICD2/Pickit programmers
as a regular user on distributions using udev [thanks to Xiaofan Chen]:

* Create file /usr/share/hal/fdi/policy/10osvendor/10-microchip.fdi

http://groups.google.com/group/pickit-devel/browse_thread/thread/86c67b83202815cf?pli=1

* Create a group named "microchip" and add your username to this group.

For distributions using "udev" and PAM (Fedora Core 5/6,...)
The following procedure may be used to be able to connect to the ICD2/Pickit programmers
as a regular user on distribution using udev [thanks to Linus Walleij]:

* Create file /etc/udev/rules.d/026-microchip.rules:

#PICKit
SUBSYSTEM=="usb_device", ACTION=="add", SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="0032", SYMLINK+="pickit1-%k"
#PICKit2
SUBSYSTEM=="usb_device", ACTION=="add", SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="0033", SYMLINK+="pickit2-%k"
#ICD2
SUBSYSTEM=="usb_device", ACTION=="add", SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="8000", SYMLINK+="icd2-%k"
#ICD21
SUBSYSTEM=="usb_device", ACTION=="add", SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="8001", SYMLINK+="icd2-%k"

* Create file /etc/security/console.perms.d/pickit2.perms (and similar files for the other devices):

=/dev/pickit2*
0600 0600 root