[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKb7Uvjv23Po+a5cJWgYSPRDOO7UEv7o2LzD_OGLuUGT3dZ_3A@mail.gmail.com>
Date: Fri, 17 Nov 2017 14:37:36 -0500
From: Ilia Mirkin <imirkin@...m.mit.edu>
To: Ondrej Zary <linux@...nbow-software.org>
Cc: Ben Skeggs <bskeggs@...hat.com>,
"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Blank console but X11 works on MCP79 - old regression since 3.8
On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@...nbow-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
>>
>> <linux@...nbow-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 =/
I think the issue is this:
- OUT_RING(evo, nv_crtc->lut.depth == 8 ?
- NV50_EVO_CRTC_CLUT_MODE_OFF :
- NV50_EVO_CRTC_CLUT_MODE_ON);
Whereas now we always set 0xC0000000 (aka "ON").
-ilia
Powered by blists - more mailing lists