Chatting about the input device in Linux (8) What will we do when it comes to beauty?

Speaking of the evdev handler name, I believe everyone will never be familiar with it again, that is, the guy who has lots of children in groups, a guy who makes many men in the world look far behind. Envy, envy. These may not matter anymore. To learn about hate, we have to find a way to fix the daughter she gave birth to with the AKM input device aunt. But to fix his daughter, we have to fix her dad first. As long as her dad opens his mouth, there may be something to talk about later. In any case, you should familiarize yourself with Uncle evdev handle.

Static struct input_handler evdev_handler = {

. Event = evdev_event,

. Connect = evdev_connect,

. Disconnect = evdev_disconnect,

. Fops = & evdev_fops,

. Minor = evdev_minor_base,

. Name = "evdev ",

. Id_table = evdev_ids,

};

In fact, we already know some of the functions in it. For example, evdev_connect () (I analyzed it in the previous section. Don't tell me you don't know? In this case, I will be very sad.) Then evdev_disconnect () is, as its name implies, the opposite action (throwing a wife and throwing a daughter ).. Id_table = evdev_ids (mate selection criteria),. Name = "evdev", the last name of the child, and a cradle number is the name, which is displayed in the/dev directory .. Minor = evdev_minor_base, do you still remember the line of code in section 7th? Evdev-> Dev. devt
= Mkdev (input_major, evdev_minor_base + minor); you can see that the device number is generated using this code. Well, there are still two things we don't know yet.

That is, evdev_event, and evdev_fops. Evdev_event is a sub-item. I will explain it in detail when leaving a suspense ..... Let's look at evdev_fops. Follow up: you will be surprised to find that:

Static const struct file_operations evdev_fops = {

. Owner = this_module,

. Read = evdev_read,

. Write = evdev_write,

. Poll = evdev_poll,

. Open = evdev_open,

. Release = evdev_release,

. Unlocked_ioctl = evdev_ioctl,

# Ifdef config_compat

. Compat_ioctl = evdev_ioctl_compat,

# Endif

. Fasync = evdev_fasync,

. Flush = evdev_flush

};

Good memory guys will soon think of what I said in the first section. Yes, this is the file operation set function provided by the input subsystem. Do you remember what Mr. Lu Xun said? If you don't remember, I suggest you look back at the content of section 1 so that the old man can feel at ease. Yes, our application-layer developers will eventually use it. If you want to make a crush, you must remember this structure, because you only need to use it to bring the handler's daughter to your pomegranate dress.

 

 

Grasp it, and you can open her mind to open her mind, and write whatever you want to write in her mind ), if you want to read many stories from her, she will let you read (read). The most important thing is that you can operate on her (evdev_ioctl) at will ). Is it very high. Remember how we described in section 2 about registering the AKM device as an input device in Linux? If you do not remember, you can look back. We have basically analyzed the few lines of code, but there is another one that is not analyzed:

Input_report_abs (data-> input_dev, abs_rx, rbuf [0]);

Input_report_abs (data-> input_dev, abs_ry, rbuf [1]);

Input_report_abs (data-> input_dev, abs_rz, rbuf [2]);

And other lines of code. As mentioned above, this is to report something happening to our input subsystem. Then our input subsystem will process it and finally submit it to our application layer, then you can use the above evdev_fops for read and write operations. Is there some understanding about the whole process.

Okay, how do we submit our device information for these functions? It is related to the evdev_event in the previous evdev_handler. It should come back after all, and it cannot escape. This is what we will discuss in the next section.