Searched full:are (Results 1 – 25 of 2700) sorted by relevance
12345678910>>...108
| /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/networking/ |
| D | ipv6.txt | 2 Options for the ipv6 module are supplied as parameters at load time.
5 or modprobe command, but are usually specified in either
9 The available ipv6 module parameters are listed below. If a parameter
12 The parameters are as follows:
19 IPv6 addresses or operations are desired.
21 The possible values and their effects are:
43 The possible values and their effects are:
59 This might be used when no IPv6 addresses are desired.
61 The possible values and their effects are:
|
| D | tcp-thin.txt | 6 retransmission mechanisms of the transport protocol are not fully
10 the service quality. Extreme latencies are caused by TCP's
21 In order to reduce application-layer latency when packets are lost,
24 the retransmission mechanisms are modified in the following manner:
29 These enhancements are applied only if the stream is detected as
31 of packets in flight. If there are less than 4 packets in flight,
35 Since these mechanisms are targeted at time-dependent applications,
39 modifications are turned off by default.
|
| /Documentation/media/uapi/v4l/ |
| D | colorspaces.rst | 27 the human eye has color receptors that are sensitive to three different
29 color. Be glad you are not a mantis shrimp as those are sensitive to 12
34 color receptors are stimulated. This is based on the Spectral Power
42 those receptors and are perceived as the same color, even though the SPD
50 After some further mathematical transforms these stimuli are known as
52 color as perceived by a human unambiguously. These X, Y and Z values are
63 The x and y values are the chromaticity coordinates and can be used to
66 colors are specified with lower case 'x' and 'y', then the CIE xyY
71 will find reading resources that go into much more detail if you are
78 phosphors used in the displays. These *color primaries* are part of what
[all …]
|
| D | pixfmt-intro.rst | 20 V4L2 drivers are not limited to these formats, however. Driver-specific
21 formats are possible. In that case the application may depend on a codec
29 Even so, ultimately, some standard formats are needed, so the V4L2
33 The V4L2 standard formats are mainly uncompressed formats. The pixels
34 are always arranged in memory from left to right, and from top to
47 :ref:`four character (FourCC) codes <v4l2-fourcc>` which are also
48 listed below, however they are not the same as those used in the Windows
52 buffers. Those formats are identified by a separate set of FourCC codes
53 and are referred to as "multi-planar formats". For example, a
58 3-planar case. Those sub-buffers are referred to as "*planes*".
|
| /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 unordered on FAILURE,
70 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.
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;
167 - RMW operations that have no return value are unordered;
[all …]
|
| D | this_cpu_ops.txt | 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
116 the value of the individual counters for each processor are
120 Per cpu variables are used for performance reasons. Bouncing cache
190 Operations on these fields are straightforward::
[all …]
|
| /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
|
| /Documentation/livepatch/ |
| D | livepatch.rst | 28 There are many situations where users are reluctant to reboot a system. It may
39 There are multiple mechanisms in the Linux kernel that are directly related
43 - The kernel probes are the most generic. The code can be redirected by
52 are in any way modified.
56 Most of these problems are solved by using the dynamic ftrace framework as
59 a live patch is called with the help of a custom ftrace handler. But there are
66 Functions are there for a reason. They take some input parameters, get or
73 Most of these changes are self contained and the function presents itself
77 But there are more complex fixes. For example, a patch might change
83 when it is safe to do so, e.g. when the affected locks are released
[all …]
|
| /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/ |
| D | writing-schema.rst | 6 Devicetree bindings are written using json-schema vocabulary. Schema files are
16 top-level json-schema properties used are:
46 schema. By default without 'select', nodes are matched against their possible
56 binding. The exact schema syntax depends on whether properties are known,
57 common properties (e.g. 'interrupts') or are binding/vendor specific properties.
65 Optional. Similar to 'properties', but names are regex.
75 Unless noted otherwise, all properties are required.
82 vocabulary for that property. The properties schemas are what is used for
86 binding schema need to be defined such as how many values are valid or what
87 possible values are valid.
[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/filesystems/ |
| D | ext2.txt | 8 filesystem in use by Linux. There are also implementations available
14 Most defaults are determined by the filesystem superblock, and can be
15 set using tune2fs(8). Kernel-determined defaults are indicated by (*).
75 compression though these are not yet implemented (some are available as
83 The space in the device or file is split up into blocks. These are
92 Blocks are clustered into block groups in order to reduce fragmentation
96 Two blocks near the start of each group are reserved for the block usage
98 are in use. Since each bitmap is limited to a single block, this means
101 The block(s) following the bitmaps in each block group are designated
102 as the inode table for that block group and the remainder are the data
[all …]
|
| D | squashfs.txt | 6 directories. Inodes in the system are very small and all blocks are packed to
7 minimise data overhead. Block sizes greater than 4K are supported up to a
45 directory data are highly compacted, and packed on byte boundaries. Each
94 Compressed data blocks are written to the filesystem as files are read from
97 xattr tables are written.
104 these are stored here.
109 Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each
114 Inodes are packed into the metadata blocks, and are not aligned to block
115 boundaries, therefore inodes overlap compressed blocks. Inodes are identified
120 To maximise compression there are different inodes for each file type
[all …]
|
| D | gfs2-glocks.txt | 14 are completed.
17 just the holders) associated with the glock. If there are any
19 of the list. Locks are granted in strictly the order that they
20 are queued, except for those marked LM_FLAG_PRIORITY which are
23 There are three lock states that users of the glock layer can request,
36 operations. The glocks are basically a lock plus some routines which deal
46 These rules are implemented using the various glock operations which
47 are defined for each type of glock. Not all types of glocks use
70 prevent a situation where locks are being bounced around the cluster
72 tends to show up most with shared mmaped files which are being written
[all …]
|
| D | isofs.txt | 1 Mount options that are the same as for msdos and vfat partitions.
7 Mount options that are the same as vfat partitions. These are only useful
10 ASCII. Joliet filenames are stored in Unicode format, but
31 'mode' and 'dmode' even though Rock Ridge extensions are
33 nojoliet Ignore Joliet extensions if they are present.
34 norock Ignore Rock Ridge extensions if they are present.
43 Recommended documents about ISO 9660 standard are located at:
|
| /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_master>`. 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
|
| D | device_connection.rst | 8 Devices often have connections to other devices that are outside of the direct
15 Device connections are generic descriptions of any type of connection between
19 They are only descriptions which are not tied to either of the devices directly.
28 either endpoint device in the description. If the connections are defined in
30 descriptions are "built-in", and need to be added separately.
34 is needed if there are multiple connections between the two devices.
|
| D | device-io.rst | 35 are starting with one. Physical addresses are of type unsigned long.
54 historical accident, these are named byte, word, long and quad accesses.
55 Both read and write accesses are supported; there is no prefetch support
58 The functions are named readb(), readw(), readl(), readq(),
64 :c:func:`memcpy_fromio()` and :c:func:`memset_io()` functions are
65 provided. Do not use memset or memcpy on IO addresses; they are not
68 The read and write functions are defined to be ordered. That is the
73 While the basic functions are defined to be synchronous with respect to
76 are burned by the fact that PCI bus writes are posted asynchronously. A
86 driver would like to ensure the write's effects are visible prior to
[all …]
|
| /Documentation/security/keys/ |
| D | trusted-encrypted.rst | 5 Trusted and Encrypted Keys are two new key types added to the existing kernel
6 key ring service. Both of these new types are variable length symmetric keys,
7 and in both cases all keys are created in the kernel, and user space sees,
10 Keys can be used on any system. All user level blobs, are displayed and loaded
11 in hex ascii for convenience, and are integrity verified.
13 Trusted Keys use a TPM both to generate and to seal the keys. Keys are sealed
17 (future) PCR values, so keys are easily migrated to new pcr values, such as
18 when the kernel and initramfs are updated. The same key can have many saved
19 blobs under different PCR values, so multiple boots are easily supported.
24 By default, trusted keys are sealed under the SRK, which has the default
[all …]
|
| /Documentation/vm/ |
| D | zswap.rst | 10 Zswap is a lightweight compressed cache for swap pages. It takes pages that are
14 significant performance improvement if reads from the compressed cache are
46 When zswap is disabled at runtime it will stop storing pages that are
49 pages stored in zswap will remain in the compressed pool until they are
66 pages are freed. The pool is not preallocated. By default, a zpool
90 Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
108 compressed pages are not modified; they are left in their own zpool. When a
110 original compressor. Once all pages are removed from an old zpool, the zpool
111 and its compressor are freed.
113 Some of the pages in zswap are same-value filled pages (i.e. contents of the
[all …]
|
| /Documentation/process/ |
| D | howto.rst | 31 are not a good substitute for a solid C education and/or years of
32 experience, the following books are good for, if anything, reference:
39 adheres to the ISO C89 standard, it uses a number of extensions that are
42 portions of the C standard are not supported. Arbitrary long long
43 divisions and floating point are not allowed. It can sometimes be
49 Please remember that you are trying to learn how to work with the
54 possible about these standards ahead of time, as they are well
64 rules and how to use `SPDX <https://spdx.org/>`_ identifiers in source code are
67 not ask on the Linux kernel mailing list. The people on the mailing lists are
78 The Linux kernel source tree has a large range of documents that are
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-driver-typec-displayport | 6 Valid values are USB, source and sink. Source means DisplayPort
9 All supported configurations are listed as space separated list
30 different pin assignments for USB Type-C connector that are
31 labeled A, B, C, D, E, and F. The supported pin assignments are
45 version 1.0b, pin assignments A, B, and F are deprecated. Only
48 and E are equal, where all channels on the connector are used
|
12345678910>>...108