On Mon, Feb 14, 2011 at 9:07 PM, Ping Cheng <pingli...@gmail.com> wrote: > On Mon, Feb 14, 2011 at 6:03 PM, Peter Hutterer <peter.hutte...@who-t.net> >> >> quote: >> "init in the config is quite different to init during hotplugging. >> the server will call, PreInit for all devices, DEVICE_INIT for all >> devices, then DEVICE_ON for all devices. >> >> For hotplugging, it's PreInit first device, PreInit + DEVICE_INIT + >> DEVICE_ON for all dependent devices in order, then DEVICE_INIT and >> DEVICE_ON for the first device." >> >> so with this patch, whenever DEVICE_ENABLE is called, you have >> common->wcmNumTools being equal to common->fd_refs. which means it'll go >> happily past the condition in wcmDevReadInput if a device sends events >> before all devices are enabled. >>
I can confirm Peter's hotplug trace under Ubuntu 10.10 (X version 1.9.0) with xf86-input-wacom from git. Hotplugging WITHOUT an xorg.conf gives the following: =============================== 1. udev adds a new device 2. wcmPreInit and NewWcmPreInit are called for a device with NULL type 3. Driver assumes type is 'stylus' and sets up appropriately 4. 'stylus' reports "hotplugging dependent devices" 5. wcmPreInit and NewWcmPreInit for a newly-created 'eraser' called 6. DEVICE_INIT and DEVICE_ON sent to 'eraser' 7. wcmPreInit and NewWcmPreInit for a newly-created 'cursor' called 8. DEVICE_INIT and DEVICE_ON sent to 'cursor' 9. 'stylus' reports hotplugging complete 10. DEVICE_INIT and DEVICE_ON sent to 'stylus' Hotplugging WITH a minimal xorg.conf gives the following: ================================ 1. wcmPreInit and NewWcmPreInit are called for the 'stylus' device 2. DEVICE_INIT and DEVICE_ON sent to 'stylus' 3. wcmPreInit and NewWcmPreInit are called for the 'eraser' device 4. DEVICE_INIT and DEVICE_ON sent to 'eraser' ... etc. N. udev attempts to add the device, but we ignore it since its already in use In either case, fd_refs and wcmNumTools are incremented in (near) lockstep. All I see it doing is narrowing the window of opportunity to crash the driver, not truly plugging the hole. Empirical results of the patch aside, it still seems like it needs some work before we can actually call this problem "solved". Jason ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
