Messages in this thread |  | | From | Ilia Mirkin <> | Date | Fri, 17 Nov 2017 12:41:17 -0500 | Subject | Re: Blank console but X11 works on MCP79 - old regression since 3.8 |
| |
On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary <linux@rainbow-software.org> wrote: > @@ -483,8 +483,8 @@ > nouveau 0000:02:00.0: disp: 0860: 00000000 -> 00000500 > nouveau 0000:02:00.0: disp: 0864: 00000000 > nouveau 0000:02:00.0: disp: 0868: 00000000 -> 04000500 > -nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100500 > -nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 00001e00 > +nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100a00 > +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 > nouveau 0000:02:00.0: disp: 0878: 00000000 > nouveau 0000:02:00.0: disp: 0880: 05000000 > > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in 64MB > case. Why? > > I get blank screen even with 64MB with video=1280x1024-8 kernel parameter. > Console works with video=1280x1024-16 even with 32MB stolen memory. > > Conclusions: 8-bit support is broken and bpp reduction is weird.
OK, well that makes a *ton* of sense (8bpp being broken).
I think the idea of bpp reduction is that when you're on your shiny new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating all that to a pinned fbcon - almost half of that would go to a single 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to have at least a few fb-sized buffers for backbuffer rendering, etc.
The specific limits could probably use tweaking - I think they only consider VRAM size, not the fb size.
I guess 8bpp worked prior to the change you bisected though, so we should figure out what we did wrong in the new code.
-ilia
|  |