[Nouveau] [Bug 95334] GM107 with 2560x1440 display on HDMI selects suboptimal resolution 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=95334 Henk Poley changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 95334] GM107 with 2560x1440 display on HDMI selects suboptimal resolution 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=95334 --- Comment #13 from Henk Poley --- Nice if your bugs are fixed in advance ;) Performance is more sluggish than the proprietary driver. But it picks the native resolution using Linux v4.5.1. Much better. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93629] [NVE6] complete system freeze, PGRAPH engine fault on channel 2, SCHED_ERROR [ CTXSW_TIMEOUT ]
https://bugs.freedesktop.org/show_bug.cgi?id=93629 --- Comment #21 from Dan Moulding --- Roy, I can also give the patch a try on my setup tomorrow and will let you know how it goes. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v5 00/13] PRIME Synchronization
On 29.04.2016 07:41, Dave Airlie wrote: > On 13 April 2016 at 14:17, Alex Goins wrote: >> Hello all, >> >> These patches change the xserver to support setting up PRIME with double >> buffering, and implement double buffered PRIME sink and source support in >> the modesetting driver. In addition to these changes, I've upstreamed a >> couple of patches to the i915 DRM driver that mesh with these, and have >> implemented double buffered PRIME source support in the NVIDIA proprietary >> driver (pending release.) >> >> Previous cover letters: >> v4: https://lists.x.org/archives/xorg-devel/2016-March/048944.html >> v3: http://lists.x.org/archives/xorg-devel/2016-February/048677.html >> v2: http://lists.x.org/archives/xorg-devel/2016-January/048434.html >> v1: http://lists.x.org/archives/xorg-devel/2015-November/048039.html >> >> I wasn't able to get any of my questions answered in the last thread, so I >> addressed the issues how I saw fit. Aside from some small tweaks, the biggest >> changes in this patch set involve resolving the ambiguity with >> rrSetScanoutPixmap(). Instead of using multiple calls to >> rrSetScanoutPixmap() to >> setup scanout pixmaps for flipping, the scanout pixmap setting is done >> implicitly in rrEnableSharedPixmapFlipping(). >> >> There are two new patches that fix outstanding bugs with >> drmmode_set_scanout_pixmap(), with details in their respective commit >> messages: >> modesetting: Internal storage of scanout pixmaps >> modesetting: Always tear down scanout pixmap >> >> Getting RRReplaceScanoutPixmap() working with synchronization would require >> an >> ABI change to pass in two pixmaps instead of one, so I just made it fail >> gracefully in the synchronized case. None of the drivers that I implemented >> PRIME synchronization for seem to use RRReplaceScanoutPixmap(). In fact, I >> believe it is currently broken with the modesetting driver without the above >> 2 >> patches. > > Okay I've finally gotten around to playing with these today. I'm using > a i915 + nouveau > system with nouveau running as the master. Both using modesetting DDX. > > The basics seem to work okay, but I am seeing some issues I'm not 100% sure > are the fault of these patches. > > Scenario 1: > start X, start mutter against X (using DRI3), start gnome-terminal, > drag g-t around > seems smooth. > set provider output, xrandr in a new display, drag g-t around, I get > choppy rendering > on the main display, the offloaded display is smooth! > > I don't think this happens with DRI2 mutter, so I'm not 100% sure what > is going on there, > I assume it's something to do with page flipping not being allowed for > present anymore. > > Scenario 2: > start X, set provider output, xrandr in a new display, start mutter in > DRI3 mode, things > go horribly wrong. Again it seems fine in DRI2 mode. so I expect this > is some interaction > with the present extension fighting this. > > I'm going to try and look at the interfaces a bit more now that I have > it running on a machine. > > Dave. > Generally speaking nouveau/DRI3 -is- half-broken, talk to Skeggs and try to solve it once and for all. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 95351] lockup on kde startup
https://bugs.freedesktop.org/show_bug.cgi?id=95351 Martin Bednar changed: What|Removed |Added Attachment #123620|0 |1 is obsolete|| --- Comment #3 from Martin Bednar --- Created attachment 123622 --> https://bugs.freedesktop.org/attachment.cgi?id=123622&action=edit dmesg 4.5.2 It's extracted from journalctl, so instead of nouveau I grepped it for kernel. I hope it's more complete this way. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 95351] lockup on kde startup
https://bugs.freedesktop.org/show_bug.cgi?id=95351 Roy changed: What|Removed |Added Status|NEW |NEEDINFO -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 95351] lockup on kde startup
https://bugs.freedesktop.org/show_bug.cgi?id=95351 --- Comment #2 from Roy --- (In reply to Martin Bednar from comment #1) > Created attachment 123620 [details] > dmesg grepped for nouveau on kernel 4.5.2 > > Tried newer kernel (4.5.2), still happens. Would you mind posting the full log rather than filtering/grepping through? Some of the backtrace has gone missing, and it'd be good to see other events in the system just for reference. Thanks! -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 95351] lockup on kde startup
https://bugs.freedesktop.org/show_bug.cgi?id=95351 Martin Bednar changed: What|Removed |Added Attachment #123619|0 |1 is obsolete|| --- Comment #1 from Martin Bednar --- Created attachment 123620 --> https://bugs.freedesktop.org/attachment.cgi?id=123620&action=edit dmesg grepped for nouveau on kernel 4.5.2 Tried newer kernel (4.5.2), still happens. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 95351] New: lockup on kde startup
https://bugs.freedesktop.org/show_bug.cgi?id=95351 Bug ID: 95351 Summary: lockup on kde startup Product: Mesa Version: 11.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: seraf...@gmail.com QA Contact: nouveau@lists.freedesktop.org Created attachment 123619 --> https://bugs.freedesktop.org/attachment.cgi?id=123619&action=edit complete dmesg when hung lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [NVS 300] (rev a2) On plasma5 (5.6) session startup, the entire GUI freezes (except cursor, that still moves). Always before plasma initializes. reproducible every time. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 95334] GM107 with 2560x1440 display on HDMI selects suboptimal resolution 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=95334 --- Comment #12 from Hans de Goede --- Hi, This is likely caused by the hdmi clock restrictions in the nouveau kernel driver, which are fixed by this commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a0c96c075bb4517d4ce4fb6750ee0a3cf38714c Which is available in the 4.5 (and later) kernels, can you please upgrade your kernel to 4.5 and try again? Regards, Hans -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
