similar to: [PATCH] nouveau: use uppercase for chipset name

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

v2: Fix build against Xservers without Wayland support Don't try to acquire/drop drm master under Wayland Refresh for xserver 1.13 kill-all-direct-access-to-xf86Screens Remove #ifdef soup in favour of xwayland compat header Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com> --- configure.ac | 7 ++ src/Makefile.am |

Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com> --- This is mostly just for testing, although it should be safe to apply to nouveau trunk. src/nouveau_dri2.c | 34 +++++++++++ src/nv_driver.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++----- src/nv_type.h | 7 +++ 3 files changed, 191 insertions(+), 13 deletions(-) diff

On Sun, 13 Sep 2009 20:06:59 -0700 (PDT) darktama at kemper.freedesktop.org (Ben Skeggs) wrote: > src/drmmode_display.c | 6 ++++++ > src/nv_driver.c | 2 ++ > 2 files changed, 8 insertions(+) > > New commits: > commit 6c045fc44783454180d7b3d00b5f25436bd5544e > Author: Ben Skeggs <bskeggs at redhat.com> > Date: Mon Sep 14 13:04:12 2009 +1000 >

--- src/nv_driver.c | 32 +------------------------------- 1 files changed, 1 insertions(+), 31 deletions(-) diff --git a/src/nv_driver.c b/src/nv_driver.c index 248a151..9606d97 100644 --- a/src/nv_driver.c +++ b/src/nv_driver.c @@ -315,8 +315,6 @@ NVAdjustFrame(int scrnIndex, int x, int y, int flags) /* * This is called when VT switching back to the X server. Its job is * to

Based on the original patch by Christoph Bumiller, but since it depends on kernel support patched I cannot push it yet. The changes are that I enable vblank by default, and offset takes OFFSET_HIGH/LOW instead of something relative to notifier_bo. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/man/nouveau.man b/man/nouveau.man index 7c72907..8765569

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: add 0x130 as a valid chip type early on in detection src/nouveau_copy.c | 2 ++ src/nouveau_exa.c | 1 + src/nv_accel_common.c | 1 + src/nv_driver.c | 4 ++++ src/nv_type.h | 1 + src/nvc0_accel.c | 6 ++++++ 6 files changed, 15 insertions(+) diff --git a/src/nouveau_copy.c

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested. I don't have the hardware. src/nv_driver.c | 2 ++ src/nvc0_accel.c | 10 +++++++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/src/nv_driver.c b/src/nv_driver.c index fff83f8..61940a8 100644 --- a/src/nv_driver.c +++ b/src/nv_driver.c @@ -390,6 +390,7 @@ NVHasKMS(struct pci_device *pci_dev,

This requires at least a quick test. :-) Acked-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> On 10/16/2016 09:14 PM, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Untested. I don't have the hardware. > > src/nv_driver.c | 2 ++ > src/nvc0_accel.c | 10 +++++++++- > 2 files changed, 11 insertions(+), 1

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nv_driver.c | 2 ++ src/nvc0_accel.c | 10 +++++++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/src/nv_driver.c b/src/nv_driver.c index fff83f8..61940a8 100644 --- a/src/nv_driver.c +++ b/src/nv_driver.c @@ -390,6 +390,7 @@ NVHasKMS(struct pci_device *pci_dev, struct xf86_platform_device *platform_dev)

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested. src/nouveau_copy.c | 2 ++ src/nouveau_exa.c | 1 + src/nv_accel_common.c | 1 + src/nv_driver.c | 3 +++ src/nv_type.h | 1 + src/nvc0_accel.c | 6 ++++++ 6 files changed, 14 insertions(+) diff --git a/src/nouveau_copy.c b/src/nouveau_copy.c index 7118a7a..7fbcc87 100644 --- a/src/nouveau_copy.c

Hi! I've written a small amount of code that gets the randr 1.2 branch much closer to working for me on a laptop. Most of the changes are fairly obvious, but a couple of comments: 1) The changes to nv_crtc.c are clearly bogus, but I'm not sure what on earth these registers do. I need to set them to get a moderately sane-looking picture 2) The fp registers poked in nv_output.c

- Only for sufficiently new xserver's and exa_driver_pixmaps. --- src/nouveau_exa.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++++-- src/nv_driver.c | 51 +++++++++++-- src/nv_proto.h | 4 + src/nv_type.h | 12 +++- 4 files changed, 267 insertions(+), 17 deletions(-) diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c index 93fc3c5..074a226 100644 ---

--- src/nv_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/nv_driver.c b/src/nv_driver.c index e726292..4c40763 100644 --- a/src/nv_driver.c +++ b/src/nv_driver.c @@ -377,6 +377,7 @@ NVHasKMS(struct pci_device *pci_dev, struct xf86_platform_device *platform_dev) case 0xf0: case 0x100: case 0x110: + case 0x120: break; default: xf86DrvMsg(-1, X_ERROR, "Unknown

X-Server versions older than 1.16.3 have bugs in their DRI3/Present implementation which impair nouveau, so it is better to stick to good old DRI2 by default on such servers. E.g., page flipping doesn't work at all under DRI3/Present with older servers, and use of extensions like OML_sync_control, SGI_video_sync or INTEL_swap_events also causes failure of Present. nouveau's glamor accel

That would be great, as long as it does only that and does not go into the "drivername" territory. As the said driver ;-) "A driver name to use can be provided instead of simple boolean value, which will be passed to the GL implementation for it to load the appropriate backend." -Emil On 4 July 2015 at 18:17, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > IMO

The DRI option with the intel ddx can be used to indicate the following - whether dri is disabled - the dri "version" - dri1, dri2, dri3 - the dri module name - doo_dri.so bar_dri.so I'm not sure how exactly it's supposed to work/works, and I believe most of that is due to legacy reasons. I'm just saying let's not do the whole thing - just the dri "version"

There's no way to get acceleration with GM20x... I'd rather save this until there is. For now reject the load and let the modesetting driver get used. OTOH, the DDX isn't released/integrated into distros at an infinite rate, and eventually GM20x will probably get acceleration.... could go either way. My immediate reaction is to hold though. There may be further differences... On Sun,

On 07/07/2015 09:51 PM, Ilia Mirkin wrote: > Lastly, from some discussions with ajax on IRC, it appears that DRI3 > is half-baked at best wrt sync between server and client. I think we > should just disable it by default for now, until issues are ironed > out. (Rather than what this patch has, which is default-on for Xorg > > some version.) What are the remaining known trouble

With this patch the DDX almost works with GK20A, the missing piece is adding COHERENT mappings to the right places. ;-) If you specify NOUVEAU_BO_APER the kernel will truncate valid_domains to the domains specified at creation time. This means that as long as we only specify the correct domain in nouveau_allocate_surface the effect is still the same. Signed-off-by: Maarten Lankhorst <dev at