| /Documentation/input/ |
| D | gamepad.rst | 12 document defines how gamepads are supposed to report their data.
44 4 buttons in diamonds-shape (on the right side). The buttons are
56 all devices have both or any, but they are present at most times.
59 Triggers are located on the upper-side of the pad in vertical direction.
60 Not all devices provide them, but the upper buttons are normally named
63 Many devices provide force-feedback features. But are mostly just
79 All new gamepads are supposed to comply with this mapping. Please report any
82 There are a lot of less-featured/less-powerful devices out there, which re-use
103 of the labels on the buttons, the codes are sent according to the
106 Please note that 2- and 3-button pads are fairly rare and old. You might
[all …]
|
| /Documentation/fb/ |
| D | api.rst | 13 buffer core are not described.
24 Device and driver capabilities are reported in the fixed screen information
39 When supported, formats are configured using a FOURCC instead of manually
46 Pixels are stored in memory in hardware-dependent formats. Applications need
50 Formats are described by frame buffer types and visuals. Some visuals require
51 additional information, which are stored in the variable screen information
55 macropixels. Types describe how macropixels are stored in memory. The following
56 types and visuals are supported.
60 Macropixels are stored contiguously in a single plane. If the number of bits
61 per macropixel is not a multiple of 8, whether macropixels are padded to the
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | colorspaces.rst | 20 the human eye has color receptors that are sensitive to three different
22 color. Be glad you are not a mantis shrimp as those are sensitive to 12
27 color receptors are stimulated. This is based on the Spectral Power
35 those receptors and are perceived as the same color, even though the SPD
43 After some further mathematical transforms these stimuli are known as
45 color as perceived by a human unambiguously. These X, Y and Z values are
56 The x and y values are the chromaticity coordinates and can be used to
59 colors are specified with lower case 'x' and 'y', then the CIE xyY
64 will find reading resources that go into much more detail if you are
71 phosphors used in the displays. These *color primaries* are part of what
[all …]
|
| D | pixfmt-intro.rst | 13 V4L2 drivers are not limited to these formats, however. Driver-specific
14 formats are possible. In that case the application may depend on a codec
22 Even so, ultimately, some standard formats are needed, so the V4L2
26 The V4L2 standard formats are mainly uncompressed formats. The pixels
27 are always arranged in memory from left to right, and from top to
40 :ref:`four character (FourCC) codes <v4l2-fourcc>` which are also
41 listed below, however they are not the same as those used in the Windows
45 buffers. Those formats are identified by a separate set of FourCC codes
46 and are referred to as "multi-planar formats". For example, a
51 3-planar case. Those sub-buffers are referred to as "*planes*".
|
| D | selection-api-configuration.rst | 17 Therefore, as usual, drivers are expected to adjust the requested
33 corner at position ``(0,0)``. The rectangle's coordinates are expressed
50 coordinates are obtained using ``V4L2_SEL_TGT_COMPOSE_BOUNDS``. All
51 coordinates are expressed in pixels. The rectangle's top/left corner
52 must be located at position ``(0,0)``. The width and height are equal to
57 coordinates are also expressed in the same coordinate system as the
76 are located and remove them if needed.
82 For output devices targets and ioctls are used similarly to the video
90 cropping coordinates are obtained using ``V4L2_SEL_TGT_CROP_BOUNDS``.
91 All coordinates are expressed in pixels. The top/left corner is always
[all …]
|
| /Documentation/ |
| D | atomic_bitops.txt | 5 While our bitmap_{}() functions are non-atomic, we have a number of operations
6 operating on single bits in a bitmap that are atomic.
12 The single bit operations are:
55 - non-RMW operations are unordered;
57 - RMW operations that have no return value are unordered;
59 - RMW operations that have a return value are fully ordered.
61 - RMW operations that are conditional are fully ordered.
68 the same barriers as for atomic_t are used, see atomic_t.txt.
|
| D | atomic_t.txt | 5 RMW operations between CPUs (atomic operations on MMIO are not supported and
82 The non-RMW ops are (typically) regular LOADs and STOREs and are canonically
86 and are doing it wrong.
91 C Atomic-RMW-ops-are-atomic-WRT-atomic_set
142 these are limited to the arithmetic operations because those are
143 reversible. Bitops are irreversible and therefore the modified value
150 - misc; the special purpose operations that are commonly used and would,
152 are time critical and can, (typically) on LL/SC architectures, be more
155 All these operations are SMP atomic; that is, the operations (for a single
165 - non-RMW operations are unordered;
[all …]
|
| /Documentation/networking/ |
| D | ipv6.rst | 8 Options for the ipv6 module are supplied as parameters at load time.
11 or modprobe command, but are usually specified in either
15 The available ipv6 module parameters are listed below. If a parameter
18 The parameters are as follows:
25 IPv6 addresses or operations are desired.
27 The possible values and their effects are:
49 The possible values and their effects are:
65 This might be used when no IPv6 addresses are desired.
67 The possible values and their effects are:
|
| D | tcp-thin.rst | 10 retransmission mechanisms of the transport protocol are not fully
14 the service quality. Extreme latencies are caused by TCP's
25 In order to reduce application-layer latency when packets are lost,
28 the retransmission mechanisms are modified in the following manner:
33 These enhancements are applied only if the stream is detected as
35 of packets in flight. If there are less than 4 packets in flight,
39 Since these mechanisms are targeted at time-dependent applications,
43 modifications are turned off by default.
|
| /Documentation/core-api/ |
| D | tracepoint.rst | 11 Tracepoints are static probe points that are located in strategic points
13 a callback mechanism. The 'probes' are strictly typed functions that are
17 debug, and understand kernel behavior. There are a number of tools that
21 Tracepoints are defined in a number of header files via various macros.
24 tracepoints are available but also to understand where future
28 ``trace_tracepointname(function parameters)``. These are the tracepoints
29 callbacks that are found throughout the code. Registering and
|
| D | this_cpu_ops.rst | 8 this_cpu operations are a way of optimizing access to per cpu
18 This means that there are no atomicity issues between the calculation of
24 Read-modify-write operations are of particular interest. Frequently
32 synchronization is not necessary since we are dealing with per cpu
34 processor should be accessing that variable and therefore there are no
37 Please note that accesses by remote processors to a per cpu area are
45 are defined. These operations can be used without worrying about
115 the value of the individual counters for each processor are
119 Per cpu variables are used for performance reasons. Bouncing cache
189 Operations on these fields are straightforward::
[all …]
|
| /Documentation/livepatch/ |
| D | livepatch.rst | 15 There are many situations where users are reluctant to reboot a system. It may
26 There are multiple mechanisms in the Linux kernel that are directly related
30 - The kernel probes are the most generic. The code can be redirected by
39 are in any way modified.
43 Most of these problems are solved by using the dynamic ftrace framework as
46 a live patch is called with the help of a custom ftrace handler. But there are
53 Functions are there for a reason. They take some input parameters, acquire or
60 Most of these changes are self contained and the function presents itself
64 But there are more complex fixes. For example, a patch might change
70 when it is safe to do so, e.g. when the affected locks are released
[all …]
|
| /Documentation/usb/ |
| D | functionfs-desc.rst | 5 Some of the descriptors that can be written to the FFS gadget are
6 described below. Device and configuration descriptors are handled
7 by the composite gadget and are not written by the user to the
10 Descriptors are written to the "ep0" file in the FFS gadget
21 descriptors are accepted.
26 Class-specific descriptors are accepted only for the class/subclass of the
27 most recent interface descriptor. The following are some of the
28 class-specific descriptors that are supported.
|
| /Documentation/admin-guide/device-mapper/ |
| D | statistics.rst | 6 regions of a DM device. If no regions are defined no statistics are
8 devices are currently supported.
14 The I/O statistics counters for each step-sized area of a region are
16 Documentation/admin-guide/iostats.rst). But two extra counters (12 and 13) are
22 The reported times are in milliseconds and the granularity depends on
24 reported times are in nanoseconds.
65 The following optional arguments are supported:
70 used, the resulting times are in nanoseconds instead of
71 milliseconds. Precise timestamps are a little bit slower
75 numbers n1, n2, etc are times that represent the boundaries
[all …]
|
| /Documentation/devicetree/bindings/ |
| D | writing-schema.rst | 6 Devicetree bindings are written using json-schema vocabulary. Schema files are
18 top-level json-schema properties used are:
48 schema. By default, without 'select', nodes are matched against their possible
58 binding. The exact schema syntax depends on whether properties are known,
59 common properties (e.g. 'interrupts') or are binding/vendor-specific
68 Optional. Similar to 'properties', but names are regex.
79 being objects, are supposed to have one as well.
91 schemas are supposed to be referenced by other schemas, which then use
100 Unless noted otherwise, all properties are required.
107 vocabulary for that property. The properties schemas are what are used for
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | suspend-flows.rst | 26 different sleep states of the system are quite similar, but there are some
36 states are mostly identical, so they both together will be referred to as
45 The following steps are taken in order to transition the system from the working
58 Tasks are frozen primarily in order to avoid unchecked hardware accesses
64 All user space tasks are intercepted as though they were sent a signal and
69 specific reasons are frozen subsequently, but they are not intercepted.
70 Instead, they are expected to periodically check whether or not they need
79 Devices are suspended in four phases called *prepare*, *suspend*,
87 phase and high-level ("action") interrupt handlers are prevented from being
90 Interrupts are still handled after that, but they are only acknowledged to
[all …]
|
| /Documentation/admin-guide/perf/ |
| D | arm-cmn.rst | 7 device ports to which various AMBA CHI agents are attached.
25 Most events are specified in a format based directly on the TRM
31 are treated as the same type (0xa), and the common event templates are
39 register. The event templates are named with prefixes to cover all
51 traffic. Watchpoints are treated as a synthetic event type, and like PMU
54 register selection, separate events are provided for flit uploads and
57 The flit match value and mask are passed in config1 and config2 ("val"
59 "wp_exclusive" are specified per the TRM definitions for dtm_wp_config0.
64 Watchpoint events with a "combine" value of 0 are considered independent
|
| /Documentation/virt/kvm/arm/ |
| D | pkvm.rst | 18 of the host kernel running at EL1 and therefore additional hypercalls are
37 whether they are spawned in protected state. It is therefore recommended only
38 to enable pKVM if protected VMs are required, with non-protected state acting
53 - Read-only memslots are unsupported and therefore dirty logging cannot be
59 - There are probably many others.
65 If you are not happy with these limitations, then please don't enable pKVM :)
74 Protected VMs are instantiated according to a fixed vCPU configuration
77 features that may be available to the host are exposed to the guest and the
78 capabilities advertised by ``KVM_CHECK_EXTENSION`` are limited accordingly,
83 are reset to zero with the exception of the PC and X0 which can be set
[all …]
|
| /Documentation/rust/ |
| D | testing.rst | 9 There are three sorts of tests:
18 These are the tests that come from the examples in the Rust documentation. They
43 KUnit tests are documentation tests
46 These documentation tests are typically examples of usage of any item (e.g.
49 They are very convenient because they are just written alongside the
63 In userspace, the tests are collected and run via ``rustdoc``. Using the tool
65 (thus enforcing they are kept in sync with the code they document) and as well
94 operator are also supported as usual, e.g.:
104 The tests are also compiled with Clippy under ``CLIPPY=1``, just like normal
124 actually failed. Additionally, doctests are not run for nonpublic functions.
[all …]
|
| /Documentation/security/ |
| D | lsm.rst | 11 The APIs described in this book are outdated.
65 of security modules that are active on the system.
67 The LSM security fields are simply ``void*`` pointers.
70 Security blobs that are used by more than one security module are
73 program execution security information, security fields are included in
79 information, security fields are included in :c:type:`struct inode
95 32-bit integer. The security modules are required to map or otherwise
98 LSM hooks are maintained in lists. A list is maintained for each
99 hook, and the hooks are called in the order specified by CONFIG_LSM.
107 which are added to the lists.
[all …]
|
| /Documentation/ABI/ |
| D | README | 10 The different levels of stability are:
14 defined to be stable. Userspace programs are free to use these
17 (like syscalls) are expected to never change and always be
21 This directory documents interfaces that are felt to be stable,
25 errors or security problems are found in them. Userspace
28 be marked stable. Programs that use these interfaces are
35 This directory documents interfaces that are still remaining in
36 the kernel, but are marked to be removed at some later point in
55 break in ways that are unacceptable. It is also
57 sure they are working in a proper way and do not need to
[all …]
|
| /Documentation/driver-api/ |
| D | spi.rst | 10 another is shifted in on the MISO line. Those bits are assembled into
12 additional chipselect line is usually active-low (nCS); four signals are
18 only "master" side interfaces are supported, where Linux talks to SPI
29 <spi_controller>`. SPI devices are children of that master,
32 <spi_board_info>` descriptors which are usually provided by
39 which are processed and completed asynchronously. (There are synchronous
40 wrappers, however.) Messages are built from one or more
43 options are needed, because different chips adopt very different
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-iio-sx9324 | 15 (PH0, PH1, PH2, PH3), where the inputs are configured
19 while CS1 and CS2 are used as shields.
21 [PH1], CS1 is measured, CS0 and CS2 are shield:
23 [PH2], CS2 is measured, CS0 and CS1 are shield:
25 [PH3], CS1 and CS2 are measured (combo mode):
28 Note, these are the chip default. Hardware layout will most
|
| D | dev-kmsg | 35 records are available read() will block, or if O_NONBLOCK is
39 there are never partial messages received by read().
62 Other seek operations or offsets are not supported because of
64 or write only whole variable length messages (records) that are
67 Because of the non-standard behavior also the error values are
70 and values are historical and could not be modified without the
76 and a flag field. All fields are separated by a ','.
84 hardware or other facilities are printed, therefore
86 are escaped by "\x00" C-style hex encoding.
112 lines are not necessarily correct, and the stream could be
[all …]
|
| /Documentation/devicetree/bindings/clock/ |
| D | stericsson,u8500-clks.yaml | 13 description: While named "U8500 clocks" these clocks are inside the
16 itself, not off-chip clocks. There are four different on-chip
52 which PRCC block the consumer wants to use, possible values are 1, 2, 3,
54 wants, possible values are 0 thru 31.
66 block the consumer wants to use, possible values are 1, 2, 3, 5, 6. The
68 values are 0 thru 31.
80 which PRCC block the consumer wants to use, possible values are 1, 2, 3
82 it wants to control, possible values are 0 thru 31.
114 output clocks. These are two PRCMU-internal clocks that can be divided and
121 The first cell indicates which output clock we are using,
[all …]
|