Opened 10 years ago

Closed 10 years ago

Last modified 18 months ago

#2213 closed defect (fixed)

Bottom half of screen goes blank in Neighborhood view

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

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 (2)

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

Download all attachments as: .zip

Change History (24)

comment:1 Changed 10 years ago by bert

  • Component changed from sugar to x window system
  • Owner changed from dcbw to jg

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

comment:2 Changed 10 years ago by jg

  • Cc bernie added
  • Milestone changed from Untriaged to Trial-2
  • Owner changed from jg to JordanCrouse
  • Priority changed from high to blocker

comment:3 Changed 10 years ago by marco

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

comment:4 Changed 10 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!!!

comment:5 Changed 10 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.

comment:6 Changed 10 years ago by jg

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

comment:7 Changed 10 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.

comment:8 Changed 10 years ago by cjb

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

comment:9 Changed 10 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.

comment:10 Changed 10 years ago by JordanCrouse

When I say correct, I mean enough.

comment:11 Changed 10 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.

comment:12 Changed 10 years ago by JordanCrouse

The attached un-tested patch should do the trick.

Changed 10 years ago by JordanCrouse

comment:13 Changed 10 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.

comment:14 Changed 10 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.

comment:15 Changed 10 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.

comment:16 Changed 10 years ago by cjb

Yes, I can test tomorrow.

Thanks for getting us a patch so quickly, Jordan!

Changed 10 years ago by cjb

comment:17 Changed 10 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.

comment:18 Changed 10 years ago by jg

  • Owner changed from cjb to dcbw

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

comment:19 Changed 10 years ago by JordanCrouse

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

comment:20 Changed 10 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.

comment:21 Changed 10 years ago by jg

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:22 Changed 18 months ago by Quozl

  • Milestone Trial-2 deleted

Milestone Trial-2 deleted

Note: See TracTickets for help on using tickets.