Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

USB mouse hotplug does not work (possibly Pi-specific)

未关闭
  • 哪里不对？
#175 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
c, linux, raspberry-pi
领域
embedded-iot, operating-systems

调研方向

Start by collecting the missing reproduction details: board, whether the mouse works when connected before boot, port, and dmesg, /dev/input/, and usbconfig list output before and after plugging. Check whether devd reports the attach event; these observations distinguish USB event delivery, devd, and userland input handling. No code files or tests are identified, and done means locating which layer fails and recording enough evidence to route the issue appropriately.

由索引模型根据 Issue 内容生成。

描述

area:rpi5 bug

Placeholder so this is not lost. Reported informally; symptom details not yet
captured — see "What to record" below before investigating.

Report

A USB mouse hotplugged after boot does not work. Possibly Raspberry Pi specific.

What is already ruled out

Not a missing driver. The HID input stack is compiled into the shipping config
(config/NEXTBSD, inherited by NEXTBSD-RPI5 via include NEXTBSD):

device  hms        # hidbus mouse leaf: relative mice and absolute pointers
device  hidmap     # usage->evdev mapper hms/hpen are built on
device  hmt        # multitouch
device  hpen
device  hconf

So usbhid0 -> hidbus0 -> hms should bind, and the question is why it does not happen
on a hotplug specifically.

Likely areas, roughly in order

  1. Hotplug event delivery. If the device attaches on a cold boot but not on a
    hotplug, the drivers are fine and the problem is USB port-change notification. On the
    Pi 5 family both USB controllers are behind RP1 (PCIe), so this may be RP1 interrupt
    related — cf. patch 0028, rp1: acknowledge level-triggered interrupts from post-ithread.
    That would make it genuinely Pi-specific, as suspected.
  2. devd. Not running, or running without the rules to react to the new device.
  3. The consumer. A new /dev/input/* node appearing but Gershwin/X not picking it
    up until restart. This would be userland, not kernel, and the ticket should move.

What to record when picking this up

None of this is known yet, and the answers change which of the three areas above it is:

  • Which board — Pi 500+, Pi 5 B, CM5, or a VM? Does it reproduce off-Pi at all?
  • Does the same mouse work when plugged in before boot? This is the single most
    useful bit: it splits "driver never binds" from "hotplug path broken".
  • Which port — RP1 USB (the normal ones) or something else?
  • dmesg across the plug event: does anything appear at all (ugen, usbhid, hms)?
  • ls /dev/input/ and usbconfig list before and after plugging.
  • Is devd running, and does devd -d show the attach event?
  • Does unplug/replug of a mouse that worked at boot break it, or is it only
    never-seen-before devices?

Not blocking anything

Filed to avoid losing it, not because it is urgent. No owner.

主要语言
C
星标
12
派生
3
平均合并
2 小时 9 分钟
30 天内合并 PR
74

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

nextbsd/nextbsd-kernel 的其他 Issue

查看 nextbsd/nextbsd-kernel 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。