Ticket #2213 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Bottom half of screen goes blank in Neighborhood view

Reported by: jfuhrer Owned by: dcbw
Priority: blocker Milestone: Trial-2
Component: x window system Version:
Keywords: Cc: bernie, cjb, danw, JordanCrouse
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Attachments

get-fbsize-from-fb.patch Download (3.0 KB) - added by JordanCrouse 7 years ago.
amd-fbsize.patch Download (2.9 KB) - added by cjb 7 years ago.

Change History

Changed 7 years ago by bert

  • owner changed from dcbw to jg
  • component changed from sugar to x window system

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

Changed 7 years ago by jg

  • cc bernie added
  • owner changed from jg to JordanCrouse
  • priority changed from high to blocker
  • milestone changed from Untriaged to Trial-2

Changed 7 years ago by marco

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

Changed 7 years ago by jg

  • cc cjb, danw, JordanCrouse added

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!!!

Changed 7 years ago by 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.

Changed 7 years ago by jg

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

Changed 7 years ago by 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.

Changed 7 years ago by cjb

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

Changed 7 years ago by 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.

Changed 7 years ago by JordanCrouse

When I say correct, I mean enough.

Changed 7 years ago by 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.

Changed 7 years ago by JordanCrouse

The attached un-tested patch should do the trick.

Changed 7 years ago by JordanCrouse

Changed 7 years ago by 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.

Changed 7 years ago by 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.

Changed 7 years ago by jg

  • owner changed from JordanCrouse to cjb

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.

Changed 7 years ago by cjb

Yes, I can test tomorrow.

Thanks for getting us a patch so quickly, Jordan!

Changed 7 years ago by cjb

Changed 7 years ago by 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.

Changed 7 years ago by jg

  • owner changed from cjb to dcbw

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

Changed 7 years ago by JordanCrouse

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

Changed 7 years ago by 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.

Changed 7 years ago by jg

  • status changed from new to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.