On Tue, Feb 15, 2011 at 12:54:26PM -0800, Ping Cheng wrote: > On Tue, Feb 15, 2011 at 11:56 AM, Jason Gerecke <killert...@gmail.com>wrote: > > > 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. > > > > My hope yesterday was we might still be able to combine the two setups if > DEVICE_INIT is called for all before DEVICE_ON for xorg.conf-defined. > Testing showed that is not the case. With the current xf86-input-wacom, even > the static setup calls DEVICE_INIT and DEVICE_ON in order. This makes > checking the counter almost meaningless even for xorg.conf-defined tools.
not necessarily. we know how many tools we need to initialise in hotplugging. e.g. on the I4, we need stylus, eraser, cursor and pad. so if you set the number of tools to 4 and inc it during DEVICE_ON (not DEVICE_INIT!) then you get the right behaviour. for the xorg.conf case, the situation is a bit different. because devices are initialised in full, counting gets really complicated (it's possible, but would require running through the devices in the server's stored config structs and here be dragons). so we need put extra barriers into the driver. I'm not overly happy with the current patch (if (pInfo->dev ...) because it merely stops short of a segfault. can we add a enabled field to the priv and toggle that on DEVICE_ON? we should be able to discard events sooner with a simple if (!priv->enabled) return; /* discard events until device is enabled */ mind you, if we have that barrier, we don't need the tool counting. saves us some work :) Cheers, Peter ------------------------------------------------------------------------------ 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
