You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge commit 'v2.6.31-rc8' into core/locking
Merge reason: we were on -rc4, move to -rc8 before applying
a new batch of locking infrastructure changes.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
Ingo Molnar
@@ -2006,6 +2006,9 @@ E: paul@laufernet.com
|
||||
D: Soundblaster driver fixes, ISAPnP quirk
|
||||
S: California, USA
|
||||
|
||||
N: Jonathan Layes
|
||||
D: ARPD support
|
||||
|
||||
N: Tom Lees
|
||||
E: tom@lpsg.demon.co.uk
|
||||
W: http://www.lpsg.demon.co.uk/
|
||||
@@ -3802,6 +3805,9 @@ S: van Bronckhorststraat 12
|
||||
S: 2612 XV Delft
|
||||
S: The Netherlands
|
||||
|
||||
N: Thomas Woller
|
||||
D: CS461x Cirrus Logic sound driver
|
||||
|
||||
N: David Woodhouse
|
||||
E: dwmw2@infradead.org
|
||||
D: JFFS2 file system, Memory Technology Device subsystem,
|
||||
|
||||
@@ -94,28 +94,37 @@ What: /sys/block/<disk>/queue/physical_block_size
|
||||
Date: May 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
This is the smallest unit the storage device can write
|
||||
without resorting to read-modify-write operation. It is
|
||||
usually the same as the logical block size but may be
|
||||
bigger. One example is SATA drives with 4KB sectors
|
||||
that expose a 512-byte logical block size to the
|
||||
operating system.
|
||||
This is the smallest unit a physical storage device can
|
||||
write atomically. It is usually the same as the logical
|
||||
block size but may be bigger. One example is SATA
|
||||
drives with 4KB sectors that expose a 512-byte logical
|
||||
block size to the operating system. For stacked block
|
||||
devices the physical_block_size variable contains the
|
||||
maximum physical_block_size of the component devices.
|
||||
|
||||
What: /sys/block/<disk>/queue/minimum_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report a preferred minimum I/O size,
|
||||
which is the smallest request the device can perform
|
||||
without incurring a read-modify-write penalty. For disk
|
||||
drives this is often the physical block size. For RAID
|
||||
arrays it is often the stripe chunk size.
|
||||
Storage devices may report a granularity or preferred
|
||||
minimum I/O size which is the smallest request the
|
||||
device can perform without incurring a performance
|
||||
penalty. For disk drives this is often the physical
|
||||
block size. For RAID arrays it is often the stripe
|
||||
chunk size. A properly aligned multiple of
|
||||
minimum_io_size is the preferred request size for
|
||||
workloads where a high number of I/O operations is
|
||||
desired.
|
||||
|
||||
What: /sys/block/<disk>/queue/optimal_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report an optimal I/O size, which is
|
||||
the device's preferred unit of receiving I/O. This is
|
||||
rarely reported for disk drives. For RAID devices it is
|
||||
usually the stripe width or the internal block size.
|
||||
the device's preferred unit for sustained I/O. This is
|
||||
rarely reported for disk drives. For RAID arrays it is
|
||||
usually the stripe width or the internal track size. A
|
||||
properly aligned multiple of optimal_io_size is the
|
||||
preferred request size for workloads where sustained
|
||||
throughput is desired. If no optimal I/O size is
|
||||
reported this file contains 0.
|
||||
|
||||
@@ -449,8 +449,8 @@ printk(KERN_INFO "i = %u\n", i);
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
__u32 ipaddress;
|
||||
printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
|
||||
__be32 ipaddress;
|
||||
printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
|
||||
@@ -21,6 +21,8 @@ ffff8000 ffffffff copy_user_page / clear_user_page use.
|
||||
For SA11xx and Xscale, this is used to
|
||||
setup a minicache mapping.
|
||||
|
||||
ffff4000 ffffffff cache aliasing on ARMv6 and later CPUs.
|
||||
|
||||
ffff1000 ffff7fff Reserved.
|
||||
Platforms must not use this address range.
|
||||
|
||||
|
||||
@@ -123,6 +123,9 @@ available from the same CVS repository.
|
||||
There are user and developer mailing lists available through the v9fs project
|
||||
on sourceforge (http://sourceforge.net/projects/v9fs).
|
||||
|
||||
A stand-alone version of the module (which should build for any 2.6 kernel)
|
||||
is available via (http://github.com/ericvh/9p-sac/tree/master)
|
||||
|
||||
News and other information is maintained on SWiK (http://swik.net/v9fs).
|
||||
|
||||
Bug reports may be issued through the kernel.org bugzilla
|
||||
|
||||
@@ -23,16 +23,14 @@ it does support include:
|
||||
|
||||
(*) Security (currently only AFS kaserver and KerberosIV tickets).
|
||||
|
||||
(*) File reading.
|
||||
(*) File reading and writing.
|
||||
|
||||
(*) Automounting.
|
||||
|
||||
(*) Local caching (via fscache).
|
||||
|
||||
It does not yet support the following AFS features:
|
||||
|
||||
(*) Write support.
|
||||
|
||||
(*) Local caching.
|
||||
|
||||
(*) pioctl() system call.
|
||||
|
||||
|
||||
@@ -56,7 +54,7 @@ They permit the debugging messages to be turned on dynamically by manipulating
|
||||
the masks in the following files:
|
||||
|
||||
/sys/module/af_rxrpc/parameters/debug
|
||||
/sys/module/afs/parameters/debug
|
||||
/sys/module/kafs/parameters/debug
|
||||
|
||||
|
||||
=====
|
||||
@@ -66,9 +64,9 @@ USAGE
|
||||
When inserting the driver modules the root cell must be specified along with a
|
||||
list of volume location server IP addresses:
|
||||
|
||||
insmod af_rxrpc.o
|
||||
insmod rxkad.o
|
||||
insmod kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91
|
||||
modprobe af_rxrpc
|
||||
modprobe rxkad
|
||||
modprobe kafs rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91
|
||||
|
||||
The first module is the AF_RXRPC network protocol driver. This provides the
|
||||
RxRPC remote operation protocol and may also be accessed from userspace. See:
|
||||
@@ -81,7 +79,7 @@ is the actual filesystem driver for the AFS filesystem.
|
||||
Once the module has been loaded, more modules can be added by the following
|
||||
procedure:
|
||||
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells
|
||||
echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 >/proc/fs/afs/cells
|
||||
|
||||
Where the parameters to the "add" command are the name of a cell and a list of
|
||||
volume location servers within that cell, with the latter separated by colons.
|
||||
@@ -101,7 +99,7 @@ The name of the volume can be suffixes with ".backup" or ".readonly" to
|
||||
specify connection to only volumes of those types.
|
||||
|
||||
The name of the cell is optional, and if not given during a mount, then the
|
||||
named volume will be looked up in the cell specified during insmod.
|
||||
named volume will be looked up in the cell specified during modprobe.
|
||||
|
||||
Additional cells can be added through /proc (see later section).
|
||||
|
||||
@@ -163,14 +161,14 @@ THE CELL DATABASE
|
||||
|
||||
The filesystem maintains an internal database of all the cells it knows and the
|
||||
IP addresses of the volume location servers for those cells. The cell to which
|
||||
the system belongs is added to the database when insmod is performed by the
|
||||
the system belongs is added to the database when modprobe is performed by the
|
||||
"rootcell=" argument or, if compiled in, using a "kafs.rootcell=" argument on
|
||||
the kernel command line.
|
||||
|
||||
Further cells can be added by commands similar to the following:
|
||||
|
||||
echo add CELLNAME VLADDR[:VLADDR][:VLADDR]... >/proc/fs/afs/cells
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells
|
||||
echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 >/proc/fs/afs/cells
|
||||
|
||||
No other cell database operations are available at this time.
|
||||
|
||||
@@ -233,7 +231,7 @@ insmod /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.91
|
||||
mount -t afs \%root.afs. /afs
|
||||
mount -t afs \%cambridge.redhat.com:root.cell. /afs/cambridge.redhat.com/
|
||||
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 > /proc/fs/afs/cells
|
||||
echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 > /proc/fs/afs/cells
|
||||
mount -t afs "#grand.central.org:root.cell." /afs/grand.central.org/
|
||||
mount -t afs "#grand.central.org:root.archive." /afs/grand.central.org/archive
|
||||
mount -t afs "#grand.central.org:root.contrib." /afs/grand.central.org/contrib
|
||||
|
||||
@@ -1167,13 +1167,11 @@ CHAPTER 3: PER-PROCESS PARAMETERS
|
||||
3.1 /proc/<pid>/oom_adj - Adjust the oom-killer score
|
||||
------------------------------------------------------
|
||||
|
||||
This file can be used to adjust the score used to select which processes should
|
||||
be killed in an out-of-memory situation. The oom_adj value is a characteristic
|
||||
of the task's mm, so all threads that share an mm with pid will have the same
|
||||
oom_adj value. A high value will increase the likelihood of this process being
|
||||
killed by the oom-killer. Valid values are in the range -16 to +15 as
|
||||
explained below and a special value of -17, which disables oom-killing
|
||||
altogether for threads sharing pid's mm.
|
||||
This file can be used to adjust the score used to select which processes
|
||||
should be killed in an out-of-memory situation. Giving it a high score will
|
||||
increase the likelihood of this process being killed by the oom-killer. Valid
|
||||
values are in the range -16 to +15, plus the special value -17, which disables
|
||||
oom-killing altogether for this process.
|
||||
|
||||
The process to be killed in an out-of-memory situation is selected among all others
|
||||
based on its badness score. This value equals the original memory size of the process
|
||||
@@ -1187,9 +1185,6 @@ the parent's score if they do not share the same memory. Thus forking servers
|
||||
are the prime candidates to be killed. Having only one 'hungry' child will make
|
||||
parent less preferable than the child.
|
||||
|
||||
/proc/<pid>/oom_adj cannot be changed for kthreads since they are immune from
|
||||
oom-killing already.
|
||||
|
||||
/proc/<pid>/oom_score shows process' current badness score.
|
||||
|
||||
The following heuristics are then applied:
|
||||
|
||||
@@ -23,7 +23,8 @@ interface.
|
||||
Using sysfs
|
||||
~~~~~~~~~~~
|
||||
|
||||
sysfs is always compiled in. You can access it by doing:
|
||||
sysfs is always compiled in if CONFIG_SYSFS is defined. You can access
|
||||
it by doing:
|
||||
|
||||
mount -t sysfs sysfs /sys
|
||||
|
||||
|
||||
@@ -139,6 +139,7 @@ Code Seq# Include File Comments
|
||||
'm' all linux/synclink.h conflict!
|
||||
'm' 00-1F net/irda/irmod.h conflict!
|
||||
'n' 00-7F linux/ncp_fs.h
|
||||
'n' 80-8F linux/nilfs2_fs.h NILFS2
|
||||
'n' E0-FF video/matrox.h matroxfb
|
||||
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
|
||||
'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
|
||||
|
||||
@@ -1115,6 +1115,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
libata.dma=4 Compact Flash DMA only
|
||||
Combinations also work, so libata.dma=3 enables DMA
|
||||
for disks and CDROMs, but not CFs.
|
||||
|
||||
libata.ignore_hpa= [LIBATA] Ignore HPA limit
|
||||
libata.ignore_hpa=0 keep BIOS limits (default)
|
||||
libata.ignore_hpa=1 ignore limits, using full disk
|
||||
|
||||
libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume
|
||||
when set.
|
||||
|
||||
@@ -36,8 +36,6 @@ detailed description):
|
||||
- Bluetooth enable and disable
|
||||
- video output switching, expansion control
|
||||
- ThinkLight on and off
|
||||
- limited docking and undocking
|
||||
- UltraBay eject
|
||||
- CMOS/UCMS control
|
||||
- LED control
|
||||
- ACPI sounds
|
||||
@@ -729,131 +727,6 @@ cannot be read or if it is unknown, thinkpad-acpi will report it as "off".
|
||||
It is impossible to know if the status returned through sysfs is valid.
|
||||
|
||||
|
||||
Docking / undocking -- /proc/acpi/ibm/dock
|
||||
------------------------------------------
|
||||
|
||||
Docking and undocking (e.g. with the X4 UltraBase) requires some
|
||||
actions to be taken by the operating system to safely make or break
|
||||
the electrical connections with the dock.
|
||||
|
||||
The docking feature of this driver generates the following ACPI events:
|
||||
|
||||
ibm/dock GDCK 00000003 00000001 -- eject request
|
||||
ibm/dock GDCK 00000003 00000002 -- undocked
|
||||
ibm/dock GDCK 00000000 00000003 -- docked
|
||||
|
||||
NOTE: These events will only be generated if the laptop was docked
|
||||
when originally booted. This is due to the current lack of support for
|
||||
hot plugging of devices in the Linux ACPI framework. If the laptop was
|
||||
booted while not in the dock, the following message is shown in the
|
||||
logs:
|
||||
|
||||
Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present
|
||||
|
||||
In this case, no dock-related events are generated but the dock and
|
||||
undock commands described below still work. They can be executed
|
||||
manually or triggered by Fn key combinations (see the example acpid
|
||||
configuration files included in the driver tarball package available
|
||||
on the web site).
|
||||
|
||||
When the eject request button on the dock is pressed, the first event
|
||||
above is generated. The handler for this event should issue the
|
||||
following command:
|
||||
|
||||
echo undock > /proc/acpi/ibm/dock
|
||||
|
||||
After the LED on the dock goes off, it is safe to eject the laptop.
|
||||
Note: if you pressed this key by mistake, go ahead and eject the
|
||||
laptop, then dock it back in. Otherwise, the dock may not function as
|
||||
expected.
|
||||
|
||||
When the laptop is docked, the third event above is generated. The
|
||||
handler for this event should issue the following command to fully
|
||||
enable the dock:
|
||||
|
||||
echo dock > /proc/acpi/ibm/dock
|
||||
|
||||
The contents of the /proc/acpi/ibm/dock file shows the current status
|
||||
of the dock, as provided by the ACPI framework.
|
||||
|
||||
The docking support in this driver does not take care of enabling or
|
||||
disabling any other devices you may have attached to the dock. For
|
||||
example, a CD drive plugged into the UltraBase needs to be disabled or
|
||||
enabled separately. See the provided example acpid configuration files
|
||||
for how this can be accomplished.
|
||||
|
||||
There is no support yet for PCI devices that may be attached to a
|
||||
docking station, e.g. in the ThinkPad Dock II. The driver currently
|
||||
does not recognize, enable or disable such devices. This means that
|
||||
the only docking stations currently supported are the X-series
|
||||
UltraBase docks and "dumb" port replicators like the Mini Dock (the
|
||||
latter don't need any ACPI support, actually).
|
||||
|
||||
|
||||
UltraBay eject -- /proc/acpi/ibm/bay
|
||||
------------------------------------
|
||||
|
||||
Inserting or ejecting an UltraBay device requires some actions to be
|
||||
taken by the operating system to safely make or break the electrical
|
||||
connections with the device.
|
||||
|
||||
This feature generates the following ACPI events:
|
||||
|
||||
ibm/bay MSTR 00000003 00000000 -- eject request
|
||||
ibm/bay MSTR 00000001 00000000 -- eject lever inserted
|
||||
|
||||
NOTE: These events will only be generated if the UltraBay was present
|
||||
when the laptop was originally booted (on the X series, the UltraBay
|
||||
is in the dock, so it may not be present if the laptop was undocked).
|
||||
This is due to the current lack of support for hot plugging of devices
|
||||
in the Linux ACPI framework. If the laptop was booted without the
|
||||
UltraBay, the following message is shown in the logs:
|
||||
|
||||
Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present
|
||||
|
||||
In this case, no bay-related events are generated but the eject
|
||||
command described below still works. It can be executed manually or
|
||||
triggered by a hot key combination.
|
||||
|
||||
Sliding the eject lever generates the first event shown above. The
|
||||
handler for this event should take whatever actions are necessary to
|
||||
shut down the device in the UltraBay (e.g. call idectl), then issue
|
||||
the following command:
|
||||
|
||||
echo eject > /proc/acpi/ibm/bay
|
||||
|
||||
After the LED on the UltraBay goes off, it is safe to pull out the
|
||||
device.
|
||||
|
||||
When the eject lever is inserted, the second event above is
|
||||
generated. The handler for this event should take whatever actions are
|
||||
necessary to enable the UltraBay device (e.g. call idectl).
|
||||
|
||||
The contents of the /proc/acpi/ibm/bay file shows the current status
|
||||
of the UltraBay, as provided by the ACPI framework.
|
||||
|
||||
EXPERIMENTAL warm eject support on the 600e/x, A22p and A3x (To use
|
||||
this feature, you need to supply the experimental=1 parameter when
|
||||
loading the module):
|
||||
|
||||
These models do not have a button near the UltraBay device to request
|
||||
a hot eject but rather require the laptop to be put to sleep
|
||||
(suspend-to-ram) before the bay device is ejected or inserted).
|
||||
The sequence of steps to eject the device is as follows:
|
||||
|
||||
echo eject > /proc/acpi/ibm/bay
|
||||
put the ThinkPad to sleep
|
||||
remove the drive
|
||||
resume from sleep
|
||||
cat /proc/acpi/ibm/bay should show that the drive was removed
|
||||
|
||||
On the A3x, both the UltraBay 2000 and UltraBay Plus devices are
|
||||
supported. Use "eject2" instead of "eject" for the second bay.
|
||||
|
||||
Note: the UltraBay eject support on the 600e/x, A22p and A3x is
|
||||
EXPERIMENTAL and may not work as expected. USE WITH CAUTION!
|
||||
|
||||
|
||||
CMOS/UCMS control
|
||||
-----------------
|
||||
|
||||
|
||||
+483
-238
File diff suppressed because it is too large
Load Diff
@@ -30,9 +30,9 @@ State
|
||||
The validator tracks lock-class usage history into 4n + 1 separate state bits:
|
||||
|
||||
- 'ever held in STATE context'
|
||||
- 'ever head as readlock in STATE context'
|
||||
- 'ever head with STATE enabled'
|
||||
- 'ever head as readlock with STATE enabled'
|
||||
- 'ever held as readlock in STATE context'
|
||||
- 'ever held with STATE enabled'
|
||||
- 'ever held as readlock with STATE enabled'
|
||||
|
||||
Where STATE can be either one of (kernel/lockdep_states.h)
|
||||
- hardirq
|
||||
|
||||
@@ -101,6 +101,8 @@ card*/pcm*/xrun_debug
|
||||
bit 0 = Enable XRUN/jiffies debug messages
|
||||
bit 1 = Show stack trace at XRUN / jiffies check
|
||||
bit 2 = Enable additional jiffies check
|
||||
bit 3 = Log hwptr update at each period interrupt
|
||||
bit 4 = Log hwptr update at each snd_pcm_update_hw_ptr()
|
||||
|
||||
When the bit 0 is set, the driver will show the messages to
|
||||
kernel log when an xrun is detected. The debug message is
|
||||
@@ -117,6 +119,9 @@ card*/pcm*/xrun_debug
|
||||
buggy) hardware that doesn't give smooth pointer updates.
|
||||
This feature is enabled via the bit 2.
|
||||
|
||||
Bits 3 and 4 are for logging the hwptr records. Note that
|
||||
these will give flood of kernel messages.
|
||||
|
||||
card*/pcm*/sub*/info
|
||||
The general information of this PCM sub-stream.
|
||||
|
||||
|
||||
@@ -66,7 +66,8 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
|
||||
'b' - Will immediately reboot the system without syncing or unmounting
|
||||
your disks.
|
||||
|
||||
'c' - Will perform a kexec reboot in order to take a crashdump.
|
||||
'c' - Will perform a system crash by a NULL pointer dereference.
|
||||
A crashdump will be taken if configured.
|
||||
|
||||
'd' - Shows all locks that are held.
|
||||
|
||||
@@ -141,8 +142,8 @@ useful when you want to exit a program that will not let you switch consoles.
|
||||
re'B'oot is good when you're unable to shut down. But you should also 'S'ync
|
||||
and 'U'mount first.
|
||||
|
||||
'C'rashdump can be used to manually trigger a crashdump when the system is hung.
|
||||
The kernel needs to have been built with CONFIG_KEXEC enabled.
|
||||
'C'rash can be used to manually trigger a crashdump when the system is hung.
|
||||
Note that this just triggers a crash if there is no dump mechanism available.
|
||||
|
||||
'S'ync is great when your system is locked up, it allows you to sync your
|
||||
disks and will certainly lessen the chance of data loss and fscking. Note
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
|
||||
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
|
||||
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
|
||||
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
|
||||
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
|
||||
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201]
|
||||
@@ -20,7 +20,7 @@
|
||||
19 -> EM2860/SAA711X Reference Design (em2860)
|
||||
20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002]
|
||||
21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801]
|
||||
22 -> Unknown EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751]
|
||||
22 -> EM2710/EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751]
|
||||
23 -> Huaqi DLCW-130 (em2750)
|
||||
24 -> D-Link DUB-T210 TV Tuner (em2820/em2840) [2001:f112]
|
||||
25 -> Gadmei UTV310 (em2820/em2840)
|
||||
|
||||
@@ -153,8 +153,8 @@
|
||||
152 -> Asus Tiger Rev:1.00 [1043:4857]
|
||||
153 -> Kworld Plus TV Analog Lite PCI [17de:7128]
|
||||
154 -> Avermedia AVerTV GO 007 FM Plus [1461:f31d]
|
||||
155 -> Hauppauge WinTV-HVR1120 ATSC/QAM-Hybrid [0070:6706,0070:6708]
|
||||
156 -> Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid [0070:6707,0070:6709,0070:670a]
|
||||
155 -> Hauppauge WinTV-HVR1150 ATSC/QAM-Hybrid [0070:6706,0070:6708]
|
||||
156 -> Hauppauge WinTV-HVR1120 DVB-T/Hybrid [0070:6707,0070:6709,0070:670a]
|
||||
157 -> Avermedia AVerTV Studio 507UA [1461:a11b]
|
||||
158 -> AVerMedia Cardbus TV/Radio (E501R) [1461:b7e9]
|
||||
159 -> Beholder BeholdTV 505 RDS [0000:505B]
|
||||
|
||||
@@ -44,7 +44,9 @@ zc3xx 0458:7007 Genius VideoCam V2
|
||||
zc3xx 0458:700c Genius VideoCam V3
|
||||
zc3xx 0458:700f Genius VideoCam Web V2
|
||||
sonixj 0458:7025 Genius Eye 311Q
|
||||
sn9c20x 0458:7029 Genius Look 320s
|
||||
sonixj 0458:702e Genius Slim 310 NB
|
||||
sn9c20x 045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650)
|
||||
sonixj 045e:00f5 MicroSoft VX3000
|
||||
sonixj 045e:00f7 MicroSoft VX1000
|
||||
ov519 045e:028c Micro$oft xbox cam
|
||||
@@ -282,6 +284,28 @@ sonixj 0c45:613a Microdia Sonix PC Camera
|
||||
sonixj 0c45:613b Surfer SN-206
|
||||
sonixj 0c45:613c Sonix Pccam168
|
||||
sonixj 0c45:6143 Sonix Pccam168
|
||||
sn9c20x 0c45:6240 PC Camera (SN9C201 + MT9M001)
|
||||
sn9c20x 0c45:6242 PC Camera (SN9C201 + MT9M111)
|
||||
sn9c20x 0c45:6248 PC Camera (SN9C201 + OV9655)
|
||||
sn9c20x 0c45:624e PC Camera (SN9C201 + SOI968)
|
||||
sn9c20x 0c45:624f PC Camera (SN9C201 + OV9650)
|
||||
sn9c20x 0c45:6251 PC Camera (SN9C201 + OV9650)
|
||||
sn9c20x 0c45:6253 PC Camera (SN9C201 + OV9650)
|
||||
sn9c20x 0c45:6260 PC Camera (SN9C201 + OV7670)
|
||||
sn9c20x 0c45:6270 PC Camera (SN9C201 + MT9V011/MT9V111/MT9V112)
|
||||
sn9c20x 0c45:627b PC Camera (SN9C201 + OV7660)
|
||||
sn9c20x 0c45:627c PC Camera (SN9C201 + HV7131R)
|
||||
sn9c20x 0c45:627f PC Camera (SN9C201 + OV9650)
|
||||
sn9c20x 0c45:6280 PC Camera (SN9C202 + MT9M001)
|
||||
sn9c20x 0c45:6282 PC Camera (SN9C202 + MT9M111)
|
||||
sn9c20x 0c45:6288 PC Camera (SN9C202 + OV9655)
|
||||
sn9c20x 0c45:628e PC Camera (SN9C202 + SOI968)
|
||||
sn9c20x 0c45:628f PC Camera (SN9C202 + OV9650)
|
||||
sn9c20x 0c45:62a0 PC Camera (SN9C202 + OV7670)
|
||||
sn9c20x 0c45:62b0 PC Camera (SN9C202 + MT9V011/MT9V111/MT9V112)
|
||||
sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655)
|
||||
sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660)
|
||||
sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R)
|
||||
sunplus 0d64:0303 Sunplus FashionCam DXG
|
||||
etoms 102c:6151 Qcam Sangha CIF
|
||||
etoms 102c:6251 Qcam xxxxxx VGA
|
||||
@@ -290,6 +314,7 @@ spca561 10fd:7e50 FlyCam Usb 100
|
||||
zc3xx 10fd:8050 Typhoon Webshot II USB 300k
|
||||
ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201)
|
||||
pac207 145f:013a Trust WB-1300N
|
||||
sn9c20x 145f:013d Trust WB-3600R
|
||||
vc032x 15b8:6001 HP 2.0 Megapixel
|
||||
vc032x 15b8:6002 HP 2.0 Megapixel rz406aa
|
||||
spca501 1776:501c Arowana 300K CMOS Camera
|
||||
@@ -300,4 +325,11 @@ spca500 2899:012c Toptro Industrial
|
||||
spca508 8086:0110 Intel Easy PC Camera
|
||||
spca500 8086:0630 Intel Pocket PC Camera
|
||||
spca506 99fa:8988 Grandtec V.cap
|
||||
sn9c20x a168:0610 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
|
||||
sn9c20x a168:0611 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
|
||||
sn9c20x a168:0613 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
|
||||
sn9c20x a168:0618 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
|
||||
sn9c20x a168:0614 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
|
||||
sn9c20x a168:0615 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
|
||||
sn9c20x a168:0617 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
|
||||
spca561 abcd:cdee Petcam
|
||||
|
||||
+940
-1849
File diff suppressed because it is too large
Load Diff
@@ -1,7 +1,7 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 31
|
||||
EXTRAVERSION = -rc4
|
||||
EXTRAVERSION = -rc8
|
||||
NAME = Man-Eating Seals of Antiquity
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user