linux 输入子系统(4) intput_dev 接口描述

  • Name
  • struct input_dev — represents an input device
  • Synopsis
  • struct input_dev {
  • const char * name; //name of the device
  • const char * phys; //physical path to the device in the system hierarchy
  • const char * uniq; //unique identification code for the device (if device has it)
  •   struct input_id id; //id of the device (struct input_id)
  •   unsigned long evbit[BITS_TO_LONGS(EV_CNT)]; //bitmap of types of events supported by the device (EV_KEY, EV_REL, etc.)
  •   unsigned long keybit[BITS_TO_LONGS(KEY_CNT)]; //bitmap of keys/buttons this device has
  •   unsigned long relbit[BITS_TO_LONGS(REL_CNT)]; //bitmap of relative axes for the device
  •   unsigned long absbit[BITS_TO_LONGS(ABS_CNT)]; //bitmap of absolute axes for the device
  •   unsigned long mscbit[BITS_TO_LONGS(MSC_CNT)]; //bitmap of miscellaneous events supported by the device
  •   unsigned long ledbit[BITS_TO_LONGS(LED_CNT)]; //bitmap of leds present on the device
  •   unsigned long sndbit[BITS_TO_LONGS(SND_CNT)]; //bitmap of sound effects supported by the device
  •   unsigned long ffbit[BITS_TO_LONGS(FF_CNT)]; //bitmap of force feedback effects supported by the device
  •   unsigned long swbit[BITS_TO_LONGS(SW_CNT)]; //bitmap of switches present on the device
  •   unsigned int keycodemax; //size of keycode table
  •   unsigned int keycodesize; //size of elements in keycode table
  •   void * keycode; //map of scancodes to keycodes for this device
  • /*optional method to alter current keymap, used to implement sparse keymaps.
  • If not supplied default mechanism will be used*/
  • int (* setkeycode) (struct input_dev *dev, int scancode, int keycode);
  • /*optional method to retrieve current keymap. If not supplied default mechanism will be used*/
  • int (* getkeycode) (struct input_dev *dev, int scancode, int *keycode);
  •   struct ff_device * ff; //force feedback structure associated with the device if device supports force feedback effects
  •   unsigned int repeat_key; //stores key code of the last key pressed; used to implement software autorepeat
  •   struct timer_list timer; //timer for software autorepeat
  • int sync; //set to 1 when there were no new events since last EV_SYNC
  • int abs[ABS_MAX + 1]; //current values for reports from absolute axes
  • int rep[REP_MAX + 1]; //current values for autorepeat parameters (delay, rate)
  •   unsigned long key[BITS_TO_LONGS(KEY_CNT)]; //reflects current state of device‘s keys/buttons
  •   unsigned long led[BITS_TO_LONGS(LED_CNT)]; //reflects current state of device‘s LEDs
  •   unsigned long snd[BITS_TO_LONGS(SND_CNT)]; //reflects current state of sound effects
  •   unsigned long sw[BITS_TO_LONGS(SW_CNT)]; //reflects current state of device‘s switches
  • int absmax[ABS_MAX + 1]; //maximum values for events coming from absolute axes
  • int absmin[ABS_MAX + 1]; //minimum values for events coming from absolute axes
  • int absfuzz[ABS_MAX + 1]; //describes noisiness for axes
  • int absflat[ABS_MAX + 1]; //size of the center flat position (used by joydev)
  • /*this method is called when the very first user calls input_open_device.
  • The driver must prepare the device to start generating events (start polling
  • thread, request an IRQ, submit URB, etc.) */
  • int (* open) (struct input_dev *dev);
  •   void (* close) (struct input_dev *dev); //this method is called when the very last user calls input_close_device.
  • /*purges the device. Most commonly used to get rid of force feedback effects
  •   loaded into the device when disconnecting from it */
  • int (* flush) (struct input_dev *dev, struct file *file);
  • /*event handler for events sent _to_ the device, like EV_LED or EV_SND.
  •   The device is expected to carry out the requested action (turn on a LED, play sound, etc.)
  •   The call is protected by event_lock and must not sleep */
  • int (* event) (struct input_dev *dev, unsigned int type, unsigned int code, int value);
  • /*input handle that currently has the device grabbed (via EVIOCGRAB ioctl).
  •   When a handle grabs a device it becomes sole recipient for all input events coming from the device */
  •   struct input_handle * grab;
  • /*this spinlock is is taken when input core receives and processes a new event for the device (in input_event). Code that accesses and/or modifies parameters of a device (such as keymap or absmin, absmax, absfuzz, etc.) after device has been registered with input core must take this lock. */
  •   spinlock_t event_lock;
  •   struct mutex mutex; //serializes calls to open, close and flush methods
  • /*stores number of users (input handlers) that opened this device. It is used by input_open_device and input_close_device to make sure that dev->open is only called when the first user opens device and dev->closeis called when the very last user closes the device */
  •   unsigned int users;
  • int going_away; //marks devices that are in a middle of unregistering and causes input_open_device*() fail with -ENODEV.
  •   struct device dev; //driver model‘s view of this device
  •   struct list_head h_list; //list of input handles associated with the device. When accessing the list dev->mutex must be held
  •   struct list_head node; //used to place the device onto input_dev_list
  • };
    • 时间： 2024-10-26 02:33:28

    linux 输入子系统(4) intput_dev 接口描述的相关文章

    Linux输入子系统(转)

    Linux输入子系统(Input Subsystem) 1.1.input子系统概述 输入设备(如按键,键盘,触摸屏,鼠标等)是典型的字符设备,其一般的工作机制是低层在按键,触摸等动作发生时产生一个中断(或驱动通过timer定时查询),然后cpu通过SPI,I2C或者外部存储器总线读取键值,坐标等数据,放一个缓冲区,字符设备驱动管理该缓冲区,而驱动的read()接口让用户可以读取键值,坐标等数据. 在Linux中,输入子系统是由输入子系统设备驱动层.输入子系统核心层(Input Core)和输入

    Linux 输入子系统原理理解（原创）

    linux    输入子系统原理理解(原创) 以前学了单独的按键设备驱动以及鼠标驱动,实际上,在linux中实现这些设备驱动,有一种更为推荐的方法,就是input输入子系统.平常我们的按键,触摸屏,鼠标等输入型设备都可以利用input接口来简化驱动程序并实现设备驱动. 输入子系统原理 linux输入子系统的体系结构可以分为三个层面,分别为:驱动层.输入核心层.事件处理层,三个有点类似PHP的MVC模式,意思就是每个层次只是负责单独的一个功能,无需参与其他的功能,有点类似函数的封装,好了,废话不多

    Linux输入子系统

    在Linux中,按键.触摸屏.鼠标等等输入设备都可以依靠输入子系统提供的接口函数来实现他们的设备驱动,在输入子系统中,系统已经完成了这些输入设备的共性,所以根据子系统提供的接口,只需要完成各自的独特性即可完成一个输入设备的设备驱动. Linux中,输入子系统由设备驱动层.核心层.事件处理层这三层组成.设备驱动层讲底层输入设备的响应转化为标准的输入事件,事件处理层就为应用程序提供统一的设备访问接口来跟底层交互数据,核心层则是连接驱动层和事件处理层的桥梁. 在输入子系统中重要的结构体就是input_

    Linux输入子系统框架分析（1）

    在Linux下的输入设备键盘.触摸屏.鼠标等都可以用输入子系统来实现驱动.输入子系统分为三层,核心层和设备驱动层,事件层.核心层和事件层由Linux输入子系统本身实现,设备驱动层由我们实现.我们在设备驱动层将输入事件上报给核心层input.c,核心层找到匹配的事件层,将事件交给事件层处理,事件层处理完后传递到用户空间. 我们最终要搞清楚的是在用户空间调用open和read最终在内核中是怎样处理的,向内核上报的事件又是谁处理的,处理完后是怎样传递到用户空间的? 上面两个图是输入子系统的框架. 下面

    Android底层开发之Linux输入子系统要不要推断系统休眠状态上报键值

    Android底层开发之Linux输入子系统要不要推断系统休眠状态上报键值 题外话:一个问题研究到最后,那边记录文档的前半部分基本上都是没用的,甚至是错误的. 重点在最后,前边不过一些假想猜測. http://blog.csdn.net/kangear/article/details/40072707 在调试一下红外遥控器input驱动时,直接採用的是一个半成品的驱动在上边实现的自己的设备的匹配,但同一时候遇到了一些关于input输入子系统的疑惑. 按键一般有「按下和抬起」两个状态一般使用0和1

    Linux输入子系统(Input Subsystem)

    Linux输入子系统(Input Subsystem) http://blog.csdn.net/lbmygf/article/details/7360084 input子系统分析  http://blog.chinaunix.net/uid-27717694-id-3758334.html

    Android底层开发之Linux输入子系统要不要判断系统休眠状态上报键值

    Android底层开发之Linux输入子系统要不要判断系统休眠状态上报键值 题外话:一个问题研究到最后,那边记录文档的前半部分基本上都是无用的,甚至是错误的.重点在最后,前边仅仅是一些假想推测. http://blog.csdn.net/kangear/article/details/40072707 在调试一下红外遥控器input驱动时,直接采用的是一个半成品的驱动在上边实现的自己的设备的匹配,但同时遇到了一些关于input输入子系统的疑惑. 按键一般有「按下和抬起」两个状态一般使用0和1来分

    linux输入子系统（input subsystem）之evdev.c事件处理过程

    1.代码 input_subsys.drv.c 在linux输入子系统(input subsystem)之按键输入和LED控制的基础上有小改动,input_subsys_test.c不变. input_subsys.drv.c 1 #include <linux/module.h> 2 #include <linux/version.h> 3 4 #include <linux/init.h> 5 #include <linux/fs.h> 6 #inclu

    Linux 输入子系统

    Technorati 标签: Kernel 输入子系统 Input      在Linux中,输入设备(如按键.键盘.触摸屏.鼠标等)是典型的字符设备,其一般的工作机理,是底层在按键.触摸时,触发一个中断,或者驱动通过定时器定时查询,通过这两种方式通知CPU,CPU然后通过SPI.I2C或I/O接口读取键值.坐标等数据,放入缓冲区,字符设备驱动管理该缓冲区,向上提供read接口供应用程序使用.      在上述的工作流程中,只有终端.读取数值是根具体硬件设备相关,而输入事件的缓冲区管理以及字符设