About ExaOffscreenDefragment in Geode LX platform Rotate operation

[Cui, Hunk]

Hi, Maarten,

	Please see below:

>>
>> 1). Can you explain ExaOffscreenDefragment -> prev->offset? When do the rotate operation, where is triggered this function and what is the prev->offset value?

>I think ExaOffscreenDefragment is triggered from the block handler
(but i didn't check).

>>
>> 2). Now I add the memorySize length(+1) when lx_crtc_shadow_allocate, after rotate normal, subtract the former memorySize length(-1) when lx_crtc_shadow_destroy. I have been used this methods to test the Geode LX platform for two days, It can properly rotate in Xserver 1.8 and 1.7.      Because I have some confuse on memorysize, so I want to ask you whether this approach is correct. I can not explain too specific. Can you explain it?

>Don't change memorySize (it should include the size you previously
subtracted for rotatedData), do exaOffscreenAlloc at the beginning if
you want to be 100% sure there is space. But i think only the
frontbuffer is fixed memory, the rest will be kicked out if needed.

[Cui, Hunk] May be you mistake my meant, I don't change the memorySize after call InitOffscreen function, I have been subtracted for rotatedData and video overlays in InitOffscreen. In our Geode-driver, in order to avoid using xorg.conf as much as possible, Jordan Crouse make assumptions about what a "default" memory map would look like. Default driver should assume the user will want to use rotation and video overlays, and EXA will get whatever is leftover.
	When do the Rotate operation, because memorySize is rotate_mem->offset, and memorySize address begin from 0 (not 1? right or wrong), so I think the memorySize should add 1 at this time, after screen return to normal, it will trigger the lx_crtc_shadow_destroy, I will subtract the memorySize (-1), that it never improve the normal memorySize operation. And so on, it is not improve the EXA offscreen space. 
	This is my consideration, Do you think reasonable?

Thanks,
Hunk Cui