As far as I can tell: there were two reasons to make the xf86ReplaceStrOption() call when an option is changed:
Recording the change in the log file (thus the confusing part :) so we (or someone) can trace the change in the log; Synchronizing the option stored locally, which was just changed, with the one in the server (if there is one) in case a xf86CheckStrOption() is called somewhere (don't ask me where since I don't know if anywhere else would call it). If we don't call xf86ReplaceStrOption(), xf86CheckStrOption would return the initial option (or no option at all even if the driver has one now). Do we really need to do this? I am not sure. I guess the majority wins. So, if you two think we don't need it, we can remove it. Please make sure to remove all of the calls in one patch. Thank you, Chris, for bringing up this discussion. Ping On Wed, Feb 24, 2010 at 3:30 PM, Peter Hutterer <peter.hutte...@who-t.net> wrote: > On Wed, Feb 24, 2010 at 10:55:29AM -0600, Chris Bagwell wrote: >> While trying to understand MaxX usage, I notice similar strange code >> in wcmRotateTablet() that I'm guessing was added at same time since >> its called during updates to prop_rotate. > > Yes, there are more bits like this where it doesn't really make sense, they > just need time tracking down :) > > for the record - the only point in replacing options from within the driver > is > - the driver later accesses this option, it saves us from keeping a tmp > variable. one usecase for this is auto-dev, where we can replace the > device-option if needed (I don't think we do, but it's a possible usecase:) > - options that need to be duplicated into the dependent devices (hotplugged > ones). > > other than that, there isn't really a reason to change the options at > runtime. especially since it might be confusing in the logs; the server > always prints out options used by the driver so if a > Option "Foobar" "yes" > pops up in the logs when the actual config is set to "no", then that needs > at least explaining in the driver log. > > Cheers, > Peter ------------------------------------------------------------------------------ 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
