new NVIDIA drivers

Cardoe wrote this late at night:

NVIDIA has released a new set of drivers in the latest series for Linux x86, Linux amd64, and Solaris. Curiously missing from this release is FreeBSD. The version is dubbed 100.14.19 and you can read the shortlog of it here. The biggest thing to note is that X.org 7.3 is supported. The drivers are already committed to the tree and Donnie has already removed the nvidia-drivers blocker in the xorg-server 1.4 ebuild, so everyone should be set. If you’re stuck on the 96xx series or the 71xx series, you’re out of luck for official X.org 7.3 support as NVIDIA has not updated those drivers for the new ABI. However, official word by NVIDIA employees is that if you disable the Composite extension and pass -ignoreABI to the X server, you should be fine.

Basically the new driver adds support for a few new Quadros and improves support for the GeForce 8 GPUs. But the item everyone might notice is actually buried deep in Appendix B on the README. It’s  OnDemandVBlankInterrupts, you put that in your driver section and set it to true and you should see some power savings from your laptops. On my machine with sys-power/powertop, it showed an immediate reduction of 60 interrupts per second.

Overall OpenGL seems to be a bit smoother with compiz and such and general graphics performance seems to be improved, however it must be noted that I am a GeForce 8600 user so people with other cards may not have the same experience I’ve had.

Xgl

Cardoe wrote this around lunchtime:

So just before yesterday’s GatorLUG meeting I installed Hanno’s Xgl overlay and got Xgl up and running on my ATI Radeon Mobility 9000. It’s a r200 based card, specifically a R250Lf chip. Hanno’s instructions are for a windowed X server on top of your current X session, this didn’t work for me. So I followed Sebastian’s instructions but those weren’t without their oddities. Basically I messed up at first and didn’t realize that I had to restart my X session… I know… duh! But I wasn’t thinking, just rushing. The other HUGELY important issue is to make sure you run glxinfo first, which is provided by x11-apps/mesa-progs and make sure you have “direct rendering: yes” in the output, otherwise X will just crash on you. Well, here’s the steps to make it happen.

  1. cd /usr/local
  2. svn co http://svn.hboeck.de/xgl-overlay
  3. add “/usr/local/xgl-overlay” to PORTDIR_OVERLAY
  4. emerge -auDv world

    # This will update mesa, cairo, and glitz.

  5. emerge xgl compiz

    # This will install the OpenGL X server and the composition manager as well as Gnome Decorator

  6. cd /usr/bin && rm X && ln -s Xgl X

    # This changes the X symlink to point to Xgl rather then Xorg. To switch back point it back to Xorg

  7. Log Out
  8. Log In
  9. If you’re using binary drivers (nvidia and fglrx) prepend the following command with LD_LIBRARY_PATH=/usr/lib/opengl/xorg-x11/lib/
  10. compiz --replace gconf decoration wobbly fade minimize cube rotate zoom scale move resize place switcher &
  11. gnome-window-decorator &
  12. And you’re all set. You should see some pretty neat effects.

Some things to keep in mind.

  • This won’t work on KDE just yet because of the lack of kde-window-decorator. It’s being worked on but it’s not ready yet.
  • It’s highly experimental code, it probably won’t work.
  • In fact, binary ATI drivers are known not to work and open source nvidia drivers are known not to work. Only ones that do work are binary Nvidia and open source ATI and only with certain cards.
  • Performance is pretty poor right now
  • Anti-Aliased console fonts are busted (aka gnome-terminal)

Reason I provided instructions is that Sebastian’s instructions didn’t work for me too well. You’ll notice my compiz call is slightly different then his. With his when I clicked on the title bars I’d get compiz crashing and it’s say WNCK_IS_DESKTOP or something like that failed. I didn’t pay enough attention to it at the time.

oh and just so everyone knows THIS IS NOT SUPPORTED BY ANYONE!!! IF IT BREAKS YOUR SYSTEM!! IT’S YOUR OWN FAULT!! Do not rant in #gentoo or on bugzilla about this not working!!

ATI Radeon cards in Laptops

Cardoe wrote this terribly early in the morning:

Anyone have an ATI Radeon card in your laptop? Notice how when you shut the screen it really doesn’t turn off the screen. I never noticed this until just recently and after being an Nvidia card user for so long I find this kind of annoying. So here’s a quick fix for everyone.

Make sure your kernel has ACPI support and ACPI button support.

cat /proc/acpi/button/lid/LID/state

It should report as being opened. (duh!)

If you don’t have this then check your kernel config

grep 'CONFIG_ACPI_BUTTON' /usr/src/linux/.config

If this says it’s not enabled, then hop back into your kernel and find ACPI and turn it on.

Next make sure you have acpid turned on.

/etc/init.d/acpid status

If it doesn’t report as being on then flick it on.

rc-update add acpid default
/etc/init.d/acpid start

If you don’t have it then just emerge it. Also you will need the laptop-mode-tools ACPI events script.

emerge acpid laptop-mode-tools

And turn it on.

Now we’re going to need the tool to do the heavy lifting for us.

emerge radeontool

And finally edit the following file /etc/acpi/actions/lm_lid.sh and add

[[ $(</proc/acpi/button/lid/LID/state) == *open ]] && \
/usr/bin/radeontool light on || \
/usr/bin/radeontool light off

And you should be set. Try closing your screen, you should notice the backlight go out.

For those of you that don’t use the external video output, it’s rumored that the following saves a little battery life.

radeontool dac off

MythTV & IVTV

Cardoe wrote this mid-afternoon:

Well Gentoo officially has a version of IVTV from the 0.3.x branch. We’ve released the 0.3.8 driver to ~x86 and hopefully ~amd64 will follow shortly. Soon as we can get the necessary patches for PPC, we’ll have it marked ~ppc.

My previous post details the issues I’ve having with my PPC machine and why I can’t work on IVTV on it along with MythTV. Which is what’s going to be the primary purpose of that box.

I’ve been working on some MythTV snapshots that include dependency updates so that they work with Modular X. Also, this includes some of the changes for the upcoming 0.19 series.

If anyone’s interested in any of these snapshots, which I can’t promise won’t toast your database, let me know and I’ll post them here.

GTK+ USE flag hell Part 2

Cardoe wrote this around lunchtime:

So yesterday I posted about how I felt about the GTK+ USE flag situation. Today I’m going to revisit the issue a little bit. Here’s a link if you didn’t read the previous rant, GTK+ USE flag hell part 1.

Basically, Gentopia is going to take care of the USE flag changes. We’ll host all the ebuilds with the changed USE flags and then we’ll work on bringing the change to Portage. It makes sense because it allows us to develop outside of the Portage tree and to test software to make sure it’s solid. (You know… that whole Gentopia ideal.)

Just as a note for the KDE & QT people. Hopefully you’ll take note of this GTK+ USE flag situation because I think it’ll affect you guys as well when QT4 hits the streets and some packages upgrade and some don’t.

GTK+ USE flag hell

Cardoe wrote this terribly early in the morning:

Here’s the solution to the GTK+ USE flag issue. The final solution because I’m tired of all the debate and in-action on the mailing lists I am posting this here. I hope we can quickly discuss it and dismiss all issues with it and I can implement it this weekend while I am being mauled by the hurricane.

Remove entirely the “gtk” USE flag. It’s ambiguous and pointless. The proper USE flags should be gtk1 and gtk2. Turn off gtk1 for the desktop profile and leave gtk2 on in the desktop profile by default. As far as I’m concerned, GTK+ 1.x is depreciated and does not need to be pulled in needlessly.

What’s that mean? If you want any GTK+ support, you turn on gtk1 and gtk2 in your USE flags. If you only want GTK+ 2.x support, you turn on gtk2 in your USE flags and leave off gtk1. If you want only GTK+ 1.x support, you turn on the gtk1 and leave off gtk2. If you don’t want GTK+ on your system you leave both USE flags off. Simple. Easy to understand. No ambiguity.

Oh no what about GTK+ 3.x people say. Well first off, that’s a long way off. Do they even have a roadmap that shows breaking ABI & API compatibility? Not as far as I know. But plain and simple, you add a gtk3 USE flag and it’s pretty obvious.

What about when a package supports both? Well the USE flags sort it out pretty easy.

What about when a package supports both and both are turned on? Let’s take easytag for an example. Well guess what, the maintainer knows the package well. So he/she makes an educated judgment. For example, when easytag GTK+ 2.x support first hit the streets, it was pretty experimental so it would have been wise that the ebuild maintainer make GTK+ 1.x the default if both USE flags were on. However now that the GTK+ 2.x support is pretty solid, it would be wise for the maintainer to switch to GTK+ 2.x to be the default? Why because it looks better and presents Gentoo as a desktop and a functional userbase better. Because most users are going to have a GTK+ 2.x based desktop (i.e. Gnome 2.x) if they use GTK+ and as such will have configured it to their liking and suddenly easytag will conform to their visual layout that they are comfortable with. It won’t stick out like a sore thumb like GTK+ 1.x does.

I hope this covers all scenarios and we can start making this change ASAP because it needs to happen 2 years ago.

Any questions? Feel free to post a comment here and I’ll answer it.

Modular X

Cardoe wrote this in the early evening:

As some people might have heard, there is a new series of X coming out, the 6.9/7.0 version. Why dual version numbers? Simple. The 6.9 version will provide the same old xorg-x11 package that we’re used to today. The package that includes everything in one. However 7.0 will contain the same code but it will provide a new twist. 7.0 has been broken up into over 300 separate packages, each which is autotooled and provides only the small necessary part of X. Libraries have been separated from headers, which are now refereed to as protocols. Apps have been split out as well.

Why you ask? Because it’s much easier for developers to break into a small package then into a HUGE package like X. That has been a barrier for a lot of developers that would do work on X. Another reason, which is a very big one in my book, if there’s a bug found in the ATI driver that’s significant for example, they can just release a new version of the driver and all distros can upgrade an all is well. Previously, you would have to wait for a new version of X to be released or grab the fix from CVS and apply it and make a new X package with the fix. Which was often a HUGE process and a lot of times didn’t happen for several months.

This also eliminates the long compiles for many people. If fonts don’t change, no need to rebuild them all.

Where is Gentoo with this process? Donnie Berkholz or spyderous as most of us know him, has been busting his ass working on this for a while. He has brought all these packages to the Portage tree. However they are package.masked while they are being further developed. For the time being he has created two guides as well as two scripts for testers, and primarily Gentoo developers to update their package’s depends to the new modular requirements.

Migrating to Modular X Howto - I recommend reading this all the way down first to see if Modular X is right for you right now.
Porting your depends to Modular X - Remember this requires having set a PORT_LOGDIR in /etc/make.conf for linking_libs.sh and not removing ${WORKDIR} for included_headers.sh

Don’t be surprised if you receive pings from me on IRC or bug reports providing you with the depends I’ve run across. Don’t however, take this as the final solution to the depends. I’m not scouring everyone’s applications in depth, just using spyderous’ scripts (which are known to miss some stuff) and the results of what was necessary on my system to build. I encourage each developer to test for themselves.