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
