linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <linux-hotplug-mail@asthe.com>
To: linux-hotplug@vger.kernel.org
Subject: what I did to hotplug Phillips/Logitech webcams
Date: Fri, 22 Feb 2002 20:51:48 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-101441134908913@msgid-missing> (raw)

Hello,

I'd like to describe what I had to do to hotplug-2001_01_16-2.noarch.rpm
in order to be able to hotplug a Phillips/Logitech 730K USB camera.

Some of my mods may be a result of not groking hotplug.  Some could
be because hotplug is a work in progress.  In other words, it is
a bug or a feature?  :-)

=-
Here is what we wanted to do:

   Plug on a Logitech QuickCam 3000 Pro (USB webcam that is a Phillips 730K)
   and have the right magic occur with the pwc and pwcx-i386 modules.

   There are two other items that are needed:

   1) We need the modprobe to be:

       modprobe pwc size=vga power_save=1 fps\x15 \
                compression=0 mbufs=2 leds%0,750

      not just 'modprobe pwc'.

   2) After pwc is loaded, we need to load the pwcx-i386 module which
      is a binary-only module :-( that requires something like:

        /sbin/insmod --force /etc/hotplug/usb/pwcx-i386.o >/dev/null 2>&1

   We wanted the webcam modules loaded at boot time if the camera was
   plugged in.  We also wanted them to be loaded if hotplug was restarted.

=-
Our hack/solution:

    We started with the 2002_01_14-1 hotplug code, installed from
    the hotplug-2002_01_14-1.noarch.rpm file.

    We added the following line to /etc/hotplug/usb.usermap:

        pwc 0x0003 0x046d 0x08b0 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 \
            0x00 0x00000000

    We created the following executable file:

        /etc/hotplug/usb/pwc

    containing the following lines:

        #!/bin/bash
        modprobe pwc size=vga power_save=1 fps\x15 compression=0 mbufs=2 \
                 leds%0,750
        /sbin/insmod --force /etc/hotplug/usb/pwcx-i386.o >/dev/null 2>&1


In order to get that to work, we had to make the following patch to
hotplug.functions:

*** hotplug.functions.init      Fri Feb 22 11:09:10 2002
--- hotplug.functions   Fri Feb 22 11:07:53 2002
***************
*** 10,16 ****
  # $Id: hotplug.functions,v 1.8 2002/01/07 18:16:46 dbrownell Exp $
  #

! # DEBUG=yes export DEBUG
  PATH=/bin:/sbin:/usr/sbin:/usr/bin

  KERNEL=`uname -r`
--- 10,16 ----
  # $Id: hotplug.functions,v 1.8 2002/01/07 18:16:46 dbrownell Exp $
  #

! # DEBUG=yes; export DEBUG
  PATH=/bin:/sbin:/usr/sbin:/usr/bin

  KERNEL=`uname -r`
***************
*** 132,151 ****

      # maybe driver modules need loading
      # either kernel or user mode drivers may need to be set up
      for MODULE in $DRIVERS
      do
        if ! lsmod | grep -q "^$MODULE "; then
!           if grep -q "^$MODULE\$" /etc/hotplug/blacklist \
                    >/dev/null 2>&1; then
                debug_mesg "... blacklisted module:  $MODULE"
            # user mode drivers will ONLY have a setup script,
            # so it's not an error if a module doesn't exist
            elif $MODPROBE -n $MODULE >/dev/null 2>&1 &&
                    ! $MODPROBE $MODULE >/dev/null 2>&1 ; then
                mesg "... can't load module $MODULE"
-           elif [ -x /etc/hotplug/$TYPE/$MODULE ]; then
-               debug_mesg Module setup $MODULE for $DESCRIPTION
-               /etc/hotplug/$TYPE/$MODULE
            else
                mesg "missing kernel or user mode driver $MODULE "
            fi
--- 132,155 ----

      # maybe driver modules need loading
      # either kernel or user mode drivers may need to be set up
+     if [ -n "$HOTPLUG_DIR" ]; then
+       HOTPLUG_DIR=/etc/hotplug
+       export HOTPLUG_DIR
+     fi
      for MODULE in $DRIVERS
      do
        if ! lsmod | grep -q "^$MODULE "; then
!           if grep -q "^$MODULE\$" $HOTPLUG_DIR/blacklist \
                    >/dev/null 2>&1; then
                debug_mesg "... blacklisted module:  $MODULE"
+           elif [ -x $HOTPLUG_DIR/$TYPE/$MODULE ]; then
+               debug_mesg Module setup $MODULE for $DESCRIPTION
+               $HOTPLUG_DIR/$TYPE/$MODULE
            # user mode drivers will ONLY have a setup script,
            # so it's not an error if a module doesn't exist
            elif $MODPROBE -n $MODULE >/dev/null 2>&1 &&
                    ! $MODPROBE $MODULE >/dev/null 2>&1 ; then
                mesg "... can't load module $MODULE"
            else
                mesg "missing kernel or user mode driver $MODULE "
            fi

   A few notes on the above patch to hotplug.functions:

        1) The ; is missing from the commented out DEBUG line.
           We made use of debugging while trying to figure things out.

        2) We found cases where $HOTPLUG_DIR was not defined during
           execution of the load_drivers() shell function.  While
           hotplug.functions may define HOTPLUG_DIR, it does not
           export it.  During testing we found it easier just to
           check for a missing/empty HOTPLUG_DIR and set it inside
           the load_drivers() shell function.

        3) We fixed a case where /etc/hotplug was still hard coded.

        4) The most critical patch:

           We needed $HOTPLUG_DIR/$TYPE/$MODULE checked before
           a modprobe was done.  The way it was written, a modprobe
           of pwc would always succeed and our script would never
           be executed.  The pwc module would not be loaded with
           the desired flags and would be ignored altogether.

We also had to patch the usb.rc file:

*** usb.rc.init Thu Feb 21 05:13:37 2002
--- usb.rc      Thu Feb 21 05:30:03 2002
***************
*** 53,59 ****
        # synthesize hotplug events if we can
        # we need (non-bash) programs to parse descriptors.
        LISTER=`type -p usbmodules`
!       if [ "$LISTER" = "" -o ! -f /proc/bus/usb/devices ]; then
                echo $"** can't synthesize root hub events"
                return
        fi
--- 53,59 ----
        # synthesize hotplug events if we can
        # we need (non-bash) programs to parse descriptors.
        LISTER=`type -p usbmodules`
!       if [ ! -f /proc/bus/usb/devices ]; then
                echo $"** can't synthesize root hub events"
                return
        fi
***************
*** 68,74 ****
        export DEVFS DEVICE

        # these notifications will be handled by pcimodules
!       for DEVICE in /proc/bus/usb/*/*
        do
                /etc/hotplug/usb.agent
        done
--- 68,74 ----
        export DEVFS DEVICE

        # these notifications will be handled by pcimodules
!       for DEVICE in /proc/bus/usb/[0-9][0-9][0-9]/[0-9][0-9][0-9]
        do
                /etc/hotplug/usb.agent
        done
***************
*** 81,92 ****
      COUNT=0
      SYNTHESIZEúlse

-     # if USB is partially initted, synthesize hotplug events since
-     # the kernel probably dropped them (missing root, unwritable /tmp)
-     if [ -d /proc/bus/usb -a `ls /proc/bus/usb 2>&1 | wc -l` -gt 2 ]; then
-       SYNTHESIZE=true
-     fi
-
      # if distro hasn't already done part of this ... load core,
      # and mount usbdevfs before the first hotplug agent fires
      # (so it'll be available to the agents).
--- 81,86 ----
***************
*** 134,139 ****
--- 128,139 ----
        return 1
      fi

+     # if USB is partially initted, synthesize hotplug events since
+     # the kernel probably dropped them (missing root, unwritable /tmp)
+     if [ -d /proc/bus/usb -a `ls /proc/bus/usb 2>&1 | wc -l` -gt 2 ]; then
+       SYNTHESIZE=true
+     fi
+
      # hotplug events didn't fire during booting;
      # cope with devices that enumerated earlier
      # and may not have been fully configured.


   A few notes on the above patch to usb.rc:

        1) We did not have the usbmodules file.  LISTER was always
           empty and we always got a 'can't synthesize root hub events'.

        2) Running /etc/hotplug/usb.agent over [0-9][0-9][0-9]/[0-9][0-9][0-9]
           is a bit more exact than just */*

        3) The test for /proc/bus/usb, when performed BEFORE the
           mounting of /proc/bus/usb would fail.  By moving this
           test later on, SYNTHESIZE=true would be set and
           usb_boot_events would be executed.  This allowed for
           an already plugged in webcam to be discovered.

           Although I realize that the intention was boottime,
           restarting hotplug (via /etc/init.d/hotplug) could
           happen AFTER /proc/bus/usb was mounted.  Additionally
           for those who put:

                none    /proc/bus/usb    usbdevfs defaults

           in their /etc/fstab, /proc/bus/usb is mounted well before
           hotplug starts.

           Last, somebody who changes a parameter in something like
           /etc/hotplug/usb/foo would like to be able to restart
           hotplug and have devices detected.

Comments welcome.

chongo (Landon Curt Noll) /\oo/\

p.s.: Here is some background info on Phillips/Logitech USB drivers:

        http://www.smcc.demon.nl/webcam/

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

             reply	other threads:[~2002-02-22 20:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22 20:51 linux-hotplug-mail [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-03-30 19:14 what I did to hotplug Phillips/Logitech webcams David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-101441134908913@msgid-missing \
    --to=linux-hotplug-mail@asthe.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).