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.doug...@ubuntu.com>
>>
>> Reorder elements so they can be uniform with the upcoming TouchAxisInfo
>> elements required for coordinate scaling.
>>
>> Signed-off-by: Chase Douglas <chase.doug...@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.hutte...@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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to