similar to: Nouveau Digest, Vol 131, Issue 3

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 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> >> To: Mario Kleiner <mario.kleiner.de at gmail.com> >> Cc: nouveau

The various clut handling functions like a setup consistent with the x-screen color depth. Otherwise we observe improper sampling in the gamma tables at depth 30. Tested at depths 16, 24 and 30 and tested at depths 24 and 30 that xgamma and gamma table animations work, and with measurement equipment to make sure identity gamma ramps actually are identity mappings at the output. Signed-off-by:

On 03/03/2018 12:59 AM, Ilia Mirkin wrote: > 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

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: https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)

On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner > <mario.kleiner.de at gmail.com> wrote: >> On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >>> >>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner >>> <mario.kleiner.de at gmail.com> wrote: >>>> >>>>

The various clut handling functions like a setup consistent with the x-screen color depth. Otherwise we observe improper sampling in the gamma tables at depth 30. Tested at depths 16, 24 and 30 and tested at depths 24 and 30 that xgamma and gamma table animations work, and with measurement equipment to make sure identity gamma ramps actually are identity mappings at the output. v2: Also deal

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 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

Dear nouveau hackers, I got as far as figuring out that Xinerama is deprecated now... Too bad WindowMaker doesn't play well with RandR. While painfully learning about it, I managed to crash my Xorg 1.5.3 server through the nouveau driver. The attached patch fixes it. To reproduce the crash, simply run X with Xinerama enabled. $ gdb hw/xfree86/Xorg Xorg.core [...] Core was generated by

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 Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner <mario.kleiner.de at gmail.com> wrote: > On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >> >> 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

On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner >> <mario.kleiner.de at gmail.com> wrote: >>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >>>> >>>> On Fri, Mar 2, 2018 at 6:46

http://bugs.freedesktop.org/show_bug.cgi?id=18286 Summary: GeForce 8300 not supported (10de:0848/C77/MCP77) Product: xorg Version: 7.4 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

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

https://bugs.freedesktop.org/show_bug.cgi?id=111841 Bug ID: 111841 Summary: Setting gamma or color temperature on GK104 causes horizontal artifacts / flickering Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority:

From: Christopher James Halse Rogers <raof at ubuntu.com> Barring some (admittedly significant) missing optimisations? this is reasonably complete, but can't be applied until the Xserver patch has landed, and that needs more work. This demonstrates the approach, however. There's probably some code to be shared with XWayland support, around the output handling (or lack thereof) and

Revised patch set v2. [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c [PATCH 2/8] drm/nouveau: use bo accessors for push buffers [PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops [PATCH 4/8] drm/nv50: proper notifier_bo access in nv50_display_vblank_crtc_handler() [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors [PATCH 6/8] drm/nouveau: screen_base and

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

From: Daniel Vetter <daniel.vetter at ffwll.ch> Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 Author: Mario Kleiner <mario.kleiner.de at gmail.com> Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.