[09:51] <ara> tseliot, hi!
[09:52] <tseliot> ara: hi
[09:52] <ara> tseliot, are the nvidia drivers now available?
[09:52] <tseliot> ara: I'm still working on it. As you can see, the blueprint involves some work: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers
[09:53] <tseliot> mainly https://wiki.ubuntu.com/X/ProprietaryDrivers/IntegrationImprovements
[09:53] <ara> tseliot, thanks! I'll subscribe to the blueprint :)
[09:53] <tseliot> ara: good idea. I'll do my best to complete it ASAP
[09:53] <tjaalton> tseliot: err, are you going to use alternatives instead of diversions?
[09:54] <tseliot> tjaalton: yep
[09:54] <tjaalton> ugh
[09:54] <tjaalton> I thought pitti said it's even more fragile than using diversions
[09:54] <tseliot> installing fglrx, nvidia (all versions) won't cause a mess
[09:54] <tjaalton> yes it will
[09:54] <tjaalton> which one gets the top priority?
[09:55] <tseliot> I thought that he was against this change but then he told me that he agreed
[09:55] <tseliot> define a use-case and I'll answer to your priority question
[09:56] <tjaalton> installing both fglrx and nvidia, I thought that was the driving factor to get this done?
[09:56] <tseliot> yes, that too
[09:56] <tjaalton> and what if you have legacy nvidia drivers
[09:56] <tseliot> same thing
[09:57] <tseliot> all libraries live in the directory of the driver they belong to
[09:57] <tjaalton> but which one is used?
[09:57] <tjaalton> the driver doesn't know
[09:57] <tseliot> whatever you choose
[09:57] <tjaalton> so the user needs to choose.. that will end in tears :)
[09:57] <tseliot> with update-alternatives --set
[09:58] <tseliot> you = Jockey
[09:58] <tseliot> it works great in Mandriva
[09:59] <tjaalton> so how does jockey choose which one to use?
[09:59] <tseliot> you can activate a driver in Jockey, right?
[09:59] <tjaalton> yes?
[10:00] <tseliot> one click on the driver that you want to use, reboot and it will work
[10:00] <tseliot> maybe I'm missing the point of your question
[10:00] <tjaalton> well, as long as fglrx doesn't support 1.7 this is pretty academic
[10:01] <tseliot> you can have mesa, nvidia current, nvidia 173, nvidia 96 and fglrx installed at the same time
[10:01] <tjaalton> so the use case where you have to choose between fglrx and nvidia will diminish
[10:01] <tseliot> and you can select what you want to use with Jockey
[10:01] <tseliot> fglrx will arrive in time
[10:01] <tseliot> for Lucid
[10:01] <tjaalton> I hope not :)
[10:01] <tjaalton> so we can get rid of it :)
[10:02] <Ng> we're getting rid of all our ati users? ;)
[10:02] <tjaalton> (fat chance)
[10:02] <tseliot> in the future it should become a fall back as we will prefer -ati
[10:02] <tjaalton> Ng: check the phoronix survey results, most of the ati users use free drivers
[10:02] <tjaalton> and now we have r600_dri
[10:02] <Ng> tjaalton: most phoronix survey takers with ati hardware? ;)
[10:02] <tjaalton> not perfect, but good enough for most
[10:03] <tjaalton> Ng: exactly :)
[10:03] <tseliot> but if you need a specific feature which only the proprietary driver supports (don't ask me what) you should still be able to switch to it
[10:03] <Ng> (I honestly have no familiarity with what ati fail is supported by which drivers, I'm just being facetious)
[10:03] <tjaalton> tseliot: ok. maybe the plan has been reworked further, so my concerns are obsolete.. hope so
[10:04] <tjaalton> at least this will get rid of all the upgrade bug
[10:04] <tjaalton> +s
[10:05] <tseliot> tjaalton: yes, don't worry, I would never put in an Ubuntu release something that doesn't convince me
[10:05] <tjaalton> tseliot: also, we are getting close to the point where it doesn't make sense for jockey to push users to use fglrx
[10:06] <tjaalton> I've no first hand experience how well fglrx works nowadays, but a friend of mine seems to have issues and is waiting for lucid..
[10:07] <tjaalton> and the new free stack
[10:07] <tseliot> tjaalton: yes, maybe we can make Jockey mark the open driver as recommended
[10:07] <tseliot> so that users will know that they can keep the open driver
[10:08] <tseliot> especially users coming from Windows
[10:15] <tjaalton> I guess we can drop the (unused) nvidia/fglrx patches from the server, since they could only break things
[10:15] <tjaalton> and since the driver will be hardcoded to xorg.conf like before
[10:17] <tseliot> tjaalton: what was the problem with those patches again?
[10:18]  * tseliot doesn't remember
[10:18] <tjaalton> tseliot: the autoconfig only works if there is no xorg.conf
[10:18] <tseliot> aah, right
[10:18] <tjaalton> othewise there's no fallback
[10:18] <tjaalton> it would just check the top driver
[10:19] <tjaalton> and since I'm proposing to pull the xorg.conf.d patches from upstream, there would practically always be an xorg.conf
[10:19] <tseliot> I haven't looked at those patches but if you can keep them there for a while I will see if I can fix that
[10:19] <tjaalton> shipped by some driver, for instance
[10:19] <tseliot> aah
[10:20] <tjaalton> it's not the patches, you'd need to rework the whole logic
[10:20] <tseliot> yes, of course
[10:20] <tjaalton> but yes, that would be cool
[10:20] <tseliot> I haven't had the time to see how the xorg.conf.d stuff works
[10:20] <tjaalton> mentioned to bryce too
[10:21] <tjaalton> then it would be possible to have for instance the synaptics quirks in a synaptics.conf
[10:21] <tjaalton> and not mess with udev rules
[10:21] <tseliot> that would be great
[10:22] <tjaalton> the backend probably will drop support for that anyway
[10:22] <tjaalton> no need to relive the fdi hell
[10:22] <tjaalton> dan sent the latest versions to the list this week
[10:23] <tjaalton> xorg-devel@, when you have time :)
[10:23] <tjaalton> I'll probably test them during the holidays
[10:23] <tjaalton> and xf86-input-wacom too, should first buy an intuos4 though
[16:40] <sconklin> bryce, tseliot: did you do any testing of kernel performance differences with the moblin patches I put in the test kernel (a couple of weeks ago now)
[16:41] <tseliot> sconklin: I didn't but Keybuk did
[16:42] <sconklin> tseliot: thanks, I'll bug him over in #kernel
[16:42] <tseliot> np
[18:04] <Duke`> omg two freezes in 5 minutes (i945, GEM, KMS, kernel 2.6.32)
[18:07] <Duke`> Sarvatt, I still got those freezes with i945 :(
[18:07] <Sarvatt> ya mean with updated libdrm? there hasnt been any changes that'd fix it if so
[18:08] <Duke`> yes
[18:08] <Sarvatt> i'm using stock lucid for now, that'll work at least until 2.4.16 gets uploaded to lucid then we're gonna have to figure out something else to get around it :D
[18:09] <Duke`> I note that it often happens when quickly scrolling up and down on a particular website
[18:09] <Sarvatt> maybe make another PPA with an 11-25 libdrm versioned higher
[18:09] <Duke`> for example: http://www.pcinpact.com/actu/news/54628-jacques-myard-nationalisation-loi-internet.htm?vc=1&p=3#vc
[18:09] <Sarvatt> yeah
[18:09] <Sarvatt> same deal here, that or scrolling in a folder with hundreds of video thumbnails
[18:09] <Duke`> it froze two times in 5 mins just 10 mins ago
[18:10] <Sarvatt> wont be able to build ati or intel against the 11-25 libdrm even though it has the features it needs from 2.4.16 :(
[18:11] <Sarvatt> the Add drmGetDeviceNameFromFd function commit
[18:14] <Sarvatt> i'm hoping http://lists.freedesktop.org/archives/intel-gfx/2009-December/005221.html makes it into stable too, that seems to fix my flashing and hanging after suspend/resume too
[18:19] <Sarvatt> with 2.6.33-rc1 i still get the freezing on a solid color after resume most of the time but the blinking is gone, and havent frozen with that patch applied yet. on 2.6.32 I get flashing every 90 seconds or so after resume. some people like jcristau are getting the post resume problem I get on first boot, that would be nasty
[18:21] <Sarvatt> http://bugzilla.kernel.org/show_bug.cgi?id=14781 https://bugs.freedesktop.org/show_bug.cgi?id=25371
[18:33] <Duke`> I haven't experienced those, but I never use suspend to ram (my hardware is broken)
[19:01] <Sarvatt> really tempted to buy an ssd for this netbook to not have to use suspend because its so often broken :) just looking at the bootchart of the nc10 on phoronix and it looks like the desktop is up and ready to use in 23 seconds
[19:02] <Sarvatt> its a little over a minute here on this acer aspire one
[19:06] <Sarvatt> i usually use this thing as an ebook/manga reader when i'm out all day, got lots of 10-15 minute gaps of time to turn it on and off
[19:14] <Sarvatt> oh boy, abi break in xserver master about to hit that'll break the nvidia blob i think
[19:21] <tjaalton> Sarvatt: the config change?
[19:21] <Sarvatt> nah [PATCH 3/3] Add type name argument to CreateNewResourceType
[19:23] <tjaalton> oh that
[19:23] <Sarvatt> in the [PATCH 0/2] Patches to ensure all ResourceTypes are named thread the nvidia guy said the blob uses it still when they were talking about how no drivers would be affected by the abi change
[19:26] <tjaalton> the reply was rather terse
[19:41] <tjaalton> ..meaning that he probably wasn't happy with it :)
[22:35] <bryce_> configure.ac:33: error: must install xorg-macros 1.3 or later before running autoconf/autogen
[22:38] <Sarvatt> everything needs xorg-macros xutils-dev 7.5 now upstream
[22:38] <Sarvatt> err xutils-dev I meant, xorg-macros being a part of that :D
[22:39] <Sarvatt> they went through and made all x components need it last month though, guessing yer trying to build a newer ddx on karmic?
[22:41] <Sarvatt> r600 : enable gl2, set R600_ENABLE_GLSL_TEST by default.
[22:41] <Sarvatt> woohoo dont need to manually change the define for r600 people anymore
[22:42] <bryce_> ah right, thanks Sarvatt
[22:42] <bryce_> yep, working on a new -ati snapshot
[22:43] <bryce_> guess needs done in a chroot
[22:44] <ripps> Is it going to be possible to port my custom_wacom.fdi to the new xorg.conf.d configs?
[22:44] <Sarvatt> is lucid shooting for mesa 7.7 or 7.8? wondering for r600/nouveau users, probably not much point trying to do nouveau gallium on 7.7
[22:50] <Sarvatt> i'll try that later tonight and see how it goes, i get over 100 fps at 1280x800 on my 8400M GS laptop with 7.8 gallium
[22:50] <Sarvatt> plenty usable
[22:53] <RAOF> 100fps at what?
[22:53] <Sarvatt> openarena
[22:54] <Sarvatt> oops thought i said that
[22:58] <RAOF> Yeah.  I think nouveau might be losing the "please don't ship 3D, it doesn't work" argument.
[22:59] <RAOF> It made more sense when it didn't drive compiz on nv40+
[23:03] <Sarvatt> compiz does freeze on my 8400 though when i start it :(
[23:03] <Sarvatt> looks like a gpu hang
[23:03] <RAOF> Heh.
[23:04] <Sarvatt> you start it any special way? any environment variables or anything?
[23:05] <RAOF> export LD_LIBRARY_PATH; export LIBGL_DRIVERS_PATH; compiz --replace
[23:06] <RAOF> Apparently you _don't_ want to install it where X can find it; AIGLX apparently doesn't work as well.
[23:06] <Sarvatt> same as me
[23:06] <Sarvatt> didnt know if you used like LIBGL_ALWAYS_INDIRECT or anything
[23:06] <RAOF> No, nothing fancy.
[23:07] <Sarvatt> i'm still using a build from 11-30, maybe it got fixed after
[23:08] <RAOF> mesa, X, drm or DDX? :)
[23:20] <Sarvatt> mesa, rest is fresh from git
[23:21] <Sarvatt> i haven't tried since updating nouveau though, had any luck with the firmware thing?
[23:21] <Sarvatt> i dont think its likely to change, could just grab the binaries out of git from before they changed them to ihexed ones and ship those seperate maybe?
[23:24] <Sarvatt> i saw some other dkms packages doing a make firmware and make firmware_install to ship the firmware, a v4l2 package on mandriva i think it was
[23:31] <RAOF> Actually, I think what I'll end up doing is uploading a nouveau-firmware package from their firmware tarball.
[23:33] <RAOF> Sarvatt: Want to give unpacking http://people.freedesktop.org/~pq/nouveau-drm/nouveau-firmware-20091212.tar.gz in /lib/firmware a try?
[23:36] <Sarvatt> doing it now
[23:36] <Sarvatt> i'm not at home with the machine so i'll only have logs to go by :D
[23:37] <Sarvatt> oh i already used ihex2fw on those ihex-ed ones
[23:37] <Sarvatt> i'll try that tar though just incase
[23:39] <Sarvatt> rebooting now
[23:42] <Sarvatt> loaded the firmware fine in dmesg but no accel in xorg.0.log
[23:42] <Sarvatt> [    2.068644] nouveau 0000:05:00.0: firmware: requesting nouveau/nv86.ctxprog
[23:43] <Sarvatt> oops think i have to update-initramfs
[23:43] <Sarvatt> [    0.595218] (EE) NOUVEAU(0): Error creating GPU channel: -19
[23:43] <Sarvatt> [    0.595232] (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
[23:45] <Sarvatt> 200mb of updates to grab again then i'll reboot again
[23:54] <Sarvatt> same deal, NoAccel
[23:56] <Sarvatt> DISPLAY=:0 LD_LIBRARY_PATH="/home/sarvatt/source/mesa/lib/" LIBGL_DRIVERS_PATH="/home/sarvatt/source/mesa/lib/gallium/" glxinfo is giving me swrast