similar to: nouveau 30bpp / deep color status

On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: > On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > > In case anyone's curious about 30bpp framebuffer support, here's the > > current status: > > > > Kernel: > > > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > > and I've also written a

On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner <mario.kleiner.de at gmail.com> wrote: > On 02/05/2018 12:50 AM, Ilia Mirkin wrote: >> >> In case anyone's curious about 30bpp framebuffer support, here's the >> current status: >> >> Kernel: >> >> Ben and I have switched the code to using a 256-based LUT for Kepler+, >> and I've also

On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > In case anyone's curious about 30bpp framebuffer support, here's the > current status: > > Kernel: > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > and I've also written a patch to cause the addfb ioctl to use the > proper format. You can pick this up at: > >

On 02/05/2018 12:50 AM, Ilia Mirkin wrote: > In case anyone's curious about 30bpp framebuffer support, here's the > current status: > > Kernel: > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > and I've also written a patch to cause the addfb ioctl to use the > proper format. You can pick this up at: > >

On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote: > On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: >> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: >> > In case anyone's curious about 30bpp framebuffer support, here's the >> > current status: >> > >> > Kernel: >>

On 03/02/2018 11:29 PM, Ilia Mirkin wrote: > On Fri, Mar 2, 2018 at 5:16 PM, Mario Kleiner > <mario.kleiner.de at gmail.com> wrote: >> On 03/01/2018 07:21 PM, nouveau-request at lists.freedesktop.org wrote: >>> >>> >>> Message: 1 >>> Date: Thu, 1 Mar 2018 08:15:55 -0500 >>> From: Ilia Mirkin <imirkin at alum.mit.edu> >>>

On 03/01/2018 07:21 PM, nouveau-request at lists.freedesktop.org wrote: > > Message: 1 > Date: Thu, 1 Mar 2018 08:15:55 -0500 > From: Ilia Mirkin <imirkin at alum.mit.edu> > To: Mario Kleiner <mario.kleiner.de at gmail.com> > Cc: nouveau <nouveau at lists.freedesktop.org> > Subject: Re: [Nouveau] [PATCH] Fix colormap handling at screen depth > 30. >

On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner <mario.kleiner.de at gmail.com> wrote: > Cc'ing mesa-dev, which was left out. > > > On 03/05/2018 01:40 PM, Ilia Mirkin wrote: >> >> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner >> <mario.kleiner.de at gmail.com> wrote: >>> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs

Cc'ing mesa-dev, which was left out. On 03/05/2018 01:40 PM, Ilia Mirkin wrote: > On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner > <mario.kleiner.de at gmail.com> wrote: >> On 02/05/2018 12:50 AM, Ilia Mirkin wrote: >>> >>> In case anyone's curious about 30bpp framebuffer support, here's the >>> current status: >>> >>>

On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote: > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul <lyude at redhat.com> wrote: > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > > > I

On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? I don't think that display_info.bpc actually implies a minimum bpc, only a maximum bpc iirc (Ville would know the answer to this one). The other thing to note here is that we want to assume

Another log, per Lyude on #nouveau. j On Tuesday, January 14, 2020 8:52:51 AM AKST Joshua J. Kugler wrote: > Here we go! > > j > > On Tuesday, January 14, 2020 7:08:20 AM AKST Ilia Mirkin wrote: > > Hi Joshua, > > > > Not a fix for your issue, but Ben noticed this (and fixed it): > > > >

On Fri, Nov 28, 2014 at 02:14:24PM +0900, Alexandre Courbot wrote: > On 11/28/2014 01:39 AM, Thierry Reding wrote: > >Tegra K1 and later use a GPU that can be driven by the Nouveau driver. > >But the GPU is a pure render node and has no display engine, hence the > >scanout needs to happen on the Tegra display hardware. The GPU and the > >display engine each have a

Sorry, haven't really looked since our initial interaction. That EDID decodes as: Block 0, Base EDID: EDID Structure Version & Revision: 1.0 Vendor & Product Identification: Manufacturer: SEC Model: 21569 Made in: 2010 Basic Display Parameters & Features: Digital display Maximum image size: 34 cm x 19 cm Gamma: 2.20 RGB color display First

Hi Joshua, Not a fix for your issue, but Ben noticed this (and fixed it): https://github.com/skeggsb/nouveau/commit/024bda7d2b0c3b0731433d60a494c78ab58cb216 which is what causes us to even try 540MB/s link training. However with this fix applied, it'll just give up faster. I'm told eDP is generally a single lane, and you're trying to get more than 270MB/s. So ... the question is ...

On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner <mario.kleiner.de at gmail.com> wrote: > On 03/02/2018 11:29 PM, Ilia Mirkin wrote: >> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set >> still only gets called with a 256-entry LUT? If so, that works nicely >> here, but is not intuitive :) > > Yes. Lots of remapping in the server, i get dizzy

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Realized when I moved nouveau over to using the atomic DP MST VCPI helpers that I forgot to ensure that we clamp the BPC to 8 to make us less likely to run out of bandwidth on a topology when enabling multiple displays that support >8 BPC - something we want to do until we have support for dynamically selecting the bpc based on the topology's available bandwidth, since userspace isn't

This allows us to advertise more modes especially on HDR displays. Fixes using 4K at 60 modes on my TV and main display both using a HDMI to DP adapter. Also fixes similiar issues for users running into this. Cc: stable at vger.kernel.org # 5.10+ Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 32 +++++++++++++++++++++++++

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually