[RFC XI 2.1 - xserver 7/9] Reorder AxisInfo elements

[Peter Hutterer]

On Wed, Nov 17, 2010 at 10:53:16AM -0500, Chase Douglas wrote:
> On 11/17/2010 01:11 AM, Peter Hutterer wrote:
> > On Fri, Nov 12, 2010 at 05:35:08PM -0500, Chase Douglas wrote:
> >> From: Chase Douglas <chase.douglas at ubuntu.com>
> >>
> >> Reorder elements so they can be uniform with the upcoming TouchAxisInfo
> >> elements required for coordinate scaling.
> >>
> >> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>
> >> ---
> >>  include/inputstr.h |    4 ++--
> >>  1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/inputstr.h b/include/inputstr.h
> >> index 4d8ea12..b3c60b2 100644
> >> --- a/include/inputstr.h
> >> +++ b/include/inputstr.h
> >> @@ -213,11 +213,11 @@ typedef struct _KeyClassRec {
> >>  
> >>  typedef struct _AxisInfo {
> >>      int		resolution;
> >> -    int		min_resolution;
> >> -    int		max_resolution;
> >>      int		min_value;
> >>      int		max_value;
> >>      Atom	label;
> >> +    int		min_resolution;
> >> +    int		max_resolution;
> >>      CARD8	mode;
> >>  } AxisInfo, *AxisInfoPtr;
> >>  
> >> -- 
> >> 1.7.1
> > 
> > this is technically an ABI break, together with the masked_valuator exports
> > I'll won't merge this into master right now until we've figured out if it's
> > worth bumping the ABI again.
> 
> This one certainly isn't worth it by itself since it's only helpful for
> MT stuff.
> 
> > Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>
> > 
> > (the same applies to the valuator mask export patch, was too quick in
> > hitting send on that one ;)
> 
> The valuator mask helpers change is needed if we want masked vals in
> evdev in 1.10.
> 
> I don't know what the guidelines are for ABI changes in the middle of
> development. I see three scenarios:

there are no real guidelines beyond what I make up on the spot. 
keith's approach to the video ABI is bump once per cyle.
I've outlined the ABI approaches here
http://www.mail-archive.com/xorg-devel@lists.x.org/msg14562.html
and just added a short paragraph to
http://wiki.x.org/wiki/XorgModuleABIVersions (remind me to update that when
needed :)

> 1. Merge helper functions and don't bump ABI again. This seems
> reasonable to me before the merge window closes, especially for
> backwards compatible ABI changes like this one.
> 
> 2. Bump the minor ABI number. Since the helper function addition is
> backwards compatible, this is possible and shouldn't harm anyone.
> Between 1 and 2 it's just a matter of whether we really care to bump the
> ABI multiple times, even just minor bumps, during a merge cycle.
> 
> 3. Bump the major ABI number. I don't see why we would want to do this
> unless we care about ABI bumps in the middle of a merge cycle and we
> pull in the AxisInfo change.
> 
> I know the above is rather self explanatory, but I have been wondering
> about ABI policy in the middle of a merge cycle. This is all probably
> documented somewhere and I've been too lazy :).

fwiw, I don't really see a need to differ between major/minor ABI. It's just
a number and we have a fair way to go before we run out of integers. And not
having to remember which one was major/minor in the driver ifdefs is
helpful.

so for all I care, we can bump the major number again, but I'd like to do
this not immediately, but rather when we know that we likely won't need
another bump this cycle.
Since the major motivation here is the MT work and the changes aren't
immediately needed for other stuff, I'd like to hold this back on the MT
branch and then cherry-pick over when we have a clearer picture. Does this
make sense?

We have some time left in the devel cycle when we can merge the ABI bump (we
don't have to care about ABI stability until the last month).
 
Cheers,
  Peter