Documentation/input/devices/iforce-protocol.rst
Source file repositories/reference/linux-study-clean/Documentation/input/devices/iforce-protocol.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/input/devices/iforce-protocol.rst- Extension
.rst- Size
- 8670 bytes
- Lines
- 382
- 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
===============
Iforce Protocol
===============
:Author: Johann Deneux <johann.deneux@gmail.com>
Home page at `<http://web.archive.org/web/*/http://www.esil.univ-mrs.fr>`_
:Additions: by Vojtech Pavlik.
Introduction
============
This document describes what I managed to discover about the protocol used to
specify force effects to I-Force 2.0 devices. None of this information comes
from Immerse. That's why you should not trust what is written in this
document. This document is intended to help understanding the protocol.
This is not a reference. Comments and corrections are welcome. To contact me,
send an email to: johann.deneux@gmail.com
.. warning::
I shall not be held responsible for any damage or harm caused if you try to
send data to your I-Force device based on what you read in this document.
Preliminary Notes
=================
All values are hexadecimal with big-endian encoding (msb on the left). Beware,
values inside packets are encoded using little-endian. Bytes whose roles are
unknown are marked ??? Information that needs deeper inspection is marked (?)
General form of a packet
------------------------
This is how packets look when the device uses the rs232 to communicate.
== == === ==== ==
2B OP LEN DATA CS
== == === ==== ==
CS is the checksum. It is equal to the exclusive or of all bytes.
When using USB:
== ====
OP DATA
== ====
The 2B, LEN and CS fields have disappeared, probably because USB handles
frames and data corruption is handled or insignificant.
First, I describe effects that are sent by the device to the computer
Device input state
==================
This packet is used to indicate the state of each button and the value of each
axis::
OP= 01 for a joystick, 03 for a wheel
LEN= Varies from device to device
00 X-Axis lsb
01 X-Axis msb
02 Y-Axis lsb, or gas pedal for a wheel
03 Y-Axis msb, or brake pedal for a wheel
04 Throttle
05 Buttons
06 Lower 4 bits: Buttons
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.