On Wed, Feb 24, 2010 at 5:20 PM, Peter Hutterer <peter.hutte...@who-t.net> wrote: > On Wed, Feb 24, 2010 at 08:49:44AM -0600, Chris Bagwell wrote: >> On Tue, Feb 23, 2010 at 11:27 PM, Peter Hutterer >> <peter.hutte...@who-t.net> wrote: >> > On Tue, Feb 23, 2010 at 08:55:38PM -0600, ch...@cnpbagwell.com wrote: >> >> From: Chris Bagwell <ch...@cnpbagwell.com> >> > Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net> >> > >> > again, I'd like to know Ping's input on this, I don't quite know what the >> > MaxX and stuff was for. And why we have a different MaxX and maxTouchX >> > anyway? >> >> I can answer the second question because originally I tried getting >> rid of maxTouch*. The reason is because of ISDV4 devices. They read >> directly from 1 serial device so all the types's are multiplexed to >> single DEVICE. They want to store in the common structure a min/max >> of X/Y for both the pen part of tablet and another for touch part of >> tablet. So they need two sets of variables. Later, they are copied >> to priv structures. >> >> The only reason to store in common struct is related to GetRanges() >> only be called once at device open. Perhaps we should support calling >> GetRanges() for all device types instead of just on open. Then most >> Max* values would become priv-only values. > > I'm not quite sure I understand what you wrote here. ISDV4 devices - do they > end up as multiple devices in X just like the usb devices? > If so, can't we use the same technique to gather the right data from the > device (depending on the "type" option)? Or am I missing something here?
Well, I'm implying a lot of how things work since I don't have any wacom's besides the USB Bamboo P&T. But this is how code reads: For a single /dev/ttyS? device, wcmDeviceTypeKeys() will report support for multiple keys including a BTN_TOOL_PEN and a BTN_TOOL_DOUBLETAP. Because of auto-dev logic, yes, they will show up as multiple devices in X. In this case though, wcmDevOpen() prevents wcmInitTablet() from being called except for first time we do true open of /dev/ttyS0; which further prevents wcmISDV4GetRanges() from being called more then once. So based on current framework, ISDV4 devices need to read all GetRanges()-like data in one call and use common structure as a temporary storage location for data related to all possible "types". And thus why MaxX is for pen tool and MaxTouchX is for touch tool. wcmInitialToolSize() is location were you move this temporary storage to correct private locations and is called once for each "type"; unlike GetRanges(). Todays way basically works but another option is to call GetRanges()'s and a subset of other related functions for all "types". But finding out what subset of functions is easier said then done. > > fwiw, I'm currently looking at the initialization sequence for wacom and one > of the things I'm trying to fix is the multiple open calls and the rather > awkward order of everything. > Ideally, we'd have a single open call, followed by the device probing, > followed by everything else. Nice! (that is if I understand what your saying :-) ). Moving auto-dev logic outside of wcmInit() and into Open() path would make flow be more logical. Currently, init order initiated by HAL for simplest of devices would be like this: wcmInit(); <-- for example from pad device wcmDevOpen(); <--- same pad device (which calls device->GetRanges()) But we are getting in to their business (auto-dev) and inserting our own similar X calls and making it look like this (example specific to Bamboo): wcmInit(); <--- touch device wcmInit(); <--- recursive call caused by auto-dev of pad device wcmDevOpen(); <--- auto-dev pad device which calls GetRanges(). wcmDevOpen(); <--- touch device and this DOESN'T call GetRanges(). Its not obvious path. The following would be nice if possible. wcmInit(); <--- touch device wcmDevOpen(); <--- touch device wchi calls GetRanges(). wcmInit(); <--- call caused by auto-dev of pad device wcmDevOpen(); <--- auto-dev pad device which DOESN'T calls GetRanges(). > > I think auto-dev is currently broken as well, given the order of tests in > wcmInit. Code is hard to follow but seems to be working for me. Chris ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
