Re: [gentoo-user] About ready to move /usr, /var and /home to LVM.
J. Roeleveld wrote: On Mon, April 16, 2012 3:47 pm, Dale wrote: J. Roeleveld wrote: On Sat, April 14, 2012 4:28 pm, Florian Philipp wrote: SNIPPED As we are out of rational ideas, have you tried unplugging the old disk? You don't need it for booting at the moment, right? AS SATA is hot-plugin capable, you can re-insert it later. Be careful here, not all SATA-controllers/ports on mainboards are hotplug capable. I have a mainboard that becomes really unstable when I try to hot(un)plug a harddisk. It runs perfectly fine as long as I switch the computer off before swapping harddrives. According to the manual, mine is. Given my luck, I don't want to try it. ;-) If the manual says it is, then probably it will be. I have 2 mainboards I tried it with that don't mention either way for hotswap in the manuals. One gets unstable, the other works perfectly. The last mainboard I bought actually has an option in the BIOS where I can specify per SATA-port which are to support hotswap or not ;) -- Joost I need to look again. Now that I think about it, I think only a couple of mine support it. I just plan to cut mine off and be safe, unless the house is on fire. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: ATI-drivers 12.3 with Kernel 3.4
Many thanks, Walt, your patches work just fine for me. Helmut. On 04/16/2012 08:45:14 PM, walt wrote: On 04/16/2012 06:09 AM, Helmut Jarausch wrote: Hi, does anybody know about patches for the ATI-drivers 12.3 to work with git-sources 3.4_rc3 ? Well, patch is too formal for the ugly hack I use :) After building your new kernel you should patch one kernel header file before building ati-drivers (taken from lkml): --- arch/x86/include/asm/compat.h.orig 2012-04-08 11:51:29.569528342 -0700 +++ arch/x86/include/asm/compat.h 2012-04-08 14:33:58.309972502 -0700 @@ -221,6 +221,7 @@ return (u32)(unsigned long)uptr; } +#ifdef CONFIG_x86_64 static inline void __user *arch_compat_alloc_user_space(long len) { compat_uptr_t sp; @@ -234,6 +235,15 @@ return (void __user *)round_down(sp - len, 16); } +#else + +static inline void __user *arch_compat_alloc_user_space(long len) +{ + struct pt_regs *regs = task_pt_regs(current); + return (void __user *)regs-sp -len; +} + +#endif static inline bool is_x32_task(void) { Here's the ugly part: some names in compat.h were changed recently, and I can't be bothered to do a proper fix, so I hacked this together instead: --- common/lib/modules/fglrx/build_mod/firegl_public.c 2012-03-23 13:38:48.0 -0700 +++ /tmp/firegl_public.c2012-04-16 10:45:41.426582953 -0700 @@ -4181,7 +4181,7 @@ { unsigned int p; KCL_DEBUG5(FN_FIREGL_KAS, %d\n, level_init); -for_each_cpu_mask(p, cpu_possible_map) +for (p=0; p4; p++) { KCL_DEBUG1(FN_FIREGL_KAS,Setting initial execution level for CPU # %d\n, p); preempt_disable(); NOTE: my new machine has 4 cpus, numbered 0 through 3, and I hardcoded that number into the ati code, above, instead of deciphering the new kernel headers. Ugly, ugly, ugly. But it works perfectly :) If you have two cpus you should change the p4 to p2, etc. And then wait for a professional fix from ati :p
[gentoo-user] Re: dev-libs/ppl-0.12 breaks gcc?
On 16/04/12 20:53, Doug Hunley wrote: On Mon, Apr 16, 2012 at 13:39, Michael Molmike...@gmail.com wrote: On Mon, Apr 16, 2012 at 1:34 PM, Doug Hunleydoug.hun...@gmail.com wrote: On Mon, Apr 16, 2012 at 13:20, Michael Molmike...@gmail.com wrote: Are you using ccache? nope. no ccache, no distcc What are you using for CFLAGS? -O2 -pipe -march=native -mtune=native -mpopcnt -msahf -fomit-frame-pointer -fforce-addr -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftree-loop-linear -ftree-loop-linear is an alias for -floop-interchange. They do the same thing.
Re: [gentoo-user] PCI video cards, hardware accel, upported by open-source drivers?
Since we're talking about video playback with open source drivers, any luck to intel onboard adapter users? I'm struggling with an HD3000 core i3 video adapter, can't playback 1080p without tearing. I was impressed with this same adapter running a racing game on a colleagues macbook air, smooth and aliased.
[gentoo-user] Re: PCI video cards, hardware accel, upported by open-source drivers?
On 17/04/12 17:11, Claudio Roberto França Pereira wrote: Since we're talking about video playback with open source drivers, any luck to intel onboard adapter users? I'm struggling with an HD3000 core i3 video adapter, can't playback 1080p without tearing. Tearing shouldn't occur when you use Xv for playback. Are you using GL instead? That might explain it.
[gentoo-user] depclean stopped working
emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) It also says: * Also, note that it may be necessary to manually uninstall * packages that no longer exist in the portage tree, since it may * not be possible to satisfy their dependencies. However, dev-libs/openssl is installed and seems to be in the tree: $ eix -e dev-libs/openssl [I] dev-libs/openssl Available versions: (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1 1.0.0g 1.0.0h **1.0.1 {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2 zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2 zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test)
Re: [gentoo-user] depclean stopped working
On Tue, 17 Apr 2012 18:01:43 +0300 Nikos Chantziaras rea...@gmail.com wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) It also says: * Also, note that it may be necessary to manually uninstall * packages that no longer exist in the portage tree, since it may * not be possible to satisfy their dependencies. However, dev-libs/openssl is installed and seems to be in the tree: $ eix -e dev-libs/openssl [I] dev-libs/openssl Available versions: (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1 1.0.0g 1.0.0h **1.0.1 {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2 zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2 zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test) I think you should file a bug against www-client/google-chrome It wants the exact version dev-libs/openssl:0.9.8 but the oldest in portage is dev-libs/openssl:0.9.8r Chances are the dev simply left off the version suffix by accident -- Alan McKinnnon alan.mckin...@gmail.com
[gentoo-user] Re: depclean stopped working
On 17/04/12 18:10, Alan McKinnon wrote: On Tue, 17 Apr 2012 18:01:43 +0300 Nikos Chantziarasrea...@gmail.com wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) It also says: * Also, note that it may be necessary to manually uninstall * packages that no longer exist in the portage tree, since it may * not be possible to satisfy their dependencies. However, dev-libs/openssl is installed and seems to be in the tree: $ eix -e dev-libs/openssl [I] dev-libs/openssl Available versions: (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1 1.0.0g 1.0.0h **1.0.1 {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2 zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2 zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test) I think you should file a bug against www-client/google-chrome It wants the exact version dev-libs/openssl:0.9.8 but the oldest in portage is dev-libs/openssl:0.9.8r Chances are the dev simply left off the version suffix by accident That can't be it. There's a wildcard at the end: =dev-libs/openssl-0.9.8* which should match 0.9.8u.
[gentoo-user] Re: depclean stopped working
On 17/04/12 18:34, Nikos Chantziaras wrote: On 17/04/12 18:10, Alan McKinnon wrote: On Tue, 17 Apr 2012 18:01:43 +0300 Nikos Chantziarasrea...@gmail.com wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) It also says: * Also, note that it may be necessary to manually uninstall * packages that no longer exist in the portage tree, since it may * not be possible to satisfy their dependencies. However, dev-libs/openssl is installed and seems to be in the tree: $ eix -e dev-libs/openssl [I] dev-libs/openssl Available versions: (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1 1.0.0g 1.0.0h **1.0.1 {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2 zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2 zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test) I think you should file a bug against www-client/google-chrome It wants the exact version dev-libs/openssl:0.9.8 but the oldest in portage is dev-libs/openssl:0.9.8r Chances are the dev simply left off the version suffix by accident That can't be it. There's a wildcard at the end: =dev-libs/openssl-0.9.8* which should match 0.9.8u. No wait, that's vmware. The chrome ebuild pulls a slot: dev-libs/openssl:0.9.8 This also matches correctly. The 0.9.8 slot matches all those versions. So no problem with that either.
Re: [gentoo-user] Re: CORRECTION - Problem with eix-REMOTE update...
On 2012-04-17 1:41 AM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: So if it is the differing versions problem, the solution is to upgrade to the most recent (~x86) version of eix, currently eix-0.25.3: echo app-portage/eix /etc/portage/package.accept_keywords emerge eix Is this safe to do while remaining on the stable version of portage?
Re: [gentoo-user] Re: CORRECTION - Problem with eix-REMOTE update...
On 2012-04-17 1:41 AM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: I haven't searched layman for packages in a long time (actually had to google how to do it), and am getting an error I can't seem to solve... Unfortunately, you have not written the actual error which should appear probably a few (probably one) lines before: Nope... After running eix-remote update, it downloads the file, then the very next lines are: * Unpacking data /tmp/eix-remote.m6Ri2tl1/1/_var_lib_layman_a3li.eix was created with an incompatible eix-update: It uses database format 101 (current is 28). Please run 'eix-update' and try again. Followed by similar lines with different cache file names for however many hundred or so files there are... Then the last error is as I said: Writing database file /var/cache/eix .. Database contains 16219 packages in 155 categories. * could not read all eix cachefiles of /tmp/eix-remote.zv5peao3/eix-caches.tbz2 Probably your eix cachefile was *not* updated successfully. Unless the above messages suggest another cause or you specified a wrong filename, the most likely cause of this is that the server uses another eix version than you or produced broken data. Please inspect /tmp/eix-remote.zv5peao3/eix-caches.tbz2 whether this is a valid *.tar.bz2 archive containing eix cachefiles (if it has already been deleted, download it using fetch). If this is not the case (but was freshly downloaded), please report a bug. Note that the archive is *not* broken if only the cachefile format versions differ: In that case only report a bug if the eix cachefile format versions in the downloaded file are *older* than that of the most current ~x86 eix version in the portage tree (but first retry after several days before reporting such a bug to give the server maintainers a chance to upgrade after a version bump of eix). Conversely, if the downloaded versions are even newer than that supported by your eix, you will have to upgrade to the most current ~x86 version of eix to use eix-remote: This inconvenience cannot be avoided and is not a bug! problems arised with cachefile _var_lib_layman_zugaina.eix * Calling eix-update... * could not read all eix cachefiles of /tmp/eix-remote.dhR5mKNK/eix-caches.tbz2 Maybe this error speaks about differing versions? Apparently it does, but *how* did this happen??
Re: [gentoo-user] Re: depclean stopped working
On Tue, 17 Apr 2012 18:41:55 +0300 Nikos Chantziaras rea...@gmail.com wrote: On 17/04/12 18:34, Nikos Chantziaras wrote: On 17/04/12 18:10, Alan McKinnon wrote: On Tue, 17 Apr 2012 18:01:43 +0300 Nikos Chantziarasrea...@gmail.com wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) It also says: * Also, note that it may be necessary to manually uninstall * packages that no longer exist in the portage tree, since it may * not be possible to satisfy their dependencies. However, dev-libs/openssl is installed and seems to be in the tree: $ eix -e dev-libs/openssl [I] dev-libs/openssl Available versions: (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1 1.0.0g 1.0.0h **1.0.1 {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2 zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2 zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test) I think you should file a bug against www-client/google-chrome It wants the exact version dev-libs/openssl:0.9.8 but the oldest in portage is dev-libs/openssl:0.9.8r Chances are the dev simply left off the version suffix by accident That can't be it. There's a wildcard at the end: =dev-libs/openssl-0.9.8* which should match 0.9.8u. No wait, that's vmware. The chrome ebuild pulls a slot: dev-libs/openssl:0.9.8 This also matches correctly. The 0.9.8 slot matches all those versions. So no problem with that either. I missed that colon for the slot. So this certainly looks buggy on the part of depclean. Now to find out what's going on. One thing that strikes me as a possibility is that the highest numbered version has the lower slot number (0). I know that SLOT names are just names and not supposed to be treated like they form an order, but I've seen odd things like this before. I think KDE did it to me once. What happens if you emerge openssl:0.9.8, let it go into world, then run depclean? The build takes 2 minutes and you can easily remove it from world later. -- Alan McKinnnon alan.mckin...@gmail.com
[gentoo-user] Re: depclean stopped working
On 17/04/12 19:39, Alan McKinnon wrote: On Tue, 17 Apr 2012 18:41:55 +0300 Nikos Chantziarasrea...@gmail.com wrote: On 17/04/12 18:34, Nikos Chantziaras wrote: On 17/04/12 18:10, Alan McKinnon wrote: On Tue, 17 Apr 2012 18:01:43 +0300 Nikos Chantziarasrea...@gmail.com wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) [...] One thing that strikes me as a possibility is that the highest numbered version has the lower slot number (0). I know that SLOT names are just names and not supposed to be treated like they form an order, but I've seen odd things like this before. I think KDE did it to me once. What happens if you emerge openssl:0.9.8, let it go into world, then run depclean? The build takes 2 minutes and you can easily remove it from world later. Nope, nothing changed.
[gentoo-user] Re: depclean stopped working
On 17/04/12 18:01, Nikos Chantziaras wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) I filed a bug about this: https://bugs.gentoo.org/show_bug.cgi?id=412391 If someone wants to try and reproduce this: emerge www-client/google-chrome emerge -a --depclean
Re: [gentoo-user] Building the nvidia and ati proprietary drivers against the latest kernel.git
Am 2012-04-09 02:30, schrieb walt: For many years I've been testing kernels from Linus's git repository and I find that about twice a year the kernel devs do something evil that breaks proprietary video drivers. (I suspect they do it on purpose but I can't prove it ;) I have no idea how many of you like to test bleeding edge kernels but I thought I'd ask. I have some seriously ugly hacks for building the nvidia (and very recently) the ati proprietary drivers against git kernels, but I won't spend time explaining them here if no one is interested. walt, would you mind sharing your nvidia-stuff as well? seems you missed my on-list reply yesterday ;-) thanks in advance, Stefan
Re: [gentoo-user] Re: depclean stopped working
On Tue, Apr 17, 2012 at 1:13 PM, Nikos Chantziaras rea...@gmail.com wrote: On 17/04/12 18:01, Nikos Chantziaras wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) I filed a bug about this: https://bugs.gentoo.org/show_bug.cgi?id=412391 If someone wants to try and reproduce this: emerge www-client/google-chrome emerge -a --depclean FWIW I have google-chrome and vmware-workstation (same versions quoted above) installed and don't see this issue (~amd64 box). My installed openssl are version 0.9.8u and 1.0.0h.
[gentoo-user] gnome 2/3
I am looking at upgrading my mail client from evolution 2 to 3 because of some features I would like. While pondering the whole gnome 2/3 thing, I have noticed the Mate desktop and like what I see - but gentoo seems to be the odd distro out without an official distro install path - is there an overlay or is it roll your own at this stage? BillK
[gentoo-user] cpu sched for bulldozer
Which cpu scheduler would work best for AMD Bulldozer? The two-level (4 macro-cores * 2 semi-cores) system looks like BFS wouldn't work efficiently on it. -- 001100 Andrey m05hbear 010010 00 andrey at moshbear dot net 11 andrey dot vul at gmail 101101 110011
[gentoo-user] kwin opengl compositing w/ nouveau?
Me again ;) I just ran 'startx' on my machine for the first time in a dog's age and had to switch the rendering engine to XRender from OpenGL to get a usable desktop (couldn't see the desktop. was a bunch of black squares). I'm not sure what changed, and the online wiki/forum pages I just spent two hours reading were stale and of little help. Anyone see anything stupid herein: -- make.conf -- VIDEO_CARDS=nouveau -- eselect -- # for i in mesa opengl qtgraphicssystem do eselect $i list done i915 (Intel 915, 945) i965 (Intel 965, G/Q3x, G/Q4x) r300 (Radeon R300-R500) r600 (Radeon R600-R700, Evergreen, Northern Islands) sw (Software renderer) [1] classic [2] gallium * Available OpenGL implementations: [1] xorg-x11 * Available Qt Graphics Systems: [1] native [2] opengl (experimental) [3] raster (default) * -- eix -- kde-meta - 4.8.2(4){tbz2}(02:36:00 PM 04/05/2012)(nls semantic-desktop -accessibility -aqua -sdk) kwin - 4.8.2(4){tbz2}(05:36:26 AM 04/05/2012)(opengl -aqua -debug -gles -xinerama) qt-opengl - 4.8.1(4){tbz2}(04:54:00 AM 03/30/2012)(exceptions qt3support -aqua -c++0x -debug -egl -pch -qpa) qt-gui - 4.8.1-r1(4){tbz2}(03:43:46 AM 04/05/2012)(accessibility dbus exceptions gif glib mng qt3support tiff xv -aqua -c++0x -cups -debug -egl -gtkstyle -nas -nis -pch -qpa -trace -xinerama) mesa - 8.0.2{tbz2}(04:52:19 AM 03/30/2012)(classic egl gallium llvm nptl shared-glapi video_cards_nouveau -bindist -d3d -debug -g3dvl -gbm -gles1 -gles2 -kernel_FreeBSD -openvg -osmesa -pax_kernel -pic -selinux -shared-dricore -vdpau -video_cards_i915 -video_cards_i965 -video_cards_intel -video_cards_r100 -video_cards_r200 -video_cards_r300 -video_cards_r600 -video_cards_radeon -video_cards_vmware -wayland -xa -xvmc) xf86-video-nouveau - 0.0.16_pre20120322{tbz2}(03:30:39 AM 03/23/2012) xorg-server - 1.12.0-r1{tbz2}(03:32:48 AM 03/21/2012)(ipv6 nptl udev xorg -dmx -doc -kdrive -minimal -selinux -static-libs -tslib -xnest -xvfb) ~ # uname -r 3.3.2-gentoo ~ # egrep -i 'nouveau|drm' /boot/config-3.3.2-gentoo CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_TTM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_DRM_VMWGFX is not set # CONFIG_DRM_GMA500 is not set CONFIG_DRM_NOUVEAU=y # CONFIG_DRM_NOUVEAU_BACKLIGHT is not set # CONFIG_DRM_NOUVEAU_DEBUG is not set # CONFIG_DRM_I2C_CH7006 is not set # CONFIG_DRM_I2C_SIL164 is not set ~ # lspci -v|grep -i nvid 01:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT] (rev a2) (prog-if 00 [VGA controller]) At this point, I don't care if it's OpenGL or OpenGL ES (kwin_gles) that we get working.. I just want to use something 'better' than XRender again (it lags badly for me) Thanks! -- Douglas J Hunley (doug.hun...@gmail.com) Twitter: @hunleyd Web: douglasjhunley.com G+: http://goo.gl/sajR3
[gentoo-user] Re: Building the nvidia and ati proprietary drivers against the latest kernel.git
On 04/17/2012 01:05 PM, Stefan G. Weichinger wrote: Am 2012-04-09 02:30, schrieb walt: I have some seriously ugly hacks for building the nvidia (and very recently) the ati proprietary drivers against git kernels, but I won't spend time explaining them here if no one is interested. walt, would you mind sharing your nvidia-stuff as well? Now there are at least three of us who just can't wait to feel the sweet sorrow of booting tomorrow's broken kernel :p If you build kernels frequently you don't need to install the entire nvidia-drivers package each time. You need only recompile the code for the nvidia kernel module, so we extract (and save) just that one part of the code from the source tarball like this: #cd /usr/src #sh /usr/portage/distfiles/NVIDIA-Linux-x86_64-295.40.run -x #mv NVIDIA-Linux-x86_64-295.40/kernel/ .--- notice the dot #rm -rf NVIDIA-Linux-x86_64-295.40/ (the next step is optional, but it will help you next week ;) #mv kernel nvidia A normal person would now do the following: #cd nvidia #make module install //Done! But you are not a normal person, are we? :p *You* will get an error message that your kernel is from another planet and the build will die. No worries. The important thing is that the binary blob (nv-kernel.o) from nvidia.com still works perfectly with today's git kernel. Confession: I know this *only* because I convinced the nvidia installer code that I know more than than the nvidia.com devs know. Obviously a lie most foul, but it worked again! (This time.) [I'm falling asleep at the keyboard now and I don't want to give you bogus information, so I'll be back tomorrow with the rest of it.]
Re: [gentoo-user] Re: Building the nvidia and ati proprietary drivers against the latest kernel.git
On Apr 18, 2012 8:51 AM, walt w41...@gmail.com wrote: On 04/17/2012 01:05 PM, Stefan G. Weichinger wrote: Am 2012-04-09 02:30, schrieb walt: I have some seriously ugly hacks for building the nvidia (and very recently) the ati proprietary drivers against git kernels, but I won't spend time explaining them here if no one is interested. walt, would you mind sharing your nvidia-stuff as well? Now there are at least three of us who just can't wait to feel the sweet sorrow of booting tomorrow's broken kernel :p If you build kernels frequently you don't need to install the entire nvidia-drivers package each time. You need only recompile the code for the nvidia kernel module, so we extract (and save) just that one part of the code from the source tarball like this: #cd /usr/src #sh /usr/portage/distfiles/NVIDIA-Linux-x86_64-295.40.run -x #mv NVIDIA-Linux-x86_64-295.40/kernel/ .--- notice the dot #rm -rf NVIDIA-Linux-x86_64-295.40/ (the next step is optional, but it will help you next week ;) #mv kernel nvidia A normal person would now do the following: #cd nvidia #make module install //Done! But you are not a normal person, are we? :p *You* will get an error message that your kernel is from another planet and the build will die. No worries. The important thing is that the binary blob (nv-kernel.o) from nvidia.com still works perfectly with today's git kernel. Confession: I know this *only* because I convinced the nvidia installer code that I know more than than the nvidia.com devs know. Obviously a lie most foul, but it worked again! (This time.) [I'm falling asleep at the keyboard now and I don't want to give you bogus information, so I'll be back tomorrow with the rest of it.] Bah! A cliffhanger! *twiddles thumb waiting for Walt to wake up* Rgds,
Re: [gentoo-user] kwin opengl compositing w/ nouveau?
On Tue, Apr 17, 2012 at 21:25, Doug Hunley doug.hun...@gmail.com wrote: Me again ;) I just ran 'startx' on my machine for the first time in a dog's age and had to switch the rendering engine to XRender from OpenGL to get a usable desktop (couldn't see the desktop. was a bunch of black squares). I'm not sure what changed, and the online wiki/forum pages I just spent two hours reading were stale and of little help. Anyone see anything stupid herein: -- make.conf -- VIDEO_CARDS=nouveau -- eselect -- # for i in mesa opengl qtgraphicssystem do eselect $i list done i915 (Intel 915, 945) i965 (Intel 965, G/Q3x, G/Q4x) r300 (Radeon R300-R500) r600 (Radeon R600-R700, Evergreen, Northern Islands) sw (Software renderer) [1] classic [2] gallium * Available OpenGL implementations: [1] xorg-x11 * Available Qt Graphics Systems: [1] native [2] opengl (experimental) [3] raster (default) * -- eix -- kde-meta - 4.8.2(4){tbz2}(02:36:00 PM 04/05/2012)(nls semantic-desktop -accessibility -aqua -sdk) kwin - 4.8.2(4){tbz2}(05:36:26 AM 04/05/2012)(opengl -aqua -debug -gles -xinerama) qt-opengl - 4.8.1(4){tbz2}(04:54:00 AM 03/30/2012)(exceptions qt3support -aqua -c++0x -debug -egl -pch -qpa) qt-gui - 4.8.1-r1(4){tbz2}(03:43:46 AM 04/05/2012)(accessibility dbus exceptions gif glib mng qt3support tiff xv -aqua -c++0x -cups -debug -egl -gtkstyle -nas -nis -pch -qpa -trace -xinerama) mesa - 8.0.2{tbz2}(04:52:19 AM 03/30/2012)(classic egl gallium llvm nptl shared-glapi video_cards_nouveau -bindist -d3d -debug -g3dvl -gbm -gles1 -gles2 -kernel_FreeBSD -openvg -osmesa -pax_kernel -pic -selinux -shared-dricore -vdpau -video_cards_i915 -video_cards_i965 -video_cards_intel -video_cards_r100 -video_cards_r200 -video_cards_r300 -video_cards_r600 -video_cards_radeon -video_cards_vmware -wayland -xa -xvmc) xf86-video-nouveau - 0.0.16_pre20120322{tbz2}(03:30:39 AM 03/23/2012) xorg-server - 1.12.0-r1{tbz2}(03:32:48 AM 03/21/2012)(ipv6 nptl udev xorg -dmx -doc -kdrive -minimal -selinux -static-libs -tslib -xnest -xvfb) ~ # uname -r 3.3.2-gentoo ~ # egrep -i 'nouveau|drm' /boot/config-3.3.2-gentoo CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_TTM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_DRM_VMWGFX is not set # CONFIG_DRM_GMA500 is not set CONFIG_DRM_NOUVEAU=y # CONFIG_DRM_NOUVEAU_BACKLIGHT is not set # CONFIG_DRM_NOUVEAU_DEBUG is not set # CONFIG_DRM_I2C_CH7006 is not set # CONFIG_DRM_I2C_SIL164 is not set ~ # lspci -v|grep -i nvid 01:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT] (rev a2) (prog-if 00 [VGA controller]) At this point, I don't care if it's OpenGL or OpenGL ES (kwin_gles) that we get working.. I just want to use something 'better' than XRender again (it lags badly for me) Thanks! -- Douglas J Hunley (doug.hun...@gmail.com) Twitter: @hunleyd Web: douglasjhunley.com G+: http://goo.gl/sajR3 Two things come to mind, given some recent trouble I've had on the radeon side of the coin here, and with an intel system or two in the past. The DRM related drivers seem to be prone to misbehaving when they're not configured as modules. I haven't managed to sort out why, so you may see if a change there helps, though it'll likely cause mode changes throughout the booting process. The second thing that comes to mind is that you don't include any relevant entries from glxinfo (glxinfo | grep ender) or Xorg.?.log (notably anything flagged as an error, 'grep EE /var/log/Xorg.0.log' grabs that, plus a bit of cruft), notably from a session where things aren't working properly, as the majority of issues trace back to direct rendering being disabled due to some incompatibility that gets noted in the log (often in delightfully cryptic prose). -- Poison [BLX] Joshua M. Murphy