similar to: [Bug 94367] Under KDE5 menus drawing is corrupted

https://bugs.freedesktop.org/show_bug.cgi?id=94367 --- Comment #4 from Riku Voipio <riku.voipio at iki.fi> --- Created attachment 129248 --> https://bugs.freedesktop.org/attachment.cgi?id=129248&action=edit Debian xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=94367 Aaron Plattner <aplattner at nvidia.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Driver/nVidia (open) |Driver/nouveau Assignee|aplattner at nvidia.com |nouveau at lists.freedesktop.o

https://bugs.freedesktop.org/show_bug.cgi?id=94367 Martin Peres <martin.peres at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #5 from Martin Peres

flight 21952 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop

flight 21930 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21930/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7

flight 21993 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21993/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 8

This package contains the configuration files, platform data, & Makefile templates for the old Imake build tool. Today is the 10th anniversary of X.Org moving off this tool for our own builds. While we continue to accept patches and publish updates for the benefit of other packages which still use Imake to build, we have not been actively maintaining, testing, or adding new OS or platform

https://bugs.freedesktop.org/show_bug.cgi?id=105722 Bug ID: 105722 Summary: Nouveau driver hangs when closing video playback Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

On Sun, 3 Apr 2005, Tom Eastep wrote: > Riku Nykanen wrote: > > Hi, > > > > I''m having problems with new Shorewall installation on Fedora Core 3 (had > > same problem with Core 2 and upgrade did not help even iptables was > > upgraded from 1.2.9 to 1.2.11). I''ve followed two nic example, but > > starting Shorewall drops all connections and

On 2019-12-02 13:42, Riku via dovecot wrote: > Hello. > My name is Riku. > > Currently, I use Dovecot as a proxy for another SMTP server. > However, this seems to cause the IP address of the "received" header > to be that of the proxy server. > Is it possible to change this so that the IP address of the sender is > entered? > The version of Dovecot is

> On 2 Dec 2019, at 19.23, Tom Sommer via dovecot <dovecot at dovecot.org> wrote: > > > On 2019-12-02 13:42, Riku via dovecot wrote: >> Hello. >> My name is Riku. >> Currently, I use Dovecot as a proxy for another SMTP server. >> However, this seems to cause the IP address of the "received" header >> to be that of the proxy server.

Hi, I''m having problems with new Shorewall installation on Fedora Core 3 (had same problem with Core 2 and upgrade did not help even iptables was upgraded from 1.2.9 to 1.2.11). I''ve followed two nic example, but starting Shorewall drops all connections and don''t permit any outgoing requests, even with "all allowed" policy. Policy file is below. Current setup

Hello. My name is Riku. Currently, I use Dovecot as a proxy for another SMTP server. However, this seems to cause the IP address of the "received" header to be that of the proxy server. Is it possible to change this so that the IP address of the sender is entered? The version of Dovecot is "2.3.8 (9df20d2db)". Sorry for the incomprehensible explanation. Thank you. Best

The menus stop drawing problem is still there in cvs. I can reproduce it 100% of the time by trying to use the File menu button in K3B. The other buttons work fine. Once i try to use the File menu all the other ones stop working. The fun doesn't stop there because trying to use it also causes all the other menus from drawing including the panel. nautilus from what i can tell stops

On 2016.10.11 17:46, Samuel Pitoiset wrote: > > > On 10/11/2016 02:18 PM, Martin Vorbach wrote: >> Samuel, >> >> the HP GT630 is unfortunately the GK107. Given we find the other GT630 >> model I will check it and come back to you. >> >> Are you interested in any of the other two cards? > > I'm (just) interested by Kepler cards actually. :-)

https://bugs.freedesktop.org/show_bug.cgi?id=104728 Bug ID: 104728 Summary: [possible regression] VMD crashes on startup on GT 640 / GK107 / NVE7 Product: Mesa Version: 17.2 Hardware: All OS: All Status: NEW Severity: major Priority: medium Component:

On 25/03/2014 17:17, Christian Zander wrote: > On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote: >> Hello, >> >> One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM >> at boot time but, if I blacklist the module and load it myself later on, >> it always succeeds. To make things weirder, the same card works great on >> another

On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote: > > Hello, > > One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM > at boot time but, if I blacklist the module and load it myself later on, > it always succeeds. To make things weirder, the same card works great on > another computer. > > Here is the relevant code in Nouveau to fetch

https://bugs.freedesktop.org/show_bug.cgi?id=92971 --- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> --- Nov 14 19:06:12 hpprol2 kernel: nouveau 0000:0a:00.0: fifo: PBDMA0: 80000000 [] ch 30 [007e6ab000 kscreenlocker_g[4257]] subc 6 mthd 2878 data a0c02020 A few things wrong with this picture... first off, nouveau never uses subchannel 6. Method 2878 is: lookup -a c8 -d SUBCHAN --

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller to switch the panel between its two GPUs. The panel mode in VBIOS is notoriously bogus on these machines. Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS if the vga_switcheroo handler is capable of temporarily switching the panel's DDC lines to the discrete GPU. This allows us to retrieve the EDID if the panel