drivers/hid/hid-input.c
Source file repositories/reference/linux-study-clean/drivers/hid/hid-input.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/hid/hid-input.c- Extension
.c- Size
- 70789 bytes
- Lines
- 2455
- Domain
- Driver Families
- Bucket
- drivers/hid
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/module.hlinux/slab.hlinux/kernel.hlinux/hid.hlinux/hid-debug.hhid-ids.hhid-input-test.c
Detected Declarations
struct usage_priorityfunction match_scancodefunction match_keycodefunction match_indexfunction list_for_each_entryfunction hidinput_getkeycodefunction hidinput_setkeycodefunction hidinput_calc_abs_resfunction find_battery_quirkfunction hidinput_scale_battery_capacityfunction hidinput_query_battery_capacityfunction hidinput_get_battery_propertyfunction list_for_each_entryfunction hidinput_cleanup_batteryfunction hidinput_setup_batteryfunction hidinput_update_battery_charge_statusfunction hidinput_update_batteryfunction hidinput_setup_batteryfunction hidinput_update_batteryfunction hidinput_configure_usagefunction eraserfunction thisfunction hidinput_hid_eventfunction hidinput_handle_scrollfunction hid_report_release_toolfunction hid_report_set_toolfunction hidinput_hid_eventfunction hidinput_report_eventfunction hidinput_find_fieldfunction list_for_each_entryfunction list_for_each_entryfunction hidinput_count_ledsfunction list_for_each_entryfunction hidinput_led_workerfunction hidinput_input_eventfunction hidinput_openfunction hidinput_closefunction __hidinput_change_resolution_multipliersfunction hidinput_change_resolution_multipliersfunction report_featuresfunction hidinput_has_been_populatedfunction hidinput_cleanup_hidinputfunction list_for_each_entryfunction list_for_each_entryfunction list_for_each_entryfunction hidinput_configure_usagesfunction hidinput_connectfunction list_for_each_entry
Annotated Snippet
struct usage_priority {
__u32 usage; /* the HID usage associated */
bool global; /* we assume all usages to be slotted,
* unless global
*/
unsigned int slot_overwrite; /* for globals: allows to set the usage
* before or after the slots
*/
};
/*
* hid-input will convert this list into priorities:
* the first element will have the highest priority
* (the length of the following array) and the last
* element the lowest (1).
*
* hid-input will then shift the priority by 8 bits to leave some space
* in case drivers want to interleave other fields.
*
* To accommodate slotted devices, the slot priority is
* defined in the next 8 bits (defined by 0xff - slot).
*
* If drivers want to add fields before those, hid-input will
* leave out the first 8 bits of the priority value.
*
* This still leaves us 65535 individual priority values.
*/
static const struct usage_priority hidinput_usages_priorities[] = {
{ /* Eraser (eraser touching) must always come before tipswitch */
.usage = HID_DG_ERASER,
},
{ /* Invert must always come before In Range */
.usage = HID_DG_INVERT,
},
{ /* Is the tip of the tool touching? */
.usage = HID_DG_TIPSWITCH,
},
{ /* Tip Pressure might emulate tip switch */
.usage = HID_DG_TIPPRESSURE,
},
{ /* In Range needs to come after the other tool states */
.usage = HID_DG_INRANGE,
},
};
#define map_abs(c) hid_map_usage(hidinput, usage, &bit, &max, EV_ABS, (c))
#define map_rel(c) hid_map_usage(hidinput, usage, &bit, &max, EV_REL, (c))
#define map_key(c) hid_map_usage(hidinput, usage, &bit, &max, EV_KEY, (c))
#define map_led(c) hid_map_usage(hidinput, usage, &bit, &max, EV_LED, (c))
#define map_msc(c) hid_map_usage(hidinput, usage, &bit, &max, EV_MSC, (c))
#define map_abs_clear(c) hid_map_usage_clear(hidinput, usage, &bit, \
&max, EV_ABS, (c))
#define map_key_clear(c) hid_map_usage_clear(hidinput, usage, &bit, \
&max, EV_KEY, (c))
static bool match_scancode(struct hid_usage *usage,
unsigned int cur_idx, unsigned int scancode)
{
return (usage->hid & (HID_USAGE_PAGE | HID_USAGE)) == scancode;
}
static bool match_keycode(struct hid_usage *usage,
unsigned int cur_idx, unsigned int keycode)
{
/*
* We should exclude unmapped usages when doing lookup by keycode.
*/
return (usage->type == EV_KEY && usage->code == keycode);
}
static bool match_index(struct hid_usage *usage,
unsigned int cur_idx, unsigned int idx)
{
return cur_idx == idx;
}
typedef bool (*hid_usage_cmp_t)(struct hid_usage *usage,
unsigned int cur_idx, unsigned int val);
static struct hid_usage *hidinput_find_key(struct hid_device *hid,
hid_usage_cmp_t match,
unsigned int value,
unsigned int *usage_idx)
{
unsigned int i, j, k, cur_idx = 0;
struct hid_report *report;
struct hid_usage *usage;
for (k = HID_INPUT_REPORT; k <= HID_OUTPUT_REPORT; k++) {
Annotation
- Immediate include surface: `linux/module.h`, `linux/slab.h`, `linux/kernel.h`, `linux/hid.h`, `linux/hid-debug.h`, `hid-ids.h`, `hid-input-test.c`.
- Detected declarations: `struct usage_priority`, `function match_scancode`, `function match_keycode`, `function match_index`, `function list_for_each_entry`, `function hidinput_getkeycode`, `function hidinput_setkeycode`, `function hidinput_calc_abs_res`, `function find_battery_quirk`, `function hidinput_scale_battery_capacity`.
- Atlas domain: Driver Families / drivers/hid.
- Implementation status: integration implementation candidate.
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.