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

[Chase Douglas]

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:

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 :).

Thanks,

-- Chase