On 06.05.2015 21:05, poma wrote: > On 28.04.2015 20:03, poma wrote: >> On 27.04.2015 11:51, Joerg Lechner wrote: >>> Hi, >>> the reason why I ask again, if really the nouveau driver is active, when using Geeqie, is a look into /var/log/Xorg.0.log, >>> where in my case (hybrid grafics intel/nvidia) I don't find the nouveau driver, which would explain, why I don't have >>> the error described in this thread. >>> >>> see part of /var/log/Xorg.0.log: >>> 148.883] Module class: X.Org Video Driver >>> [ 148.883] ABI class: X.Org Video Driver, version 19.0 >>> [ 148.883] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: >>> i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, >>> 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, >>> Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, >>> GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 >>> [ 148.884] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000 >>> [ 148.884] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100 >>> [ 148.884] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300 >>> >>> Therefore my question in case of Matthews Lenovo, is it really the nouveau driver or another video driver, >>> which causes the Geeqie error? >>> Kind Regards >>> >>> >>> >>> -----Ursprüngliche Mitteilung----- >>> Von: Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> >>> An: For testing and quality assurance of Fedora releases <test@xxxxxxxxxxxxxxxxxxxxxxx> >>> Verschickt: So, 26 Apr 2015 9:25 pm >>> Betreff: Re: nouveau driver freeze -- can anyone else reproduce this? >>> >>> >>> On Sun, Apr 26, 2015 at 08:54:48PM +0200, drago01 wrote: >>>>>> What kind of menu >>> is that? How big is it (height / width in pixels) ? >>>>> It's the right-click >>> context menu you get when clicking on a filename >>>>> in geeqie. It's nothing >>> special -- 14 items in three groups, with "View >>>>> in new window" being the >>> longest item. 150x300 pixels, maybe? >>>> OK so nothing "special" about it ... >>> odd. >>> >>> Yeah. I did get what seemed like the same behavior with a context menu >>> in >>> Gimp *once*, but can't reproduce there. However, geeqie seems to >>> very reliably >>> trigger it. And it seems to be only _that_ right-click >>> menu, in the filelist, >>> not others in the app. I guess I can go around >>> right-clicking in other programs >>> to see if it happens. >>> >>> One thing that occurs to me is that the placement of this >>> menu means >>> that when it comes up, it almost always comes up on top of a >>> scrollbar >>> and into another panel. *Maybe* that interaction causes some >>> rendering >>> need which triggers the bug? Seems like a longshot, and I really >>> don't >>> know what I'm talking about here. :) >>> >>> >> >> >> If I understood Ilia, >> https://bugs.freedesktop.org/show_bug.cgi?id=89842#c5 >> >> the problem is somewhere in between: >> libdrm-2.4.60 >> http://cgit.freedesktop.org/mesa/drm/commit/?id=5f7b672 >> & >> libdrm-2.4.59 >> http://cgit.freedesktop.org/mesa/drm/commit/?id=d2e0f55 >> >> i.e. >> 74 commitas >> >> What are you waiting for? :) >> >> man 1 git-bisect >> >> > > https://bugs.freedesktop.org/show_bug.cgi?id=89842#c10 > > Thus you can quickly test whether Skeggs's commit really works: $ cd ~/rpmbuild/SOURCES/ $ git clone git://pkgs.fedoraproject.org/libdrm.git . $ sed -i 's/#define gitdate 20130117/%define gitdate 20150506/' libdrm.spec $ sed -i 's/: 1/: 100/' libdrm.spec $ sed -i 's/%patch5/#%patch5/' libdrm.spec $ sed -i '/dr[im]stat\|get[csv]\|name_from_fd\|openclose\|setversion\|updatedraw\|bindir}\/exynos/d' libdrm.spec $ sed -i '/kmstest/ a\%{_bindir}/proptest' libdrm.spec $ ./make-git-snapshot.sh $ pkexec yum-builddep libdrm $ rpmbuild -ba libdrm.spec -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
