similar to: [PATCH 1/2] drmmode: fix screen resize without acceleration

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"

Make it a Bool consistently, as declared in header. Reported-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com> --- src/nouveau_present.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/nouveau_present.c b/src/nouveau_present.c index 4de1e6e..699a58d 100644 --- a/src/nouveau_present.c +++

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New nouveau DDX release. Ben Skeggs (1): Bump version to 1.0.12 Ilia Mirkin (14): copy: don't bother trying to create copy on pre-nva3 allow path to envyas binary to be specified kepler: remove unnecessary texbars, add live-only tex for nvf0 use defined method names where available nv50: explicitly disable

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New nouveau DDX release. Ben Skeggs (1): Bump version to 1.0.12 Ilia Mirkin (14): copy: don't bother trying to create copy on pre-nva3 allow path to envyas binary to be specified kepler: remove unnecessary texbars, add live-only tex for nvf0 use defined method names where available nv50: explicitly disable

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Highlights: - Support for server managed fd's. - Glamor support. - Maxwell support. - DRI3 and initial Present support. - vsync'ed kms pageflip performance fixes when running on Linux 3.13+ - Multi-display vsync, vblank, swap scheduling, timestamping fixes. - Multi x-screen support fixes. - ZaphodHead support on for

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Highlights: - Support for server managed fd's. - Glamor support. - Maxwell support. - DRI3 and initial Present support. - vsync'ed kms pageflip performance fixes when running on Linux 3.13+ - Multi-display vsync, vblank, swap scheduling, timestamping fixes. - Multi x-screen support fixes. - ZaphodHead support on for

Hello everyone. I seem to have a bit of a problem running some 3D accelerated games under wine, while using the open-source ATI Radeon driver. My graphics card is Radeon 9700, and the open-source drivers overall work much better than the proprietary fglrx. The fglrx driver allows me (in most cases) to run games like Temple of Elemental Evil (particularily) or Morrowind normally, but I can't

Hi, On 30-07-15 16:09, Ilia Mirkin wrote: > FWIW this is a fail on nv50+ as well. See for example > https://bugs.freedesktop.org/show_bug.cgi?id=91445 > > My suspicion is that this is due to the lack of PUSH_KICK in the *Done > exa handlers -- works fine with DRI2, but DRI3 has no synchronization > and so the commands never get flushed out. Easily verified by sticking >

I'm aware of this issue, and am experiencing it myself. The issue is that drmmode_event_handler takes up more and more CPU time. It seems like some events are being "left behind". I haven't had time to debug it further yet though. I also have DRI3 enabled, but only very rarely do I make use of my secondary GPUs, and I'm pretty sure I've seen the problem happen without

I observed this bug for quite some time, but so far I workarounded it with just setting DRI2 (default) in xorg.conf.d/20-nouveau.conf Now with two GPU i iwsh to use DRI3, so right now it set up like this: cat /etc/X11/xorg.conf.d/20-nouveau.conf Section "Device" Identifier "Card0" Driver "nouveau" Option "PageFlip" "1" #Option

http://bugs.freedesktop.org/show_bug.cgi?id=16285 Summary: First display corrupted when second screen plugged at boot Product: xorg Version: 7.3 Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo: nouveau

We don't really expect to have too many events in the queue. If there are, then the algorithm we use isn't appropriate. Add a warning when the queue gets very long, as it's an indication of something having gone wrong. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/drmmode_display.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git

Yes, you are right - the Intel-chip is connected to the display, it just offloads 3D work to do to the nVidia-chip, which isn't even to tell how to get the EDID. I just wanted to try it out, simply for two reasons: 1. I heard that nouveau now "supports" the chip, and since I got the hardware, I wanted to try it out - just for the fun of it. :) 2. As far as I am informed, a way to

Hi, On 03-08-15 17:36, Ilia Mirkin wrote: > On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 30-07-15 16:09, Ilia Mirkin wrote: >>> >>> FWIW this is a fail on nv50+ as well. See for example >>> https://bugs.freedesktop.org/show_bug.cgi?id=91445 >>> >>> My suspicion is that this is

Hello, I try to run StarCraft on FreeBSD 7.0 using wine 1.1.1. The game hangs while I'm running it (I can see loading and image with 3 characters). Also StarEdit is very slow, however it doesn't hang. I installed Stronghold Crousader on FreeBSD using wine and it seems to work fine. I installed some linux games (unreal tournament 2004, unreal tournament, tuxracer) and I suppose that DRI

Straight port of Matthias Hopf's KMS backlight code for xf86-video-intel, with reformatting and a couple of minor cleanups. Works fine on my MacBookAir2,1. Signed-off-by: Daniel Stone <daniel at fooishbar.org> --- src/drmmode_display.c | 269 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 268 insertions(+), 1 deletions(-) diff --git a/src/drmmode_display.c

This is the initial release of the xf86-video-amdgpu driver. It was forked from the xf86-video-ati radeon driver and modified to support the amdgpu kernel driver via libdrm_amdgpu, and by extension the latest AMD GPU families Tonga, Carrizo, Iceland, Fiji and Stoney. Some functionality was removed because it's not relevant for the GPUs supported by the amdgpu kernel driver, but other than