Bottom half of screen goes blank in Neighborhood view

[jfuhrer]

OFW: Q2C18 Build: 514

On a B2 machine, whenever the user switches into the Neighborhood view, the bottom half of the screen will turn completely blank after a few seconds. The frame still appears on the bottom half, as do any tooltips that would have appeared there, and any blinking mesh icons, but everything else is white. If the user switches to another view and then waits for a while, the screen will go back to normal, but if they switch back to the Neighborhood view after that the problem will occur again.

This problem did not seem to occur on the B3/B4.

[bert]

This seems to be some X drawing issue, happens in etoys too on build 513 which uses plain X11.

[marco]

If I revert the frame buffer size to Option "FBSize" "8388608" it goes back working.

[jg]

Chris, can you please work with DanW to get the FBSize fixed?

Jordan, after Trial-2, I'd really like to get the fbsize settings from the operating system, rather than requiring FBsize in config files.

xorg.conf, die, die, die!!!

[cjb]

We're saying that 8M is correct and 16M is incorrect, then?

8M isn't enough to rotate the screen, so I think the FBSize is already correct (at 16M). We'd best wait for Jordan's input.

[jg]

More memory should always be good, so yes, this should be in Jordan's lap.

[JordanCrouse]

8MB is correct on GX, and 16MB is correct on LX, as per agreement. Sounds like we're going to need multiple configs. Sorry folks.

[cjb]

Ah, I see. Can we rotate on GX, then, or not?

[JordanCrouse]

Yes. GX doesn't have the command buffer (which kills off 2Mb right off the bat). We jumped to 16Mb on the B3 because we could, and because Sugar consumed so much pixmap memory, that we didn't have anything left over for things like cursors at 8MB.

Rotation requires a buffer of 1200 * 2 * 900 (2160000), which is carved out before we allocate pixmap memory, so Sugar cannot interfere. That plus the visible space (also 2160000) leaves us just under 4Mb for pixmap memory which has proven to be correct in the past.

[JordanCrouse]

When I say correct, I mean enough.

[JordanCrouse]

Another thought - remember that we don't get to choose how much memory we have - the firmware has long ago chosen for us how much memory we get. I can put in code to read it from the framebuffer, but thats going to require an act of Jim for trial-2.

[JordanCrouse]

The attached un-tested patch should do the trick.

[jg]

Thanks for the patch; we can deal with the fbsize from the kernel part after Trial-2, as I said above.

The problem is we've definitely uncovered a GX X driver bug; see above.

[JordanCrouse]

What bug? OFW gives the GX 8Mb of video memory, we tell X it has 16Mb - when the EXA engine starts trying to put pixmaps in the >8Mb space, bad things will happen.

[jg]

you are right....

My eyes are crosseyed from too much bug mail.

Messing with the config files is probably as risk prone as fixing the driver at this point, from a wuick read of the patch.

Chris, Dan should be getting his systems Wednesday, but might not. Could you test Jordan's driver patch on both GX and LX? Then we can drop the fbsize spec entirely from the xorg.conf file.

[cjb]

Yes, I can test tomorrow.

Thanks for getting us a patch so quickly, Jordan!

[cjb]

Attached a version of the patch that compiled okay. The headers might need #if defined(..) around them. Jordan, could you commit a version of this and reassign to dcbw to build a new RPM? Thanks.

[jg]

Tested, approved for inclusion in the Trial-2 build. Thanks all!

[JordanCrouse]

Committed to d.l.o - build on, man, build on.

[jfuhrer]

I tested build 525 on a B2 briefly and had no problems with this bug, but I'd like to be a bit more sure before I or someone else closes this as fixed.

[jg]

We have every reason to believe this is fixed. Reopen if it reappears.