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.hutte...@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 _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
