Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <201711171833.52855.linux@rainbow-software.org>
References: <201711171526.01053.linux@rainbow-software.org>
 <CAKb7UvgEyKTHK3JMrEdLrMXZP0SAPH9opDFGAWjeFCw4s+NEUA@mail.gmail.com> <201711171833.52855.linux@rainbow-software.org>
From:   Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Fri, 17 Nov 2017 12:41:17 -0500
Message-ID: <CAKb7Uvg9BQ6yAXXt+PbVf_c3Wzx3vkA0VdzkcO6qnRC2nJ7AOQ@mail.gmail.com>
Subject: Re: Blank console but X11 works on MCP79 - old regression since 3.8
To:     Ondrej Zary <linux@rainbow-software.org>
Cc:     Ben Skeggs <bskeggs@redhat.com>,
        "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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

From 1584347650595426325@xxx Fri Nov 17 20:47:42 +0000 2017
X-GM-THRID: 1584342040192660961
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread