the configuration. The match/attach code was assuming whole-device
attach args all the time.
-Use the first (ie index 0) configuration for ubsa -- it makes the
code work in at least one case (PR kern/39211 by Frank Wille), and
there is no indication that an alternative configuration would
be needed. (I've admittedly never seen a usb device with more than
one configuration.)
This fixes mistakes when uhmodem support was added, and the changes were
not tested with a Huawei device yet. So please test if you can.
than a zero-terminated list; this makes the code simpler and also
hopefully fixes the recent "childdet" botch, see PR kern/38528
-handle the root hub specially a bit earlier, this allows to kick out
the "submatch" functions completely which needed to second-guess
from the port number (where "0" meant root hub")
(we could handle the root hub specially even earlier, but as done
now big parts of the hub emulation code are exercised regularely,
this would bitrot otherwise)
PR/37692 from Yojiro UO
---
uhmodem: device driver for huawei 3G wireless modem
* what it is?
A device driver for huawei 3G wireless modem, E220 and its valiations.
The devices are very simuler to ubsa device, but they need special care
to use as modem device.
This patch introduce "uhmodem (USB Huawei modem)" for the devices.
A uhmodem device has two com devices and one USB mass strage device.
The driver enable to use all of them.
* dmesg:
uhmodem0 at uhub0 port 1 configuration 1 interface 0
uhmodem0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
uhmodem0: mass storage only mode, reattach to enable modem
uhmodem0: at uhub0 port 1 (addr 2) disconnected
uhmodem0 detached
uhmodem0 at uhub0 port 1 configuration 1 interface 0
uhmodem0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ucom0 at uhmodem0 portno 0: modem
ucom1 at uhmodem0 portno 1: monitor
umass0 at uhub0 port 1 configuration 1 interface 2
umass0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
cd0 at scsibus0 target 0 lun 0: <HUAWEI, Mass Storage, 2.31> cdrom removable
matching (and handling) a whole device and those which match an
interface only. This will allow to enforce some rules, eg that
the former don't use interface information for matching or that the
latter don't modify global device state.
The previous way left too much freedom do the drivers which led to
inconsistencies and abuse.
For now, I've not changed locators and submatch rules, this will
happen later.
There should not be any change in behaviour, except in the case of
some drivers which did behave inconsistently:
if_atu, if_axe, uep: matched the configured device in the interface
stage, but did configuration again. I've converted them to match
in the device stage.
ustir, utoppy: matched in the interface stage, but only against
vendor/device information, and used any configuration/interface
without checking. Changed to match in device stage, and added
some simple code to configure and use the first interface.
If you have one of those devices, please test!
wsmouse device for now; easy enough to make it a joystick driver in the
future.
Mappings:
Left analog stick: Mouse movement
Right analog stick: Scroll wheel (4 directions)
A button: Left click
B button: Right click
X button: Middle click
Y button: injected to wsmouse as a fourth mouse button click
remove pseudo-device btdev(4) and inherent limitations
add bthub(4) which autoconfigures at bluetooth controllers as they
are enabled. bluetooth devices now attach here.
btdevctl(8) and its cache is updated to handle new semantics
etc/rc.d/btdevctl is updated to configure devices from a list
in /etc/bluetooth/btdevctl.conf
While it can be made to compile, the paradigm is not quite right because
it attempts to contact the filesystem during autoconfig which sometimes
causes a panic. Even if that was fixed, there is another potential problem
in that the driver tries/sleeps/tries/sleeps and the sleep could
theoretically sleep past the rc.d/btconfig stage and the controller
would remain unconfigured.
So, I have prepared a different method for loading the firmware to
Broadcom BCM2033 chip based devices. A package 'sysutils/bcmfw' will load
the firmware files via a ugen(4) device interface.
This update removes the ubtbcmfw(4) driver and adds a table to the ubt(4)
driver so that it will not attach to Broadcom BCM2033 based devices before
the firmware was loaded.
This fixes kern/34219
ahead and write behind, improving performance for the Universal
Software Radio Peripheral (USRP) used with GNU Radio.
Enable UGEN_BULK_RA_WB in GENERIC and GENERIC_LAPTOP; behavior is
unchanged unless the new ioctl is called.
This code was written by Joanne Mikkelson under funding from DARPA's
ACERT program.
ok'd by christos@, tested by Berndt Josef Wulf
NetBSD Foundation Membership still pending.) This stack was written by
Iain under sponsorship from Itronix Inc.
The stack includes support for rfcomm networking (networking via your
bluetooth enabled cell phone), hid devices (keyboards/mice), and headsets.
Drivers for both PCMCIA and USB bluetooth controllers are included.
of digital video recorders popular in Europe and Australia.
These devices have a USB client port which can be used to upload and
download recordings (and other files, such as MIPS binaries for execution
on the DVR's CPU) to/from their internal hard disk, in addition to some
other operations on files and directories.
Xenarc, Liliput, etc. small touchpanel LCD displays.
TODO:
- manpage
- calibration support (make hpc's tpcalib stuff more MI?)
- On i386 and other xfree-ish xservers, (currently-uncomitted) patches
are needed for X to honor wscons absolute mouse position events.
joerg