我正在为游戏库创建一个 Linux 模块,让您可以热插拔多个操纵杆,它使用 inotify 来观看 /dev/input
.
我正在用 3 个操纵杆测试它:
- 首先,我连接了 2 个操纵杆。li>
- 然后我启动应用程序,操纵杆正常工作,我没有收到错误。
- 之后我连接第三个操纵杆,
perror
给出:/dev/input/js1: Permission denied
. - 当我检查
ls -l /proc/<pid-of-process>/fd
它列出了/dev/input/js0
和/dev/input/js2
.
当我以 root 身份运行它时,所有的操纵杆都工作正常。
这是它的初始化方式:
static void createGamepad(char *locName){
char dirName[30];
int fd;
snprintf(dirName, 30, "/dev/input/%s", locName);
fd = open(dirName, O_RDONLY | O_NONBLOCK, 0);
if(fd < 0){
perror(dirName);
}
}
struct dirent *dir;
DIR *d;
int i, notifyfd, watch;
// Attach notifications to check if a device connects/disconnects
notifyfd = inotify_init();
watch = inotify_add_watch(notifyfd, "/dev/input", IN_CREATE | IN_DELETE);
d = opendir("/dev/input");
i = 0;
while((dir = readdir(d)) != NULL){
if(*dir->d_name == 'j' && *(dir->d_name + 1) == 's'){
createGamepad(dir->d_name, i);
i++;
}
}
closedir(d);
之后 inotify 在 while(1)
中像这样处理它循环:
static bool canReadINotify(){
fd_set set;
struct timeval timeout;
FD_ZERO(&set);
FD_SET(notifyfd, &set);
timeout.tv_sec = 0;
timeout.tv_usec = 0;
return select(notifyfd + 1, &set, NULL, NULL, &timeout) > 0 &&
FD_ISSET(notifyfd, &set);
}
// Inside the event loop
struct inotify_event ne;
while(canReadINotify()){
if(read(notifyfd, &ne, sizeof(struct inotify_event) + 16) >= 0){
if(*ne.name != 'j' || *(ne.name + 1) != 's'){
continue;
}
if(ne.mask & IN_CREATE){
createGamepad(ne.name);
}
}
}
是否可以使用 inotify 或我应该使用 udev?如果可能的话,我该如何解决这个问题?
最佳答案
这很可能是竞争条件。你看,当设备节点被创建时(由 udev 使用 mknod()
调用),你得到了 inotify 事件,但是访问权限是由 udev 使用单独的 chown()
调用,稍晚一点。
参见 systemd src/udev/udev-node.c
, node_permissions_apply()
.在这种特殊情况下,/dev/input/jsX
不是符号链接(symbolic link),而是实际的设备节点;至少对于 systemd,设备节点访问模式会在创建实际节点后的某个时间设置。
一个可靠的解决方案是修改您的 createGamepad()
函数,这样您就不会在 fd == -1 && errno == EACCES
处完全失败,而是稍后重试;至少几次,比如最多一两秒。
但是,ninjalj指出了一个更好的建议:也使用访问权限更改作为触发器来检查设备节点。这可以通过使用 IN_CREATE | 轻松完成。删除 |
!inotify_add_watch()
函数中的 IN_ATTRIBUTE
(您还需要忽略 createGamepad()
中的 open()==-1, errno==EACCES
错误,因为它们很可能由此引起竞争条件,以及以下 IN_ATTRIBUTE
inotify 事件将产生对同一设备的访问。)
在 ninjalj 的评论之前,我个人使用了一组输入设备,另一个用于“可能的”输入设备,这些输入设备可以/需要在短暂超时后重试以确定它们是否可用,但我认为他的建议要好得多。
需要/想要一个例子吗?
关于inotify 事件后无法打开/dev/input/js 文件描述符,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25381103/