* what I did to hotplug Phillips/Logitech webcams
@ 2002-02-22 20:51 linux-hotplug-mail
0 siblings, 0 replies; 2+ messages in thread
From: linux-hotplug-mail @ 2002-02-22 20:51 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: what I did to hotplug Phillips/Logitech webcams
@ 2002-03-30 19:14 David Brownell
0 siblings, 0 replies; 2+ messages in thread
From: David Brownell @ 2002-03-30 19:14 UTC (permalink / raw)
To: linux-hotplug
This is more of a reply to "RFE" #535191 ...
> 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'.
Normally I'd expect applications to set driver modes as
necessary. But if you don't want apps to know such stuff,
what's wrong with having them set in /etc/modules.conf in
your particular configuration?
> 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
Easily done in an /etc/hotplug/usb/... script. Or even in
/etc/modules.conf ("above" or "post-install").
> 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.
Yes, that's basically what the "hotplug" in /etc/rc.d is for. Though
it seems like you weren't having that do your USB initialization,
and that was likely part of the problem.
> We added the following line to /etc/hotplug/usb.usermap:
>
> pwc 0x0003 0x046d 0x08b0 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 \
> 0x00 0x00000000
Not needed with current PWC drivers.
As for the patches ... I second Greg's request to use "diff -u"
format when posting/submitting patches, "context" diffs are
harder to understand than "unified"! Going by the comments
explaining them (and omitting what Greg dealt with):
> hotplug.functions:
> ...
> 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.
Actually the bug would be that the setup script wouldn't run if the
modprobe was done ... which is clearly bogus. I've noticed that
happening in some cases, a fix should be in the next version.
(The logic was bit too heavy on else-if ... :)
> The pwc module would not be loaded with
> the desired flags and would be ignored altogether.
See above. The normal ways to do this are with "modules.conf",
or (better yet) for applications to set the driver modes they need.
> We also had to patch the usb.rc file:
>
> ...
>
> 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 */*
Actually no ... you weren't synthesizing the events correctly,
since at this time only "usbmodules" is able to provide all
the essential device descriptor information (from usbfs).
So those two patches add up to nothing, since "*/*" is fully
correct (a more constrained pattern doesn't matter).
If you were trying to debug the processing for a single event,
it's better to just export the relevant environment variables
from a shell script using the syslogged data, and use "sh -x"
to watch the whole sequence. I can't see how you'd see
some of the failures you described unless you were running
scripts without correctly invoking them.
> 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.
If you had problems with hotplugging at boot time, they
weren't caused by this. If the USB startup script was
loading "usbcore" and mounting usbfs, then there's
no need to synthesize hotplug events ... because real
ones would be reported.
> 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.
Not quite. Hotplug for USB starts pretty much when the first
host controller driver is loaded, and the connected devices
start enumerating. After they're set up, "/sbin/hotplug is
invoked. And if usbfs is mounted already, everything works
without any need to synthesize events.
If your system boot strap procedures are initializing USB
before hotplug, it's either doing it correctly (usbfs mounted
before the host controller drivers are loaded), or not ... and
if it's not, better to fix that than try to patch broken OS init
through hotplug.
> 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.
Right, but that's happening automatically by virtue of fully stopping
USB, then correctly starting it up.
- Dave
_______________________________________________
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-03-30 19:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-30 19:14 what I did to hotplug Phillips/Logitech webcams David Brownell
-- strict thread matches above, loose matches on Subject: below --
2002-02-22 20:51 linux-hotplug-mail
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).