Documentation/ABI/testing/sysfs-driver-hid-wiimote
Source file repositories/reference/linux-study-clean/Documentation/ABI/testing/sysfs-driver-hid-wiimote
File Facts
- System
- Linux kernel
- Corpus path
Documentation/ABI/testing/sysfs-driver-hid-wiimote- Extension
[no extension]- Size
- 3770 bytes
- Lines
- 86
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: Documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
What: /sys/bus/hid/drivers/wiimote/<dev>/led1
What: /sys/bus/hid/drivers/wiimote/<dev>/led2
What: /sys/bus/hid/drivers/wiimote/<dev>/led3
What: /sys/bus/hid/drivers/wiimote/<dev>/led4
Date: July 2011
KernelVersion: 3.1
Contact: David Herrmann <dh.herrmann@googlemail.com>
Description: Make it possible to set/get current led state. Reading from it
returns 0 if led is off and 1 if it is on. Writing 0 to it
disables the led, writing 1 enables it.
What: /sys/bus/hid/drivers/wiimote/<dev>/extension
Date: August 2011
KernelVersion: 3.2
Contact: David Herrmann <dh.herrmann@gmail.com>
Description: This file contains the currently connected and initialized
extensions. It can be one of: none, motionp, nunchuck, classic,
motionp+nunchuck, motionp+classic
motionp is the official Nintendo Motion+ extension, nunchuck is
the official Nintendo Nunchuck extension and classic is the
Nintendo Classic Controller extension. The motionp extension can
be combined with the other two.
Starting with kernel-version 3.11 Motion Plus hotplugging is
supported and if detected, it's no longer reported as static
extension. You will get uevent notifications for the motion-plus
device then.
What: /sys/bus/hid/drivers/wiimote/<dev>/devtype
Date: May 2013
KernelVersion: 3.11
Contact: David Herrmann <dh.herrmann@gmail.com>
Description: While a device is initialized by the wiimote driver, we perform
a device detection and signal a "change" uevent after it is
done. This file shows the detected device type. "pending" means
that the detection is still ongoing, "unknown" means, that the
device couldn't be detected or loaded. "generic" means, that the
device couldn't be detected but supports basic Wii Remote
features and can be used.
Other strings for each device-type are available and may be
added if new device-specific detections are added.
Currently supported are:
============= =======================================
gen10: First Wii Remote generation
gen20: Second Wii Remote Plus generation
(builtin MP)
balanceboard: Wii Balance Board
============= =======================================
What: /sys/bus/hid/drivers/wiimote/<dev>/bboard_calib
Date: May 2013
KernelVersion: 3.11
Contact: David Herrmann <dh.herrmann@gmail.com>
Description: This attribute is only provided if the device was detected as a
balance board. It provides a single line with 3 calibration
values for all 4 sensors. The values are separated by colons and
are each 2 bytes long (encoded as 4 digit hexadecimal value).
First, 0kg values for all 4 sensors are written, followed by the
17kg values for all 4 sensors and last the 34kg values for all 4
sensors.
Calibration data is already applied by the kernel to all input
values but may be used by user-space to perform other
transformations.
What: /sys/bus/hid/drivers/wiimote/<dev>/pro_calib
Date: October 2013
KernelVersion: 3.13
Contact: David Herrmann <dh.herrmann@gmail.com>
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.