i have been looking at the clipping issues with the savage driver. this centers around the use of the scissor box. currently the savage driver does not use the scissor box.
next are my observations. i am new to this so please feel free to comment.
i noticed that in the savgeDDRenderStart function the savageDDScissor function is called with the coordinates of the first clip rect in the driDrawable. this effectively wiped out the value that was given by any previous calls to glScissor, hence no scissoring. i commented this command out and scissoring started working correctly well almost. it worked for the first call but did not work for subsequent calls. i found that subsequent calls were being held up in emitHWStateLocked. if the upload clip rects flag is not set and the flags for uploading ctx, textures or buffers are set then the registers are emitted and the scissor rect gets set. these conditions were not being met on the second call so the second attempt to set the scissor rect failed. to the conditions mentioned above, i added a check for scissor changed and now everything works. this is not a good solution, just a proof of concept.
all the other drivers i have looked at don't seem to use the scissor rect to do general clipping. if  i'm following the code, before they draw something they take the context clip rects and copy them into the sarea clip rects then execute the draw command. when draw command is executed the clip rects in the sarea are uploaded to the video card by the kernel driver. the savage kernel driver does not support uploading clip rects this is why they use the scissor rect.
a proper implementation whether in the kernel driver or elsewhere would involve uploading the clip rects to the video card. i don't see any information on how to do this within savage driver code. i can't imagine that everyother video card has this capability and the savage doesn't. if someone knows of a source code sample please let me know.
as things are now, i don't see any reason to intersect the scissor rect with the sarea clip rects. we draw to the back buffer, therefore we don't need to clip to overlapping windows. the scissor rect is intersected with the main draw region (window bounds) before it is uploaded to the video card, so we don't have to worry about drawing outside the draw region. of course this assumes that you only draw to the back buffer. as soon as you start drawing to the front buffer your gonna have problems.
the swap buffer function does handle clipping properly. it uses the serea clip rects to define regions to blit to the front buffer. so no overlapping windows will be affected.
now for a question. i don't know if it is in the opengl spec, but i would like to have the scissor rect taken into account during swap buffers. this is simple to implement. i think the i810 driver does something similar. this would provide a performance enhancement as the user would be able to control the amount of data blit'ed from the back buffer to the front buffer. most opengl optimization documentation mentions using the scissor rect to minimize drawing or clearing of unwanted regions, this seems to play directly into that strategy.
please comment,