Input driver on 1.15.1 vs. 1.19.6

[Peter Hutterer]

On Sat, Oct 12, 2019 at 03:19:52AM +0000, Software Orchestration wrote:
>  On Friday, October 11, 2019, 7:38:57 PM PDT, Peter Hutterer <peter.hutterer at who-t.net> wrote: 
> > if your device has a /dev/input/eventX node anyway, then yes, evdev is 
> > the way to go. You may  not need any modification at all, evdev may do 
> > the trick.
> 
> I think I'm starting to understand how all of this starts up, the
> XF86ModuleData has the entry to call for the driver. Then the PreInit name
> is located in the InputDriverRec  which is passed with xf86AddInputDriver,
> that in turn triggers the PreInit which then receives the InputInfoPtr
> which a few things are assigned to, one being the main Proc that xorg will
> send events (pInfo->device_control). That InputInfo struct is used to open
> the device with EvdevOpenDevice. Some other stuff is done in the PreInit,
> but after that, I'm guessing that all the interaction between the driver
> and xorg is done through that Proc.
> 
> Does that sounds correct?

yes, that's correct. Of note: DEVICE_INIT and DEVICE_CLOSE are only called
once, but DEVICE_ON/OFF are called every time the device is
enabled/disabled. That happens on vt swtich, suspend or on user request.

xf86AddEnabledDevice() is the important bit in DEVICE_ON, it registers the
fd with the server's poll(). read_input is the callback invoked on data and
notably: that one is called from the input thread, not the main thread.

Cheers,
   Peter

> 
> Thanks so much, I am starting to modify the evdev code. And just to be
> clear, I'm not really re-writing the driver, I'm just taking what's there
> and putting it inside this new framework. The client will thank me in the
> end, unless I fall on my face...LOL