#1869 BLOC Trial-2: Xorg post-1.3: right-half of all bitmaps becomes a green box on GX

[Zarro Boogs per Child]

#1869: Xorg post-1.3: right-half of all bitmaps becomes a green box on GX
------------------------------+---------------------------------------------
  Reporter:  bernie           |       Owner:  JordanCrouse
      Type:  defect           |      Status:  new         
  Priority:  blocker          |   Milestone:  Trial-2     
 Component:  x window system  |     Version:              
Resolution:                   |    Keywords:              
  Verified:  0                |  
------------------------------+---------------------------------------------
Comment (by JordanCrouse):

 Okay - here's what we know so far.  It seems that the trigger is drawing a
 32BPP pixmap with GTK (not cairo).  See gtk-image.py for an example.  This
 is what I see with instrumentation - the 32bpp image is copied to
 offscreen memory.  The image is then put through Composite to convert it
 to 16bpp.  Then both the 32BPP and 16BPP images are copied back to system
 memory, and the 16BPP image is then copied back offscreen into video
 memory and then finally copied on the screen where it appears corrupted.

 I have visually verified that the last uploaded pixmap is already
 corrupted when it is put into video memory, so the final copy isn't to
 blame.

 I then commented out the Upload and Download functions (so the EXA version
 will be used instead), and the corruption continued.  Note that the
 corrupted picture appears correct in shape and size, and parts of the
 image are correctly rendered, which precludes a really bad copy.
 Ajax informs me that the image will be put through composite when it gets
 color converted, so for safety, I commented out the Composite hooks in the
 driver as well, but the corruption continues.

 So, to summarize - My driver now only supports the solid and copy hooks,
 and punts everything else to software, yet the problem is still not
 solved.  My current working theory is that something breaks between EXA
 and fbComposite, though I don't blame fBComposite at all because rendering
 works fine when NoAccel is enabled.  I really don't think this is living
 in the driver right now - unless its a subtle issue with solid fill or
 copy, and that would have to be really, really obscure.  I'm open to
 arguments to the contrary though.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1869#comment:8>
One Laptop Per Child <http://laptop.org/>