我正在为游戏库创建一个Linux模块,让您热插拔多个操纵杆,它使用inotify观看/dev/input

我正在用3个操纵杆进行测试:

  • 首先,我连接2个操纵杆。
  • 然后启动应用程序,操纵杆正常工作,但没有收到错误消息。
  • 之后,我连接第三个操纵杆,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?如果有可能,我该如何解决呢?

    最佳答案

    这很可能是比赛条件。您会看到,在创 build 备节点时(通过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 | IN_DELETE | IN_ATTRIBUTE函数中使用inotify_add_watch()可以轻松实现这一点!

    (您也将要忽略open()==-1, errno==EACCES中的createGamepad()错误,因为它们很可能是由这种竞争条件引起的,并且以下IN_ATTRIBUTE inotify事件将产生对同一设备的访问。)

    在ninjalj发表评论之前,我个人使用过一系列输入设备,另外一个用于“可能的”输入设备,这些输入设备可以/需要在短暂的超时后重试以确定是否可用,但我认为他的建议是好多了。

    需要/想要一个例子吗?

    关于c - inotify事件后无法打开/dev/input/js文件描述符,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/25381103/

    10-15 01:17