linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: what I did to hotplug Phillips/Logitech webcams
Date: Sat, 30 Mar 2002 19:14:48 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-101751586731909@msgid-missing> (raw)

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

             reply	other threads:[~2002-03-30 19:14 UTC|newest]

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

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-101751586731909@msgid-missing \
    --to=david-b@pacbell.net \
    --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).