如何使用 udev 规则识别断开连接的 USB 设备?
我有两个使用 Xorg xinerama 功能的 LCD。每个 LCD 屏幕都有一个触摸屏,连接到各自的 USB 线。
查看“/var/log/messages”文件,我看到以下内容:
kernel: input: Analog Resistive as /class/input/input0
kernel: input: USB HID v1.01 Mouse [Analog Resistive] on usb-0000:00:1d.3-1
kernel: input: Analog Resistive as /class/input/input1
kernel: input: USB HID v1.01 Mouse [Analog Resistive] on usb-0000:00:1d.3-2
出于某种原因,在某个时间点,USB 总线似乎重置了(或有些奇怪的东西),并且我的两个触摸屏颠倒了(按左侧 LCD 并按鼠标在右侧移动,如果我按右侧 LCD,鼠标会在左侧移动)。
为了尝试调试问题,我尝试编写一个 udev 规则来记录我的设备重置/断开连接(或其他情况)时的情况。但似乎 udev 在连接时会报告设备上的完整详细信息(产品、制造商、idProduct、idVendor 等),但在删除时只提供一些总线编号。这是为什么呢?
当我得到 ACTION==“remove”,KERNEL==“input*” 规则时,我无法知道它是哪个设备!有谁知道解决这个问题的方法吗?
I have two LCD's using Xorg's xinerama feature. Each LCD screen has a touchscreen which are connected to their respective USB lines.
Looking into the '/var/log/messages' file, I see the following:
kernel: input: Analog Resistive as /class/input/input0
kernel: input: USB HID v1.01 Mouse [Analog Resistive] on usb-0000:00:1d.3-1
kernel: input: Analog Resistive as /class/input/input1
kernel: input: USB HID v1.01 Mouse [Analog Resistive] on usb-0000:00:1d.3-2
For some reason, at some point in time the USB bus seems to reset (or something weird) and my two touchscreens get inverted (press the left LCD and the mouse moves on the right and if I press the right LCD the mouse moves on the left).
To try and debug the problem, I tried to write a udev rule to log when my devices get reset/disconnected (or whatever). But it seems as though udev will report full details (product, manufacturer, idProduct, idVendor, etc) on the device when it connects, but gives you nothing but a few bus numbers when it is removed. Why is this?
When I get an ACTION=="remove", KERNEL=="input*" rule, there is no way for me to know which device it is! Does anyone know a way around this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我建议首先检查设备“删除”事件上的 udev 事件,方法是运行 udevadm monitor --kernel --property --subsystem-match=usb 并依次断开设备连接并比较输出。
在一次鼠标断开连接上,我收到两个事件:
您可以编写调用脚本的规则,该脚本应该在检查某些特定环境变量后执行一些工作。规则可能很简单,
在您的情况下,我建议检查 usbdevgone.sh 内的 $DEVPATH ,因为它们对于您的两个其他相同的设备应该有所不同。
您还可以将
devpath
(这是 /sys/ 文件系统中的路径)作为参数传递给脚本,如下所示(请参阅man udev
以获取可用的列表替换
):不要忘记使用
udevadm control --reload-rules
通知udevd您的新规则或更改规则i'd suggest first thing check udev events on device "remove" event by running e.g.
udevadm monitor --kernel --property --subsystem-match=usb
and disconnecting your devices in turn and comparing outputs.Here on a single mouse disconnect i get two events:
You can write your rule invoking a script which should do some job after examining some specific environment variable. A rule may be as simple as
In your case i'd suggest checking $DEVPATH inside usbdevgone.sh as they should differ for your two otherwise identical devices.
Also you may pass
devpath
(this is a path in /sys/ filesystem) as an argument to your script like this (seeman udev
for a list of availablesubstitutions
):Do not forget to notify udevd of your new or changed rule with
udevadm control --reload-rules
我在 Linux 中也遇到了同样的问题。删除时发送的信息很少,不能用于唯一标识被删除的设备。我曾经使用
PHYDEVPATH
(对于给定的机器和 USB 端口,它在插入和拔出时是唯一的),但非常不幸的是,这一直是 在更高版本的udev
中已弃用。I have run into the same problem in Linux. The information sent on a remove is minimal and cannot be used to uniquely identify the device being removed. I used to use the
PHYDEVPATH
(which is unique on plug in and unplug for a given machine and USB port), but very unfortunately, that has been deprecated in later versions ofudev
.我正在编写一个具有类似功能的应用程序,并且解决了实现守护进程的问题,该守护进程的唯一任务是存储连接的
udev_device
。因此,当我检测到某些remove
(甚至是从udev_monitor
)时,我会检查守护程序的设备列表中是否缺少某些设备。缺少的是设备已断开连接。这样我就可以获得断开连接的设备的数据。I was writing an application with similars features and I solved the problem implementing a daemon with the only mission of storing the
udev_device
connected. So when I detect someremove
even from theudev_monitor
I check for some device missing on the deamon's devices list. That what is missing is the device disconnected. That way I can obtain the data of disconnected devices.