forked from Minki/linux
Merge branch 'refs' into docs-next
Tom Saeger says: Recently, while reading up on binfmt I attempted to open a document ref only to find it was invalid. I did a quick grep, found all the binfmt_misc related broken refs and sent a patch. Fine. Easy. Then I wondered, "how many broken doc refs are there?". Turns out with all the recent doc moves, quite a few. I went about fixing just those found in Documentation/, except those in Documentation/translations/ and Documentation/devicetree/ for now. Most of these changes were s/txt/rst/ or fixing up a path to an obvious new location. Some required going back to v4.10 v4.4 or some other version to sleuth-out what content was actually being referenced and then fixing the reference to point to the new file with that content.
This commit is contained in:
commit
3211ba4157
@ -1,5 +1,5 @@
|
||||
# Note: This documents additional properties of any device beyond what
|
||||
# is documented in Documentation/sysfs-rules.txt
|
||||
# is documented in Documentation/admin-guide/sysfs-rules.rst
|
||||
|
||||
What: /sys/devices/*/of_node
|
||||
Date: February 2015
|
||||
|
@ -18,6 +18,6 @@ Description:
|
||||
in the initramfs, which has already been measured as part
|
||||
of the trusted boot. For more information on creating and
|
||||
loading existing trusted/encrypted keys, refer to:
|
||||
Documentation/keys-trusted-encrypted.txt. (A sample dracut
|
||||
patch, which loads the trusted/encrypted key and enables
|
||||
Documentation/security/keys/trusted-encrypted.rst. (A sample
|
||||
dracut patch, which loads the trusted/encrypted key and enables
|
||||
EVM, is available from http://linux-ima.sourceforge.net/#EVM.)
|
||||
|
@ -187,7 +187,8 @@ Description: Processor frequency boosting control
|
||||
This switch controls the boost setting for the whole system.
|
||||
Boosting allows the CPU and the firmware to run at a frequency
|
||||
beyound it's nominal limit.
|
||||
More details can be found in Documentation/cpu-freq/boost.txt
|
||||
More details can be found in
|
||||
Documentation/admin-guide/pm/cpufreq.rst
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/crash_notes
|
||||
@ -223,7 +224,8 @@ Description: Parameters for the Intel P-state driver
|
||||
no_turbo: limits the driver to selecting P states below the turbo
|
||||
frequency range.
|
||||
|
||||
More details can be found in Documentation/cpu-freq/intel-pstate.txt
|
||||
More details can be found in
|
||||
Documentation/admin-guide/pm/intel_pstate.rst
|
||||
|
||||
What: /sys/devices/system/cpu/cpu*/cache/index*/<set_of_attributes_mentioned_below>
|
||||
Date: July 2014(documented, existed before August 2008)
|
||||
|
@ -18,7 +18,8 @@ Description:
|
||||
Writing one of the above strings to this file causes the system
|
||||
to transition into the corresponding state, if available.
|
||||
|
||||
See Documentation/power/states.txt for more information.
|
||||
See Documentation/admin-guide/pm/sleep-states.rst for more
|
||||
information.
|
||||
|
||||
What: /sys/power/mem_sleep
|
||||
Date: November 2016
|
||||
@ -35,7 +36,8 @@ Description:
|
||||
represented by it to be used on subsequent attempts to suspend
|
||||
the system.
|
||||
|
||||
See Documentation/power/states.txt for more information.
|
||||
See Documentation/admin-guide/pm/sleep-states.rst for more
|
||||
information.
|
||||
|
||||
What: /sys/power/disk
|
||||
Date: September 2006
|
||||
|
@ -350,7 +350,7 @@ If something goes wrong
|
||||
help debugging the problem. The text above the dump is also
|
||||
important: it tells something about why the kernel dumped code (in
|
||||
the above example, it's due to a bad kernel pointer). More information
|
||||
on making sense of the dump is in Documentation/admin-guide/oops-tracing.rst
|
||||
on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst
|
||||
|
||||
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
|
||||
as is, otherwise you will have to use the ``ksymoops`` program to make
|
||||
|
@ -314,7 +314,7 @@
|
||||
amijoy.map= [HW,JOY] Amiga joystick support
|
||||
Map of devices attached to JOY0DAT and JOY1DAT
|
||||
Format: <a>,<b>
|
||||
See also Documentation/input/joystick.txt
|
||||
See also Documentation/input/joydev/joystick.rst
|
||||
|
||||
analog.map= [HW,JOY] Analog joystick and gamepad support
|
||||
Specifies type or capabilities of an analog joystick
|
||||
@ -439,7 +439,7 @@
|
||||
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
|
||||
bttv.radio= Most important insmod options are available as
|
||||
kernel args too.
|
||||
bttv.pll= See Documentation/video4linux/bttv/Insmod-options
|
||||
bttv.pll= See Documentation/media/v4l-drivers/bttv.rst
|
||||
bttv.tuner=
|
||||
|
||||
bulk_remove=off [PPC] This parameter disables the use of the pSeries
|
||||
@ -724,7 +724,7 @@
|
||||
db9.dev[2|3]= [HW,JOY] Multisystem joystick support via parallel port
|
||||
(one device per port)
|
||||
Format: <port#>,<type>
|
||||
See also Documentation/input/joystick-parport.txt
|
||||
See also Documentation/input/devices/joystick-parport.rst
|
||||
|
||||
ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
|
||||
time. See
|
||||
@ -1220,7 +1220,7 @@
|
||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||
support via parallel port (up to 5 devices per port)
|
||||
Format: <port#>,<pad1>,<pad2>,<pad3>,<pad4>,<pad5>
|
||||
See also Documentation/input/joystick-parport.txt
|
||||
See also Documentation/input/devices/joystick-parport.rst
|
||||
|
||||
gamma= [HW,DRM]
|
||||
|
||||
@ -1766,7 +1766,7 @@
|
||||
ivrs_acpihid[00:14.5]=AMD0020:0
|
||||
|
||||
js= [HW,JOY] Analog joystick
|
||||
See Documentation/input/joystick.txt.
|
||||
See Documentation/input/joydev/joystick.rst.
|
||||
|
||||
nokaslr [KNL]
|
||||
When CONFIG_RANDOMIZE_BASE is set, this disables
|
||||
@ -2251,7 +2251,7 @@
|
||||
See Documentation/admin-guide/pm/sleep-states.rst.
|
||||
|
||||
meye.*= [HW] Set MotionEye Camera parameters
|
||||
See Documentation/video4linux/meye.txt.
|
||||
See Documentation/media/v4l-drivers/meye.rst.
|
||||
|
||||
mfgpt_irq= [IA-32] Specify the IRQ to use for the
|
||||
Multi-Function General Purpose Timers on AMD Geode
|
||||
@ -3134,7 +3134,7 @@
|
||||
|
||||
plip= [PPT,NET] Parallel port network link
|
||||
Format: { parport<nr> | timid | 0 }
|
||||
See also Documentation/parport.txt.
|
||||
See also Documentation/admin-guide/parport.rst.
|
||||
|
||||
pmtmr= [X86] Manual setup of pmtmr I/O Port.
|
||||
Override pmtimer IOPort with a hex value.
|
||||
@ -4205,7 +4205,7 @@
|
||||
TurboGraFX parallel port interface
|
||||
Format:
|
||||
<port#>,<js1>,<js2>,<js3>,<js4>,<js5>,<js6>,<js7>
|
||||
See also Documentation/input/joystick-parport.txt
|
||||
See also Documentation/input/devices/joystick-parport.rst
|
||||
|
||||
udbg-immortal [PPC] When debugging early kernel crashes that
|
||||
happen after console_init() and before a proper
|
||||
|
@ -94,7 +94,7 @@ step-by-step instructions for how a user can trigger the bug.
|
||||
|
||||
If the failure includes an "OOPS:", take a picture of the screen, capture
|
||||
a netconsole trace, or type the message from your screen into the bug
|
||||
report. Please read "Documentation/admin-guide/oops-tracing.rst" before posting your
|
||||
report. Please read "Documentation/admin-guide/bug-hunting.rst" before posting your
|
||||
bug report. This explains what you should do with the "Oops" information
|
||||
to make it useful to the recipient.
|
||||
|
||||
@ -120,7 +120,7 @@ summary from [1.]>" for easy identification by the developers::
|
||||
[4.2.] Kernel .config file:
|
||||
[5.] Most recent kernel version which did not have the bug:
|
||||
[6.] Output of Oops.. message (if applicable) with symbolic information
|
||||
resolved (see Documentation/admin-guide/oops-tracing.rst)
|
||||
resolved (see Documentation/admin-guide/bug-hunting.rst)
|
||||
[7.] A small shell script or example program which triggers the
|
||||
problem (if possible)
|
||||
[8.] Environment
|
||||
|
@ -690,9 +690,7 @@ The USB devices are now exported via debugfs:
|
||||
This file is handy for status viewing tools in user mode, which can scan
|
||||
the text format and ignore most of it. More detailed device status
|
||||
(including class and vendor status) is available from device-specific
|
||||
files. For information about the current format of this file, see the
|
||||
``Documentation/usb/proc_usb_info.txt`` file in your Linux kernel
|
||||
sources.
|
||||
files. For information about the current format of this file, see below.
|
||||
|
||||
This file, in combination with the poll() system call, can also be used
|
||||
to detect when devices are added or removed::
|
||||
|
@ -12,7 +12,7 @@ To support these disparate requirements, the Linux USB system provides
|
||||
HID events to two separate interfaces:
|
||||
* the input subsystem, which converts HID events into normal input
|
||||
device interfaces (such as keyboard, mouse and joystick) and a
|
||||
normalised event interface - see Documentation/input/input.txt
|
||||
normalised event interface - see Documentation/input/input.rst
|
||||
* the hiddev interface, which provides fairly raw HID events
|
||||
|
||||
The data flow for a HID event produced by a device is something like
|
||||
|
@ -230,4 +230,5 @@ Historic Edits
|
||||
2005-03-19 - Dominic Cerquetti <binary1230@yahoo.com>
|
||||
- added stuff for dance pads, new d-pad->axes mappings
|
||||
|
||||
Later changes may be viewed with 'git log Documentation/input/xpad.txt'
|
||||
Later changes may be viewed with
|
||||
'git log --follow Documentation/input/devices/xpad.rst'
|
||||
|
@ -184,7 +184,7 @@ is done when dirty_ratio is reached.
|
||||
DO_CPU:
|
||||
|
||||
Enable CPU frequency scaling when in laptop mode. (Requires CPUFreq to be setup.
|
||||
See Documentation/cpu-freq/user-guide.txt for more info. Disabled by default.)
|
||||
See Documentation/admin-guide/pm/cpufreq.rst for more info. Disabled by default.)
|
||||
|
||||
CPU_MAXFREQ:
|
||||
|
||||
@ -287,7 +287,7 @@ MINIMUM_BATTERY_MINUTES=10
|
||||
|
||||
# Should the maximum CPU frequency be adjusted down while on battery?
|
||||
# Requires CPUFreq to be setup.
|
||||
# See Documentation/cpu-freq/user-guide.txt for more info
|
||||
# See Documentation/admin-guide/pm/cpufreq.rst for more info
|
||||
#DO_CPU=0
|
||||
|
||||
# When on battery what is the maximum CPU speed that the system should
|
||||
@ -378,7 +378,7 @@ BATT_HD=${BATT_HD:-'4'}
|
||||
DIRTY_RATIO=${DIRTY_RATIO:-'40'}
|
||||
|
||||
# cpu frequency scaling
|
||||
# See Documentation/cpu-freq/user-guide.txt for more info
|
||||
# See Documentation/admin-guide/pm/cpufreq.rst for more info
|
||||
DO_CPU=${CPU_MANAGE:-'0'}
|
||||
CPU_MAXFREQ=${CPU_MAXFREQ:-'slowest'}
|
||||
|
||||
|
@ -18,7 +18,7 @@ General information
|
||||
|
||||
This class of cards has a bt878a as the PCI interface, and require the bttv driver
|
||||
for accessing the i2c bus and the gpio pins of the bt8xx chipset.
|
||||
Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx PCI bridge:
|
||||
Please see Documentation/media/dvb-drivers/cards.rst => o Cards based on the Conexant Bt8xx PCI bridge:
|
||||
|
||||
Compiling kernel please enable:
|
||||
|
||||
@ -45,7 +45,7 @@ Loading Modules
|
||||
Regular case: If the bttv driver detects a bt8xx-based DVB card, all frontend and backend modules will be loaded automatically.
|
||||
Exceptions are:
|
||||
- Old TwinHan DST cards or clones with or without CA slot and not containing an Eeprom.
|
||||
People running udev please see Documentation/dvb/udev.txt.
|
||||
People running udev please see Documentation/media/dvb-drivers/udev.rst.
|
||||
|
||||
In the following cases overriding the PCI type detection for dvb-bt8xx might be necessary:
|
||||
|
||||
@ -72,7 +72,7 @@ Useful parameters for verbosity level and debugging the dst module:
|
||||
The autodetected values are determined by the cards' "response string".
|
||||
In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI].
|
||||
For bug reports please send in a complete log with verbose=4 activated.
|
||||
Please also see Documentation/dvb/ci.txt.
|
||||
Please also see Documentation/media/dvb-drivers/ci.rst.
|
||||
|
||||
Running multiple cards
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -100,7 +100,7 @@ Examples of card ID's:
|
||||
|
||||
$ modprobe bttv card=113 card=135
|
||||
|
||||
For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv.
|
||||
For a full list of card ID's please see Documentation/media/v4l-drivers/bttv-cardlist.rst.
|
||||
In case of further problems please subscribe and send questions to the mailing list: linux-dvb@linuxtv.org.
|
||||
|
||||
Probing the cards with broken PCI subsystem ID
|
||||
|
@ -431,7 +431,7 @@ MPEG stream.
|
||||
*Historical context*: This format specification originates from a
|
||||
custom, embedded, sliced VBI data format used by the ``ivtv`` driver.
|
||||
This format has already been informally specified in the kernel sources
|
||||
in the file ``Documentation/video4linux/cx2341x/README.vbi`` . The
|
||||
in the file ``Documentation/media/v4l-drivers/cx2341x.rst`` . The
|
||||
maximum size of the payload and other aspects of this format are driven
|
||||
by the CX23415 MPEG decoder's capabilities and limitations with respect
|
||||
to extracting, decoding, and displaying sliced VBI data embedded within
|
||||
|
@ -284,7 +284,7 @@ enum v4l2_mpeg_stream_vbi_fmt -
|
||||
* - ``V4L2_MPEG_STREAM_VBI_FMT_IVTV``
|
||||
- VBI in private packets, IVTV format (documented in the kernel
|
||||
sources in the file
|
||||
``Documentation/video4linux/cx2341x/README.vbi``)
|
||||
``Documentation/media/v4l-drivers/cx2341x.rst``)
|
||||
|
||||
|
||||
|
||||
|
@ -52,7 +52,7 @@ please make a proposal on the linux-media mailing list.
|
||||
`http://www.ivtvdriver.org/ <http://www.ivtvdriver.org/>`__
|
||||
|
||||
The format is documented in the kernel sources in the file
|
||||
``Documentation/video4linux/cx2341x/README.hm12``
|
||||
``Documentation/media/v4l-drivers/cx2341x.rst``
|
||||
* .. _V4L2-PIX-FMT-CPIA1:
|
||||
|
||||
- ``V4L2_PIX_FMT_CPIA1``
|
||||
|
@ -307,7 +307,7 @@ console and let some terminal application log the messages. /me uses
|
||||
screen. See Documentation/admin-guide/serial-console.rst for details on setting
|
||||
up a serial console.
|
||||
|
||||
Read Documentation/admin-guide/oops-tracing.rst to learn how to get any useful
|
||||
Read Documentation/admin-guide/bug-hunting.rst to learn how to get any useful
|
||||
information out of a register+stack dump printed by the kernel on
|
||||
protection faults (so-called "kernel oops").
|
||||
|
||||
|
@ -7,7 +7,7 @@ The MAX2175 driver implements the following driver-specific controls:
|
||||
-------------------------------
|
||||
Enable/Disable I2S output of the tuner. This is a private control
|
||||
that can be accessed only using the subdev interface.
|
||||
Refer to Documentation/media/kapi/v4l2-controls for more details.
|
||||
Refer to Documentation/media/kapi/v4l2-controls.rst for more details.
|
||||
|
||||
.. flat-table::
|
||||
:header-rows: 0
|
||||
|
@ -332,8 +332,8 @@ References
|
||||
[5] "MBIM (Mobile Broadband Interface Model) Registry"
|
||||
- http://compliance.usb.org/mbim/
|
||||
|
||||
[6] "/dev/bus/usb filesystem output"
|
||||
- Documentation/usb/proc_usb_info.txt
|
||||
[6] "/sys/kernel/debug/usb/devices output format"
|
||||
- Documentation/driver-api/usb/usb.rst
|
||||
|
||||
[7] "/sys/bus/usb/devices/.../descriptors"
|
||||
- Documentation/ABI/stable/sysfs-bus-usb
|
||||
|
@ -47,7 +47,7 @@ The requirements for GSO are more complicated, because when segmenting an
|
||||
(section 'E') for more details.
|
||||
|
||||
A driver declares its offload capabilities in netdev->hw_features; see
|
||||
Documentation/networking/netdev-features for more. Note that a device
|
||||
Documentation/networking/netdev-features.txt for more. Note that a device
|
||||
which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start
|
||||
and csum_offset given in the SKB; if it tries to deduce these itself in
|
||||
hardware (as some NICs do) the driver should check that the values in the
|
||||
|
@ -1055,7 +1055,7 @@ TX_RING part only TP_STATUS_AVAILABLE is set, then the tp_sec and tp_{n,u}sec
|
||||
members do not contain a valid value. For TX_RINGs, by default no timestamp
|
||||
is generated!
|
||||
|
||||
See include/linux/net_tstamp.h and Documentation/networking/timestamping
|
||||
See include/linux/net_tstamp.h and Documentation/networking/timestamping.txt
|
||||
for more information on hardware timestamps.
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
@ -24,7 +24,8 @@ platform.
|
||||
|
||||
If one of the strings listed in /sys/power/state is written to it, the system
|
||||
will attempt to transition into the corresponding sleep state. Refer to
|
||||
Documentation/power/states.txt for a description of each of those states.
|
||||
Documentation/admin-guide/pm/sleep-states.rst for a description of each of
|
||||
those states.
|
||||
|
||||
/sys/power/disk controls the operating mode of hibernation (Suspend-to-Disk).
|
||||
Specifically, it tells the kernel what to do after creating a hibernation image.
|
||||
|
@ -8,7 +8,7 @@ management. Based on previous work by Patrick Mochel <mochel@transmeta.com>
|
||||
|
||||
This document only covers the aspects of power management specific to PCI
|
||||
devices. For general description of the kernel's interfaces related to device
|
||||
power management refer to Documentation/power/admin-guide/devices.rst and
|
||||
power management refer to Documentation/driver-api/pm/devices.rst and
|
||||
Documentation/power/runtime_pm.txt.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
@ -417,7 +417,7 @@ pm->runtime_idle() callback.
|
||||
2.4. System-Wide Power Transitions
|
||||
----------------------------------
|
||||
There are a few different types of system-wide power transitions, described in
|
||||
Documentation/power/admin-guide/devices.rst. Each of them requires devices to be handled
|
||||
Documentation/driver-api/pm/devices.rst. Each of them requires devices to be handled
|
||||
in a specific way and the PM core executes subsystem-level power management
|
||||
callbacks for this purpose. They are executed in phases such that each phase
|
||||
involves executing the same subsystem-level callback for every device belonging
|
||||
@ -623,7 +623,7 @@ System restore requires a hibernation image to be loaded into memory and the
|
||||
pre-hibernation memory contents to be restored before the pre-hibernation system
|
||||
activity can be resumed.
|
||||
|
||||
As described in Documentation/power/admin-guide/devices.rst, the hibernation image is loaded
|
||||
As described in Documentation/driver-api/pm/devices.rst, the hibernation image is loaded
|
||||
into memory by a fresh instance of the kernel, called the boot kernel, which in
|
||||
turn is loaded and run by a boot loader in the usual way. After the boot kernel
|
||||
has loaded the image, it needs to replace its own code and data with the code
|
||||
@ -677,7 +677,7 @@ controlling the runtime power management of their devices.
|
||||
|
||||
At the time of this writing there are two ways to define power management
|
||||
callbacks for a PCI device driver, the recommended one, based on using a
|
||||
dev_pm_ops structure described in Documentation/power/admin-guide/devices.rst, and the
|
||||
dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and the
|
||||
"legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and
|
||||
.resume() callbacks from struct pci_driver are used. The legacy approach,
|
||||
however, doesn't allow one to define runtime power management callbacks and is
|
||||
@ -1046,5 +1046,5 @@ PCI Local Bus Specification, Rev. 3.0
|
||||
PCI Bus Power Management Interface Specification, Rev. 1.2
|
||||
Advanced Configuration and Power Interface (ACPI) Specification, Rev. 3.0b
|
||||
PCI Express Base Specification, Rev. 2.0
|
||||
Documentation/power/admin-guide/devices.rst
|
||||
Documentation/driver-api/pm/devices.rst
|
||||
Documentation/power/runtime_pm.txt
|
||||
|
@ -680,7 +680,7 @@ left in runtime suspend. If that happens, the PM core will not execute any
|
||||
system suspend and resume callbacks for all of those devices, except for the
|
||||
complete callback, which is then entirely responsible for handling the device
|
||||
as appropriate. This only applies to system suspend transitions that are not
|
||||
related to hibernation (see Documentation/power/admin-guide/devices.rst for more
|
||||
related to hibernation (see Documentation/driver-api/pm/devices.rst for more
|
||||
information).
|
||||
|
||||
The PM core does its best to reduce the probability of race conditions between
|
||||
|
@ -117,7 +117,7 @@ PM support:
|
||||
anything. For the driver testing instructions see
|
||||
Documentation/power/drivers-testing.txt and for a relatively
|
||||
complete overview of the power management issues related to
|
||||
drivers see Documentation/power/admin-guide/devices.rst .
|
||||
drivers see Documentation/driver-api/pm/devices.rst.
|
||||
|
||||
Control:
|
||||
In general if there is active maintenance of a driver by
|
||||
|
@ -5,7 +5,7 @@ Linux Security Module Development
|
||||
Based on https://lkml.org/lkml/2007/10/26/215,
|
||||
a new LSM is accepted into the kernel when its intent (a description of
|
||||
what it tries to protect against and in what cases one would expect to
|
||||
use it) has been appropriately documented in ``Documentation/security/LSM``.
|
||||
use it) has been appropriately documented in ``Documentation/security/LSM.rst``.
|
||||
This allows an LSM's code to be easily compared to its goals, and so
|
||||
that end users and distros can make a more informed decision about which
|
||||
LSMs suit their requirements.
|
||||
|
@ -196,7 +196,7 @@ The Linux kernel supports the following types of credentials:
|
||||
When a process accesses a key, if not already present, it will normally be
|
||||
cached on one of these keyrings for future accesses to find.
|
||||
|
||||
For more information on using keys, see Documentation/security/keys.txt.
|
||||
For more information on using keys, see ``Documentation/security/keys/*``.
|
||||
|
||||
5. LSM
|
||||
|
||||
|
@ -3,7 +3,7 @@ Key Request Service
|
||||
===================
|
||||
|
||||
The key request service is part of the key retention service (refer to
|
||||
Documentation/security/core.rst). This document explains more fully how
|
||||
Documentation/security/keys/core.rst). This document explains more fully how
|
||||
the requesting algorithm works.
|
||||
|
||||
The process starts by either the kernel requesting a service by calling
|
||||
|
@ -11,7 +11,7 @@ General
|
||||
|
||||
First of all, you need to enable GAMEPORT support on Linux kernel for
|
||||
using a joystick with the ALSA driver. For the details of gameport
|
||||
support, refer to Documentation/input/joystick.txt.
|
||||
support, refer to Documentation/input/joydev/joystick.rst.
|
||||
|
||||
The joystick support of ALSA drivers is different between ISA and PCI
|
||||
cards. In the case of ISA (PnP) cards, it's usually handled by the
|
||||
|
@ -192,7 +192,7 @@ preset model instead of PCI (and codec-) SSID look-up.
|
||||
What ``model`` option values are available depends on the codec chip.
|
||||
Check your codec chip from the codec proc file (see "Codec Proc-File"
|
||||
section below). It will show the vendor/product name of your codec
|
||||
chip. Then, see Documentation/sound/HD-Audio-Models.rst file,
|
||||
chip. Then, see Documentation/sound/hd-audio/models.rst file,
|
||||
the section of HD-audio driver. You can find a list of codecs
|
||||
and ``model`` options belonging to each codec. For example, for Realtek
|
||||
ALC262 codec chip, pass ``model=ultra`` for devices that are compatible
|
||||
|
@ -2498,7 +2498,7 @@ Mic boost
|
||||
Mic-boost switch is set as “Mic Boost” or “Mic Boost (6dB)”.
|
||||
|
||||
More precise information can be found in
|
||||
``Documentation/sound/alsa/ControlNames.txt``.
|
||||
``Documentation/sound/designs/control-names.rst``.
|
||||
|
||||
Access Flags
|
||||
------------
|
||||
|
@ -773,7 +773,7 @@ host:
|
||||
# cat /dev/usb/lp0
|
||||
|
||||
More advanced testing can be done with the prn_example
|
||||
described in Documentation/usb/gadget-printer.txt.
|
||||
described in Documentation/usb/gadget_printer.txt.
|
||||
|
||||
|
||||
20. UAC1 function (virtual ALSA card, using u_audio API)
|
||||
|
Loading…
Reference in New Issue
Block a user