[PATCH 1/2 v2] dri2proto: Add DRI2GetParam request

[Chad Versace]

Tomorrow (Wednesday) I will submit a v3 of this series that addresses
your questions and suggestions. Comments below.

On 05/14/2012 05:51 PM, Alan Coopersmith wrote:
> On 05/14/12 03:23 PM, Chad Versace wrote:
>> +	Parameter names in which the value of the most signficant byte is 0 are
>> +	reserved for the X server. Names in which the byte's value is 1 are
>> +	reserved for the DDX. Names in which the byte's value is neither 0
>> +	nor 1 are reserverd for future use.
> 
> Typos highlighted by Thunderbird when it quoted your message for my reply:
> 	signficant -> significant
> 	reserverd -> reserved

Thanks. Will fix in v3.

> So just to make sure I'm understanding correctly - a "name" is really a 32-bit
> enum from a unique space, not an Atom or any other existing namespace, right?

Right.
 
> Where will the master list of these be maintained to avoid conflicts?   Server
> ones in dri2proto.txt/dri2proto.h and driver ones in each driver's headers?

That is the plan; sorry for not documenting that. I will explicitly
document that in dri2proto.txt in v3.
 
>> +     ▶
>> +	1	1			Reply
>> +	1				unused
>> +	2	CARD16			sequence number
>> +	4	0			reply length
>> +	1	BOOL			is_param_recognized
>> +	3				unused
>> +	4	CARD32			value_hi
>> +	4	CARD32			value_lo
>> +	12				unused
> 
> Seems like "is_param_recognized" could go in the unused byte after
> Reply and then get rid of the 3 padding bytes in the middle, i.e.:
> 
> +     ▶
> +	1	1			Reply
> +	1	BOOL			is_param_recognized
> +	2	CARD16			sequence number
> +	4	0			reply length
> +	4	CARD32			value_hi
> +	4	CARD32			value_lo
> +	16				unused
> 
> Both simpler, and hopefully better alignment for the two value_*,
> since they'll start on a 64-bit aligned boundary.   (Plus more
> space for future expansion, if it ever becomes necessary.)

Ah, this is my first time working the X protocol. I was unaware that
it was legal to pack data into the packet header. I'll do this in v3.

Thanks for the feedback.

----
Chad Versace
chad.versace at linux.intel.com