On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > 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.
Someone tested out a GF100 and it had the same issue. I've since determined that the color is that of the first entry in the LUT. With the above program, it's (192, 192, 192) which looks white. -ilia
