On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> > wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >>> >>> <li...@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. >> >> Yes, booted 3.7 (last working kernel) and it's running in 8bpp. > > By the way, instead of booting $kernel, you can use modetest from > libdrm/tests. Not sure if it supports C8 though =/
It didn't. But it does now - I mailed a patch to dri-devel, also (with slight fix) available at https://people.freedesktop.org/~imirkin/patches/0001-modetest-add-C8-support-to-generate-SMPTE-pattern.patch This works on GK208 but not on G92 (whose display unit is much closer to your MCP79's). You can run as ./modetest -s DVI-I-1:1920x1200@C8 This should display a SMPTE pattern, and exit when you hit enter. When it does so, it doesn't restore fbcon, but you can swtich to another vty to get console back. I get a white picture on G92. Now just have to figure out how to fix it. Someone should also test on a G80 if possible, since that takes a different path as well. -ilia