lkml.org 
[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Blank console but X11 works on MCP79 - old regression since 3.8
    On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@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
    >>
    >> <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.
    >
    > 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

    \
     
     \ /
      Last update: 2017-11-17 20:37    [W:4.009 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site