Searched full:report (Results 1 – 25 of 394) sorted by relevance
12345678910>>...16
| /Documentation/hid/ |
| D | hidraw.rst | 16 which send and receive data in a way that is inconsistent with their report
18 through it, checking them against the device's report descriptor, such
44 read() will read a queued report received from the HID device. On USB
47 a report available to be read. read() can be made non-blocking, by passing
52 will be the report number; the report data follows, beginning in the second
53 byte. For devices which do not use numbered reports, the report data
58 The write() function will write a report to the device. For USB devices, if
59 the device has an INTERRUPT OUT endpoint, the report will be sent on that
60 endpoint. If it does not, the report will be sent over the control endpoint,
63 The first byte of the buffer passed to write() should be set to the report
[all …]
|
| D | hiddev.rst | 74 bundles called "reports". Each report is divided into "fields",
82 it performs an interrupt transfer containing a report which contains
83 the changed value. The hid-core.c module parses the report, and
85 the report. In its basic mode, the hiddev will make these individual
149 Instructs the kernel to retrieve all input and feature report values
164 Instructs the kernel to get a feature or input report from the device,
171 Instructs the kernel to send a report to the device. This report can
173 individual usage values in the report before sending the report in full
179 Fills in a hiddev_report_info structure for the user. The report is
182 report id as reported by the device -- or relative --
[all …]
|
| D | hidintro.rst | 4 Introduction to HID report descriptors
7 This chapter is meant to give a broad overview of what HID report
36 through the *HID report descriptor*, a fixed set of bytes describing
39 a HID Report Descriptor may specify that "in a report with ID 3 the
42 The HID report itself then merely carries the actual data values
48 The HID subsystem is in charge of parsing the HID report descriptors,
51 HID report descriptor provided by the device is wrong, or because it
55 The format of HID report descriptors is described by two documents,
66 Parsing HID report descriptors
71 one can read the corresponding report descriptor::
[all …]
|
| D | hid-transport.rst | 17 report-parsing, report interpretation and the user-space API. Device specifics
101 channel. Any unrequested incoming or outgoing data report must be sent on
115 report can be of one of three types:
117 - INPUT Report: Input reports provide data from device to host. This
122 - OUTPUT Report: Output reports change device states. They are sent from host
128 - FEATURE Report: Feature reports are used for specific static device features
132 or retrieve a feature report. This also means, feature reports are never sent
145 - GET_REPORT: A GET_REPORT request has a report ID as payload and is sent
146 from host to device. The device must answer with a data report for the
147 requested report ID on the ctrl channel as a synchronous acknowledgement.
[all …]
|
| D | hid-sensor.rst | 6 a report descriptor conforming to HID 1.12 sensor usage tables.
17 data fields. The length and order is specified in the report descriptor. For
18 example a part of report descriptor can look like::
28 Report Size(8)
29 Report Count(1)
30 Report Offset(16)
35 The report is indicating "sensor page (0x20)" contains an accelerometer-3D (0x73).
57 report descriptors and identifies all the sensors present. It adds an MFD device
70 functions, which get and set each input/feature/output report.
76 the report and get the indexes of the fields and also can get events. This driver
[all …]
|
| D | hid-bpf.rst | 41 Simple fixup of report descriptor
45 in the report descriptor. These fixes all require a kernel patch and the
117 Thus, all of the parsing of the HID report and the HID report descriptor
159 3. change of the report descriptor with ``SEC("struct_ops/hid_rdesc_fixup")`` or
172 change the report descriptor from the BPF program. Once a ``hid_rdesc_fixup``
221 1. for a given device, if we know that the report length will always be of a certain value,
222 we can request the ``data`` pointer to point at the full report length.
235 2. if the report length is variable, but we know the value of ``X`` is always a 16-bit
298 content of the report descriptor. The memory associated with that buffer is
302 modified content and size as the report descriptor.
[all …]
|
| D | amd-sfh-hid.rst | 31 | with HID Report Generator|
61 enumeration of each sensor, client layer fills the HID Descriptor structure and HID input report
62 structure. HID Feature report structure is optional. The report descriptor structure varies from
99 | | | Create Input report | | |
134 | | report | | |
139 | | | report | | |
142 | | in HID report| | |
|
| D | hid-alps.rst | 26 4 wReportDescLength 00B2 Report Descriptor is 178 Bytes (0x00B2)
27 6 wReportDescRegister 0002 Identifier to read Report Descriptor
28 8 wInputRegister 0003 Identifier to read Input Report
29 10 wMaxInputLength 0053 Input Report is 80 Bytes + 2
30 12 wOutputRegister 0000 Identifier to read Output Report
41 Report ID
|
| /Documentation/ABI/testing/ |
| D | configfs-tsm | 1 What: /sys/kernel/config/tsm/report/$name/inblob
10 What: /sys/kernel/config/tsm/report/$name/outblob
15 (RO) Binary attestation report generated from @inblob and other
16 options The format of the report is implementation specific
20 What: /sys/kernel/config/tsm/report/$name/auxblob
34 What: /sys/kernel/config/tsm/report/$name/manifestblob
46 What: /sys/kernel/config/tsm/report/$name/provider
64 What: /sys/kernel/config/tsm/report/$name/generation
73 @outblob, or it can prevent conflicts by creating a report
76 What: /sys/kernel/config/tsm/report/$name/privlevel
[all …]
|
| D | sysfs-kernel-wakeup_reasons | 6 used to report wakeup reasons after system exited suspend.
13 used to report time spent in last suspend cycle. It contains
|
| D | configfs-usb-gadget-hid | 9 report_desc blob corresponding to HID report descriptors
11 report_length HID report length
|
| /Documentation/devicetree/bindings/power/supply/ |
| D | maxim,max17042.yaml | 41 Temperature threshold to report battery as cold (in tenths of degree Celsius).
42 Default is not to report cold events.
47 Temperature threshold to report battery as over heated (in tenths of degree Celsius).
48 Default is not to report over heating events.
53 Voltage threshold to report battery as dead (in mV).
54 Default is not to report dead battery events.
59 Voltage threshold to report battery as over voltage (in mV).
60 Default is not to report over-voltage events.
|
| /Documentation/netlink/specs/ |
| D | binder.yaml | 13 name: report
15 Attributes included within a transaction failure report. The elements
68 name: report
71 binder transaction failures. The generated report provides the full
75 attribute-set: report
76 mcgrp: report
93 name: report
|
| /Documentation/usb/ |
| D | gadget_hid.rst | 108 Hit return and the corresponding report will be sent by the
112 --caps-lock and hit return. A report is then sent by the
117 recv report:2
193 int keyboard_fill_report(char report[8], char buf[BUF_LEN], int *hold)
212 report[2 + key++] = kval[i].val;
221 report[2 + key++] = (tok[0] - ('a' - 0x04));
227 report[0] = report[0] | kmod[i].val;
246 int mouse_fill_report(char report[8], char buf[BUF_LEN], int *hold)
263 report[0] = report[0] | mmod[i].val;
271 report[1 + mvt++] = (char)strtol(tok, NULL, 0);
[all …]
|
| /Documentation/admin-guide/ |
| D | reporting-issues.rst | 16 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
27 <https://kernel.org/>`_. If the issue is present there, send a report.
40 If you are facing multiple issues with the Linux kernel at once, report each
41 separately. While writing your report, include all information relevant to the
43 regressions mailing list (regressions@lists.linux.dev) to your report. Also try
47 Once the report is out, answer any questions that come up and help where you
51 Step-by-step guide how to report issues to the kernel maintainers
54 The above TL;DR outlines roughly how to report issues to the Linux kernel
112 join the discussion instead of sending a new report.
123 increase the risk your report will be rejected or ignored.
[all …]
|
| D | reporting-regressions.rst | 24 #. Report your issue as outlined in Documentation/admin-guide/reporting-issues.rst,
26 below for convenience. Two of them are important: start your report's subject
30 #. Optional, but recommended: when sending or forwarding your report, make the
73 How do I report a regression?
76 Just report the issue as outlined in
85 * Start your report's subject with "[REGRESSION]".
87 * In your report, clearly mention the last kernel version that worked fine and
92 (regressions@lists.linux.dev) know about your report:
94 * If you report the regression by mail, CC the regressions list.
96 * If you report your regression to some bug tracker, forward the submitted
[all …]
|
| /Documentation/dev-tools/ |
| D | coccinelle.rst | 78 Four basic modes are defined: ``patch``, ``report``, ``context``, and
84 - ``report`` generates a list in the following format:
90 - ``org`` generates a report in the Org mode format of Emacs.
93 of Coccinelle, the default mode is "report".
99 - ``rep+ctxt`` runs successively the report mode and the context mode.
106 To make a report for every semantic patch, run the following command::
108 make coccicheck MODE=report
128 make coccicheck MODE=report V=1
136 make coccicheck MODE=report J=4
164 make coccicheck COCCI=<my_SP.cocci> MODE=report
[all …]
|
| D | kasan.rst | 104 When it is enabled, KASAN panics the kernel after printing a bug report.
106 By default, KASAN prints a bug report only for the first invalid memory access.
107 With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
113 - ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls whether
114 to only print a KASAN report, panic the kernel, or panic the kernel on
115 invalid writes only (default: ``report``). The panic happens even if
169 A typical KASAN report looks like this::
242 The report header summarizes what kind of bug happened and what kind of access
246 bug report). Next comes a description of the accessed slab object and the
249 In the end, the report shows the memory state around the accessed address.
[all …]
|
| /Documentation/virt/coco/ |
| D | sev-guest.rst | 22 This section describes ioctls that is used for querying the SEV guest report
95 The SNP_GET_REPORT ioctl can be used to query the attestation report from the
97 provided by the SEV-SNP firmware to query the attestation report.
99 On success, the snp_report_resp.data will contains the report. The report
130 related to the additional certificate data that is returned with the report.
135 firmware to get the attestation report.
137 On success, the snp_ext_report_resp.data will contain the attestation report
174 reported TCB version in the attestation report. The command is similar
186 When requesting an attestation report a guest is able to specify whether
187 it wants SNP firmware to sign the report using either a Versioned Chip
[all …]
|
| /Documentation/mm/ |
| D | free_page_reporting.rst | 12 field within the structure it will populate is the "report" function
26 While pages are being processed by the report function they will not be
27 accessible to the allocator. Once the report function has been completed
|
| /Documentation/input/ |
| D | gamepad.rst | 12 document defines how gamepads are supposed to report their data.
79 All new gamepads are supposed to comply with this mapping. Please report any
89 devices that report a small subset of the events.
91 No other devices, that do not look/feel like a gamepad, shall report these
97 Gamepads report the following events:
107 want to filter gamepads that do not report all four.
134 may even report both. The kernel does not convert between these so
|
| D | event-codes.rst | 270 Upon binding to a device or resuming from suspend, a driver must report
288 - Used to report the number of microseconds since the last reset. This event
397 accelerometer data. Some devices also report gyroscope data, which devices
398 can report through the rotational axes (absolute and/or relative rx, ry, rz).
413 REL_{X,Y} must be reported when the mouse moves. BTN_LEFT must be used to report
414 the primary button press. BTN_{MIDDLE,RIGHT,4,5,etc.} should be used to report
415 further buttons of the device. REL_WHEEL and REL_HWHEEL should be used to report
422 used to report when a touch is active on the screen.
431 Legacy trackpads that only provide relative position information must report
434 Trackpads that provide absolute touch position must report ABS_{X,Y} for the
[all …]
|
| /Documentation/process/ |
| D | security-bugs.rst | 8 disclosed as quickly as possible. Please report security bugs to the
16 who will help verify the bug report and develop and release a fix.
17 If you already have a fix, please include it with your report, as
57 reporter. This includes but is not limited to the original bug report
63 of the report are treated confidentially even after the embargo has been
|
| /Documentation/devicetree/bindings/net/ |
| D | allwinner,sun4i-a10-mdio.yaml | 17 # will be able to report a warning when we have that compatible, since
18 # we will validate the node thanks to the select, but won't report it
|
| /Documentation/networking/devlink/ |
| D | iosm.rst | 108 * - ``report.json``
128 $ devlink region new pci/0000:02:00.0/report.json
130 $ devlink region dump pci/0000:02:00.0/report.json snapshot 0
132 $ devlink region del pci/0000:02:00.0/report.json snapshot 0
|
12345678910>>...16