[00:15] <bryce> RAOF, yep
[00:15] <bryce> RAOF, in fact we could probably use your advice as to exactly what all to pull in
[00:16] <bryce> but yeah, shuttleworth's 100% favorable to getting nouveau into lucid as the default foss driver
[00:17] <RAOF> Great!
[00:18] <RAOF> I wonder if it might be a better plan to keep the nouveau drm in a separate dkms-ified source package, though.  It's much, much easier to update that than the full kernel package.
[00:18] <bryce> would that work for booting off a livecd though?
[00:19] <RAOF> Aha!  Good point.  Yes - probably! - it'd just build the module on boot, but you wouldn't get as nice a modesetting experience.
[00:20] <RAOF> That said, I'm not particularly familiar with the livecd experience.  The packages are all unpacked & installed before being bundled into the livecd rootfs, aren't they?
[00:20] <bryce> doing it with dkms is a really good idea, although we're going to have full support from the kernel team, so perhaps it is less necessary than it would be usually
[00:21] <RAOF> In that case, the module would be built during the install process, and the pre-built module would end up on the livecd (and in the initramfs, if we wanted to).
[00:21] <bryce> yeah, I'm just not sure whether dkms modules are built before things boot up or not
[00:21] <bryce> I suppose it must in order to get wireless drivers and such, but I don't really know
[00:21] <bryce> yeah
[00:21] <RAOF> It's up to the postinst script; nouveau-kernel-source builds the module against the current kernel in the postinst, so that'd be OK.
[00:23] <RAOF> The package in xorg-edgers also switches on kms by default, and includes an initramfs-tools hook to shovel it into the initramfs.
[00:24] <jcristau> the livecd doesn't have kernel headers tho
[00:24] <jcristau> afaik anyway
[00:24] <RAOF> Also, I found the dkms options to prevent it trying & failing to build against kernels that the module won't build against.  That was a nice discovery.
[00:25] <RAOF> Oh.  Right.  That would be a problem, then.
[00:26] <RAOF> As I've said, I'm not very familiar with the way the livecd is constructed.
[01:02] <bryce> RAOF, btw does the -nouveau in xorg-edgers have 3D or is it 2D only?
[01:05] <RAOF> bryce: It'd work with 3D if someone turned on the --enable-nouveau-gallium switch in the mesa builds.
[01:05] <RAOF> I don't think that's a good idea, though; upstream still doesn't want bug reports for 3D that don't have patches attached, and there's plenty of bugs to hit.
[01:12] <RAOF> (Such as trying 3D on anything < nv4x)
[02:21] <bryce_> yeah
[06:35] <tjaalton> nouveau replacing nv? that's great news
[06:36] <RAOF> Yeah.
[06:37] <pwnguin> so what happens if you do 3d on an unsupported chipset? catastrophic failure or just a lack of 3d?
[06:40] <tjaalton> probably the former
[06:42] <RAOF> Almost certainly the former.
[06:43] <RAOF> Because there's some 3d code for those chipsets; it's just broken :)
[06:47] <tjaalton> yeah, maybe those could be disabled for known-to-be-broken hardware, but it's still not what upstream likes to see (at least in the main archive, ppa would be ok)
[06:49] <RAOF> I was thinking of asking upstream what they thought about enabling 3D in xorg-edgers.
[06:51] <tjaalton> sure
[06:52] <tjaalton> can't hurt
[06:55] <bryce> I already asked
[06:55] <bryce> they said "don't"
[06:55] <tjaalton> oh :)
[06:57] <tjaalton> did the kernel team decide which version lucid will get? can't find a document on gobby
[06:58] <RAOF> Does that question even make sense?  In what way does nouveau have versions?
[06:58] <RAOF> Although I'd also be interested in any documentation about this that's lying around :)
[06:58] <bryce> tjaalton, 2.6.32
[06:58] <bryce> tjaalton, I missed the official session but all the kernel engineers I talked to said that it was pretty certain
[07:00] <bryce> RAOF, I'll forward to ubuntu-x@
[07:12] <tjaalton> RAOF: yeah, I meant the kernel version
[07:13] <tjaalton> bryce: thanks
[07:14] <RAOF> tjaalton: It becomes obvious with context! :)
[07:14] <tjaalton> hehe
[07:49] <tjaalton> bryce: well, pq said that shipping 3D with the distribution is a no-no, but a PPA with a loud warning should be ok
[07:49] <bryce> yeah
[07:51] <bryce> tjaalton, however, in my reply I addressed his concern about upstream wanting users to verify against git versions by suggesting it would be a good purpose for xorg-edgers
[07:51] <bryce> tjaalton, so from that standpoint we may want to leave 3D off in xorg-edgers as well
[07:52] <bryce> but no reason we couldn't put a 3D enabled nouveau in one of our other many ppas
[07:52] <tjaalton> yeah, and maybe have a special ppa for that if wanted
[07:52] <pwnguin> hmm
[07:52] <pwnguin> as the owner of a 6600gt, this intrigues me
[07:52] <tjaalton> we still need to figure out what to do with gallium, packaging wise
[07:52] <tjaalton> together with XSF
[07:53] <bryce> yep
[07:53] <RAOF> You mean, whether or not to split up the various winsys, trackers, etc?
[07:53] <tjaalton> right
[07:54] <tjaalton> and do they conflict with the dri drivers
[07:54] <tjaalton> I've never tried it out, so I'm not sure what gets used
[07:54] <RAOF> They end up all linked into a single dri driver, don't they?
[07:54] <tjaalton> no idea :)
[07:54] <RAOF> I'm just trying to remember how nouveau's gallium goes.  I'm pretty sure you just end up with a nouveau_dri.so
[07:55] <RAOF> However, I'm less certain how mesa itself changes; it's possible that it conflicts there.
[07:57] <RAOF> Mayhap I'll play with mesa from xorg-edgers.
[16:50] <apw> tseliot, about?
[16:50] <tseliot> apw: yep
[16:50] <apw> tseliot, wanted to talk to you about bcmwl ...
[16:51] <tseliot> apw: sure
[16:51] <apw> suspect #u-x isn't the right place :)  want to come to #u-kernel ?
[16:51] <tseliot> ok
[17:36] <WeatherGod> greetings from the bug squad...
[17:36] <WeatherGod> I have a quick question I was hoping someone here can help me with
[17:37] <WeatherGod> I have a bug report from someone using the NVidia graphics drivers who is reporting the the GPU fan isn't turning on
[17:37] <WeatherGod> any idea where this bug report should be filed against?
[17:37] <tjaalton> nvidia-graphics-drivers-180
[17:38] <WeatherGod> note that he also tried the just released 190 drivers
[17:39] <WeatherGod> ok, I have moved the bug to the drivers-180 package
[17:40] <WeatherGod> for your reference, it is bug 484875
[17:42] <bryce> WeatherGod, could be a hardware issue
[17:43] <WeatherGod> he reports that the fan works when in Windows
[17:44] <WeatherGod> also, in Jaunty, he was able to load a custom DSDT which allowed the fan to work
[17:45] <bryce> yeah sounding like a hardware issue
[17:46] <WeatherGod> ?
[17:47] <WeatherGod> don't get confused by the first reply in the report, it isn't the OR, and he was asked to file a separate bug
[17:51] <bryce> WeatherGod, heh I don't think you're hearing me
[17:51] <bryce> WeatherGod, gpu fans are not generally controlled by the video driver.  And in this case, even if it was controlled by the video driver, it is closed source so we could not change it.
[17:52] <WeatherGod> ok, then where should I file this bug
[17:52] <WeatherGod> tjaalton said to file it against the nvidia driver
[17:52] <WeatherGod> so I did
[17:52] <bryce> if the issue is "gpu fan doesn't work" - that is a hardware issue
[17:53] <WeatherGod> if that is the wrong spot, tell me where to move it
[17:53] <bryce> if the issue is "can't load custom DSDT" - hmm, kernel maybe?  not sure what should permit DSDT customization
[17:53] <WeatherGod> the issue is the fan doesn't work while using Karmic
[17:53] <Ng> fwiw, laptop fans are often pulling air across the CPU and GPU/Northbridge
[17:54] <WeatherGod> so, I should ask the people in #ubuntu-kernel?
[17:55] <bryce> sure
[17:56] <WeatherGod> ok
[17:56] <WeatherGod> will do
[18:33] <tjaalton> I've understood that the driver takes care of power management
[18:35] <bryce> tjaalton, including the gpu fans?
[18:40] <tjaalton> yes, turning them off when underclocking the gpu
[18:41] <tjaalton> I've never had such hw myself though,passive cooling ftw :)
[18:41] <bryce> heh true
[18:48] <bryce> tjaalton, I'd noticed a slew of "doesn't get resolution right" bugs right around karmic release
[18:49] <bryce> tjaalton, have you noticed/heard anything similar there?
[18:49] <bryce> tjaalton, in talking with the kernel guys at UDS, it sounds like a kernel patch went in a couple weeks before release that changed how timings were done with gfx
[18:50] <bryce> tjaalton, steve conklin felt a little uneasy about that patch, and indicated he saw another patch upstream which purported to fix a timing issue.
[18:50] <bryce> I'm going to follow up with him about that patch, as it sounds like the likely culprit
[18:50] <bryce> tjaalton, but if you have better clues let me know
[19:06] <tjaalton> bryce: my hw has worked fine, and haven't been following the bugmail that closely to say if something went bad
[21:33] <Riotta> hello
[21:35] <Riotta> I'm wondering if anybody can do something with bug 441408 which is linked with upstream bug and there is upstream bug fix present, maybe somebody could look into it?
[21:35] <Riotta> thanks in advance
[22:00] <tormod> Riotta, I can make a test package with that upstream fix for you to test
[22:00] <Riotta> tormod: I will be pleased
[22:01] <bryce> if you attach the patch to the bug report (so it shows up on http://www2.bryceharrington.org:8080/X/Reports/patches.html) it will be on my radar to integrate
[22:07] <Riotta> thanks for the hint
[22:19] <Riotta> done
[22:19] <tormod> Riotta and Bryce, the patch did not apply directly to the Karmic package, but I modified it. you can download and test from my PPA
[22:20] <Riotta> cool
[22:37] <tormod> Riotta, it can take an hour before the package is built in the PPA.
[22:38] <Riotta> okay no problem I will wait
[22:38] <Riotta> thanks for your support
[22:58] <bryce> heya tormod
[22:58] <tormod> hi bryce
[23:06] <bryce> oh fsck me - http://www2.bryceharrington.org:8080/X/Graphs/totals.svg
[23:06] <bryce> total # bugs exceeds graph limits X-P
[23:09] <tjaalton> hehe
[23:13] <pwnguin> bryce: is the animation intentional or just ff being really bad at svg?
[23:14] <bryce> pwnguin, ff
[23:14] <pwnguin> cuz i could see some canvas or ajax stuff possibly
[23:14] <bryce> pwnguin, actually it is pretty quick for me, might be slow internet or slow computer
[23:15] <pwnguin> you've insulted a nerd's computer!
[23:15] <pwnguin> oh, interesting; you embedded the svg
[23:15] <bryce> it's not embedded... it *is* svg
[23:16] <pwnguin> yea, i saw that seconds before you reminded me
[23:16] <bryce> e.g. you could download the svg file and load it in firefox directly (or in inkscape or any other svg viewer)
[23:16] <pwnguin> this all reminds me to do something with my bootcharts
[23:17] <bryce> pwnguin, these are all svg just output directly from gnuplot fwiw
[23:18] <pwnguin> ive seen your python scripts i believe
[23:18] <pwnguin> but i was thinking of doing some xslt
[23:18] <pwnguin> ive got daily bootcharts, i could probably build a graph of boot over time
[23:47] <tormod> Riotta, the evdev package is built now
[23:48] <Riotta> thanks
[23:48] <Riotta> will try it
[23:51] <Riotta> be right back