PowerShot S2 IS in Linux

  • user warning: Table 'cache' is marked as crashed and should be repaired query: SELECT data, created, headers, expire FROM cache WHERE cid = 'filter:1:7b52757ae8275165d78d0a5f8e697ed1' in /home/dowdle/public_html/montanalinux/includes/database.mysql.inc on line 121.
  • user warning: Table 'cache' is marked as crashed and should be repaired query: UPDATE cache SET data = '<p>I have a Canon S2 IS camera. It is a mid-level camera which I am happy with. In my resent family migration to full throttle Linux this past month; I have been the only one to have fired up XP one time to access pictures from this camera. Back in Fedora Core 6 and I think even up to resent kernel updates, I was able to mount my camera. The PowerShot S2 is not a mass storage device so you can\'t just mount it to get the pictures. Instead it uses the Picture Transfer Protocol (PTP).</p>\n<p>Evidently hotplug has been pretty much replaced by udev in modern Linux distros now. Up to now I only heard the term udev but had no idea old or new it was nor what it did. Once upon a time Linux used a static list of devices under /dev. Today everyone is connecting and disconnecting devices with USB, Firewire, and Bluetooth and static /dev alone just doesn\'t cut it anymore. Dynamic udev to the rescue!</p>\n<p>Wikipedia excerpt:<br />\n<blockquote>udev is the device manager for the Linux 2.6 kernel series. Its primary function is managing device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load.</p>\n<p>The latest versions of udev depends on the latest version of the uevent interface of the Linux kernel which has been updated or introduced with Linux kernel 2.6.13. A system using a new version of udev will not boot with kernels older than 2.6.13 unless udev is disabled with bootparam noudev and a traditional /dev directory is used for device access.</p></blockquote>\n<p>My problem wasn\'t this wonderful idea of udev, but with the rules file that sets my camera up to begin with. It appears to recognize it and mount it just fine but as a normal user trying to browse the images, it would freak out saying it didn\'t have control of the USB device.</p>\n<p>With the help of my friend \'psymin\', he suggested I look at permissions and testing as root. Low and behold, it was fully browseable. Next I confirmed testing by changing ownership of the USB id as my normal user. This was obviously the only problem I was having.</p>\n<p>Before actually figuring out which rule was being enforced I had come across a custom fix (<a href=\"http://www.hyperborea.org/journal/archives/2007/11/14/digikam-permissions/\" target=\"_digikam\">When digiKam Failed to Connect</a>) that created a new rule. I only modified the group as I have a shared group already:</p>\n<pre>/usr/lib/libgphoto2/print-camera-list udev-rules-0.98 group camera mode 0660 \n&gt; /etc/udev/rules.d/90-libgphoto2.rules</pre><p> A small snip of the file:<br />\n<blockquote># udev rules file for libgphoto2 devices (udev &gt;= 0.98)<br />\n#<br />\nSUBSYSTEM!=\"usb*\", GOTO=\"libgphoto2_rules_end\"<br />\nACTION!=\"add\", GOTO=\"libgphoto2_rules_end\"</p>\n<p>ATTRS{idVendor}==\"0553\", ATTRS{idProduct}==\"0202\", MODE=\"0660\", GROUP=\"camera\"<br />\nATTRS{idVendor}==\"06bd\", ATTRS{idProduct}==\"0403\", MODE=\"0660\", GROUP=\"camera\"<br />\n...<br />\n<b>ATTRS{idVendor}==\"04a9\", ATTRS{idProduct}==\"30f0\", MODE=\"0660\", GROUP=\"camera\"</b></p></blockquote>\n<p>Thank you Kelson!</p>\n<p>So if the system previously mounted without this new rule, why don\'t I just fix it? Because when they do any updates my changes would be wiped out in the event the update didn\'t address the permission issue. This new custom rule worked without a hitch and won\'t be overwritten so when they do fix it I won\'t know any better.</p>\n<p>Update: My wife discovered she wasn\'t able to print at all yesterday. After I wrestled with it for about an hour I decided to put some logic to it. What was the last think I did since printing last worked? So I renamed the new rule so it wasn\'t .rules and restart udev-post (assuming that is the service), reset the printer and viola, it started working again. So I just trimmed out the above custom rule including only my camera in the bold and all is well.</p>\n<br class=\"clear\" />', created = 1410836192, expire = 1410922592, headers = '' WHERE cid = 'filter:1:7b52757ae8275165d78d0a5f8e697ed1' in /home/dowdle/public_html/montanalinux/includes/database.mysql.inc on line 121.
| | |

I have a Canon S2 IS camera. It is a mid-level camera which I am happy with. In my resent family migration to full throttle Linux this past month; I have been the only one to have fired up XP one time to access pictures from this camera. Back in Fedora Core 6 and I think even up to resent kernel updates, I was able to mount my camera. The PowerShot S2 is not a mass storage device so you can't just mount it to get the pictures. Instead it uses the Picture Transfer Protocol (PTP).

Evidently hotplug has been pretty much replaced by udev in modern Linux distros now. Up to now I only heard the term udev but had no idea old or new it was nor what it did. Once upon a time Linux used a static list of devices under /dev. Today everyone is connecting and disconnecting devices with USB, Firewire, and Bluetooth and static /dev alone just doesn't cut it anymore. Dynamic udev to the rescue!

Wikipedia excerpt:

udev is the device manager for the Linux 2.6 kernel series. Its primary function is managing device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load.

The latest versions of udev depends on the latest version of the uevent interface of the Linux kernel which has been updated or introduced with Linux kernel 2.6.13. A system using a new version of udev will not boot with kernels older than 2.6.13 unless udev is disabled with bootparam noudev and a traditional /dev directory is used for device access.

My problem wasn't this wonderful idea of udev, but with the rules file that sets my camera up to begin with. It appears to recognize it and mount it just fine but as a normal user trying to browse the images, it would freak out saying it didn't have control of the USB device.

With the help of my friend 'psymin', he suggested I look at permissions and testing as root. Low and behold, it was fully browseable. Next I confirmed testing by changing ownership of the USB id as my normal user. This was obviously the only problem I was having.

Before actually figuring out which rule was being enforced I had come across a custom fix (When digiKam Failed to Connect) that created a new rule. I only modified the group as I have a shared group already:

/usr/lib/libgphoto2/print-camera-list udev-rules-0.98 group camera mode 0660 
> /etc/udev/rules.d/90-libgphoto2.rules

A small snip of the file:

# udev rules file for libgphoto2 devices (udev >= 0.98)
#
SUBSYSTEM!="usb*", GOTO="libgphoto2_rules_end"
ACTION!="add", GOTO="libgphoto2_rules_end"

ATTRS{idVendor}=="0553", ATTRS{idProduct}=="0202", MODE="0660", GROUP="camera"
ATTRS{idVendor}=="06bd", ATTRS{idProduct}=="0403", MODE="0660", GROUP="camera"
...
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="30f0", MODE="0660", GROUP="camera"

Thank you Kelson!

So if the system previously mounted without this new rule, why don't I just fix it? Because when they do any updates my changes would be wiped out in the event the update didn't address the permission issue. This new custom rule worked without a hitch and won't be overwritten so when they do fix it I won't know any better.

Update: My wife discovered she wasn't able to print at all yesterday. After I wrestled with it for about an hour I decided to put some logic to it. What was the last think I did since printing last worked? So I renamed the new rule so it wasn't .rules and restart udev-post (assuming that is the service), reset the printer and viola, it started working again. So I just trimmed out the above custom rule including only my camera in the bold and all is well.