=== ripps_ is now known as ripps [08:48] tjaalton: do you know what version of libdrm Lucid will use? [08:51] tseliot: no, there's 2.4.15 but who knows what will be released within the next few months [08:52] depends on what ati/intel(/nouveau?) require [08:53] right, we'll see then === seb128_ is now known as seb128 === seb128_ is now known as seb128 === seb128 is now known as seb128_ === seb128_ is now known as seb128 [15:07] bryce: the versions_current.html doesn't show lucid versions yet? also, libxss is libXScrnSaver upstream, so the upstream version isn't shown [17:02] tjaalton, hmm, ok will get that working [17:23] tjaalton, should be fixed now - http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html [19:02] Hello, I have a quick X question to rule out some possible causes for a bug [19:03] does X at all control the brightness of a display? [19:03] I am sure it doesn't, but I just want to double-check [19:03] for laptops, it can [19:04] oh? [19:05] so, if a user is experiencing changes in the brightness level on their display, could that be an X issue? [19:05] note, it isn't a power-saving setting [19:07] brightness can be changed through X yes. X doesn't change it on its own, it has to be requested by a client [19:08] mostly it exports the interface from /sys/class/backlight/ [19:08] ok, that helps [19:09] hmmm, ok, I will have to investigate this further [19:09] thanks! [19:10] hi [19:13] https://bugs.launchpad.net/ubuntu/karmic/+source/fglrx-installer/+bug/440233 <--- this bug is not assigned.... do you think it would ever be fixed within a few months or shoudl i be looking at a new motherboard+ integrated video card? [19:13] Launchpad bug 440233 in fglrx-installer "fglrx fails at startup because of missing amdpcsdb.default + removal leaves bad settings in Xorg.conf" [High,Confirmed] [20:11] added Debian Testing as well - http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html [20:53] bryce, radeon KMS: I see the kernel guys have made some blueprints and stuff. I hope you are in the loop? [20:53] is it right that they have settled on 2.6.32 only but want to use radeon KMS by default? [20:54] yep and yep [20:55] we had a chance to sync up plans at UDS [20:55] aiui the debian and ubuntu kernel teams met at plumbers and decided to both settle on .32 [20:57] so they have massive drm-backporting in their plans also then? [20:57] bryce: hi... has the slow radeon KMS performance been improved? [20:58] with .32? [20:58] mac_v, it has improved yes [20:58] cool... [20:58] but not quite at UMS level [21:00] sadly , X crashes in .31 while viewing image files... not sure how to debug it even.. :( [21:00] then suspend/resume is quite important and needs lot of testing and probably patches [21:00] mac_v, tips on debugging X issues are available from http://wiki.ubuntu.com/X/ [21:00] mac_v, why are you using .31 ? :) [21:01] mac_v, if those docs don't answer your questions, please add Q's at the bottom of the respective page and I'll try to fill in / clarify [21:01] karmic ;) .... need to get to lucid ;) [21:02] I hope the performance issue on radeon can be worked out by release, but at this point having KMS in place is a higher priority [21:02] mac_v, even if you use karmic you should use the lucid kernel if you want to try KMS [21:02] bryce: is there a bug already reported > where X crashes when there user is viewing a lot of image files? [21:02] mac_v, heck if I know [21:03] we get so many bug reports now it's impossible for me to keep track [21:03] lol.. yeah... [21:03] bryce: saw your graph ;) [21:03] sadly I am having to give up the notion that I'll ever be able to handle all the bug reports [21:04] I am going to just have to pick some suitable subset to focus on [21:04] maybe bug reports from people with the highest karma ;-) [21:04] bryce, I can defend KMS by upstream focusing totally on it, but I would not trade performance for "flicker-free" booting [21:04] * mac_v has a healthy karma ;) [21:06] tormod, I think this is one of those situations where due to it being LTS, we want to put the tech in place that we're going to be able to maintain for several years [21:06] which accentuates the importance of upstream's total focus on it vs. UMS [21:06] bryce, that's sound sane [21:07] as well, the Dx team is doing a lot of stuff now which presupposes KMS is there, so if we're not on KMS we make them grumpy [21:08] I was a bit worried this could be a top-down management decision because esthetics and buzzwords are important, but that's certainly not true, right? [21:08] same rationale exists for why we're pushing for -nouveau [21:08] tormod: any word on this bug > Bug #436546 [21:09] Launchpad bug 436546 in xserver-xorg-video-ati "X crashes when using compiz cube and cairo-dock" [Undecided,Confirmed] https://launchpad.net/bugs/436546 [21:09] but then we definitely should hurry up and get radeon KMS by default in Lucid [21:09] yep [21:09] and prepare for the bug flood [21:10] there is definitely top down encouragement for doing this [21:10] however, I had both -nouveau and -radeon KMS in the plans for karmic myself, already so it's just encouragement for what had already been planned :-) [21:11] (I was actually pleasantly surprised to see top down support for this strategy, since I had expected it was going to redouble focus on proprietary driver support) [21:11] bryce: is it possible to run gdb from one user and wait for the X crash to be produce in another session? [21:12] another user* [21:12] use another machine [21:12] mac_v, if that other user is root, then yeah [21:13] otherwise when X crashes you'll be stuck.. [21:13] mac_v, jcristau is right though; usually better to ssh in [21:13] I am sad to see how much time you Canonical guys have to use on proprietary drivers [21:13] jcristau: i dont have a second linux box :( , the other one is windows :/ [21:13] great blob support is of course a major advantage for some users [21:13] mac_v: windows has ssh clients [21:13] tormod, yeah [21:13] (X will be stopped in gdb, and you can't vt switch with X stopped) [21:14] oh [21:14] but what if the resources had been used on open source for the benefit of the future [21:14] tormod, to be honest, the amount of effort I spend on proprietary drivers myself is quite small compared with what I spend on foss stuff [21:14] mac_v, look for putty [21:15] good to hear that [21:15] tormod, tseliot and superm1 do most of the hard work on them [21:15] yeah , i should do that... havent tried putty , its about time i debugged this crash ;) [21:16] tormod, I'm hopeful that if we can get 3D+KMS on r6xx/r7xx for -radeon, we may drastically reduce the number of -fglrx users [21:17] bryce, yes according to phoronix posters, radeon is already better than fglrx in many cases [21:17] with -nouveau I have similar hopes but at a much smaller scale [21:18] bryce, we won't get 3D with nouveau on lucid? [21:18] i hope that the specs that were released will be able to get XvBA like support in radeon at some point using va-api or vdpau [21:18] tormod, nope [21:18] tormod, even upstream recommends we not do 3D yet. (Forwarded mail to ubuntu-x@ last week) [21:19] tormod, maybe we could do a ppa or something if we have time/ambition [21:19] yes I think I remember that, so nouveau will not really be better than nvidia then [21:19] but better than nv :) [21:20] my suspicion is that it will be better than -nv in that it has kms, but I think we may have stability problems and regressions on a lot of hardware [21:20] but I see that as the price to pay in order to move forward [21:20] -nv is just a dead end it seems [21:20] bryce, are you running KMS on your radeons? [21:20] tormod, on my test machines, yeah [21:21] although lately I've had nvidia hw slapped into them, for all those -nvidia bugs we had post-release [21:21] oh btw regarding the bug situation [21:21] did you see my gdm.conf on https://wiki.ubuntu.com/X/RadeonKMS ? you probably had module loading race issues as well [21:22] I've given a lot of thought to how I should spend my bug time [21:22] and esp. in light of how many bug reports we got, and the need to narrow my focus, [21:22] you should just work the automated tools IMO :) [21:22] I am thinking instead of working on bugs directly, that my time would be better spent writing tutorials on how to fix certain kinds of X bugs [21:23] I've started writing up one on "how to fix X crashes", am about 50% done with it [21:23] make those tutorials into ubuntu-bug wizards :) [21:23] and I'll do one on fixing resolution detection problems, that's another common category [21:23] any known serious bugs in kernel .32 ? [21:24] yeah, and then redouble efforts around automated tools [21:24] mac_v, not in -rc8 AFAIK [21:24] great [21:24] also I want to work on expanding our ubuntu-x community. I am hoping the tutorials make a nice path for people to follow to get involved [21:26] oh I feel good, I wrote half a tutorial on git-bisect today :) [21:27] bryce, back to KMS, interesting that airlied said a few days ago, he would never push radeon KMS into a non-experimental distribution now :) [21:27] I hope that will change, like soon [21:29] wow [21:29] tormod, did he elaborate why? just stability issues in general or any particular troubles we should be wary of? [21:30] well I guess he was just defending fedora 12 which got quite some sh*t for regressions due to KMS [21:31] ahh [21:31] yeah I've heard fedora has had even more complaints than us regarding gfx problems [21:34] trying to look up the quote before I put words in his mouth though... [22:00] What should I be doing wrt nouveau in Lucid? The X/Nouveau blueprint doesn't seem to have actionable stuff for me. [22:01] RAOF, probably the next important thing to do with -nouveau is identify the kernel patches that steve needs to pull [22:01] so if you know what we need in the kernel, a list to him could help move things forward to the next step [22:02] Would he want a list of git commits? [22:02] yep [22:02] That's going to be a really, really big list. [22:03] on the X side of things, identifying if we need to pull mesa and/or libdrm support from git would be good to know [22:03] Don't need mesa, less sure about libdrm. [22:03] a debdiff for updating -nouveau to a new version that I could sponsor would be handy [22:03] "commits up to id .." should be easier [22:04] tjaalton: How would I get that? [22:06] RAOF, also testing on all of your available hardware + filing good bugs on issues would be a solid step [22:07] RAOF, also you probably know -nouveau better than any of the rest of us, so if you could jot down any bits of wisdom/advice/tips-and-tricks/etc. it would help a lot as we try to draft up the bits of documentation we'll need (release notes, troubleshooting guides, and so forth) [22:07] RAOF: well, how is it done now? you depend on a dkms'ified snapshot of drm-modules, so telling what id and of what tree is needed for the ddx [22:09] tjaalton: Ok, that's easy; master of nouveau's linux-2.6 tree. That, however, would pull in more than we need, 'cause it'll also pull in drm-next. [22:10] how many changes in drm core does nouveau depend on? [22:10] That's a question I haven't answered yet. [22:10] I'm pulling the Lucid kernel tree; I'll run some comparisons. [22:10] They tend to depend on the very most latest stuff, though. [22:11] a diff against drm-next would give an idea i guess [22:11] bryce: We'll be having xserver 1.7 in lucid, yes? That eliminates the most commonly hit limitation of nouveau, which is you don't get EXA or Xv on nv5x cards without a composite manager in < 1.7 [22:12] yep, hopefully 1.7 by alpha-1 (Dec 10th) [22:12] looks quite small [22:13] assuming i got the diff right, it's drivers/gpu/drm/ttm/ttm_bo.c | 4 [22:13] and that's it [22:13] That wouldn't surprise me. [22:13] which is pretty good news :) [22:14] But there'll be a much bigger diff against lucid's kernel, right? And we'll need to be careful when pulling in updates. [22:15] yeah [22:37] for radeon KMS we would probably need most of drm-next as well [22:38] Hm. 525 commits in nouveau that aren't in lucid. [22:38] i'll get intel video overlay pulled into squeeze's kernel probably [22:38] so that's part of intel's drm-next :) [22:44] git masters: how do I get a list of commits that touched a set of files? [22:47] git log --format=oneline -- seems to work [23:02] mac_v, that bug you asked about, it is related to bug 446578 I think. fixing one breaks the other. [23:24] Here's a list of git commits for nouveau http://pastebin.com/f5c80954e [23:25] that looks like the source code for pacman [23:26] :) [23:26] Bah. Trying to cherry pick those commits in an automated manner seems hard. [23:27] that would be the wrong thing to do anyway [23:28] What would the right thing to do be? [23:28] * tormod as a kid would type stuff like this from computer magazines into the "home computer" and hope nothing break before I could save it on the tape recorder [23:30] RAOF: either merge from some tree, or combine the stuff into one big 'add nouveau' patch, imo [23:30] trying to rebase will just lead to madness [23:31] We could merge, as long as we don't mind pulling drm-next in. [23:31] i suspec tthat you do [23:32] I'm open minded about drm-next, but really it'd be a kernel team decision [23:32] I pinged sconklin [23:32] heya [23:32] Howdie. [23:32] sconklin, we were just discussing kernel stuff needed for -nouveau/kms (and radeon kms) [23:33] in particular, it appears to need drm-next [23:33] sconklin, Here's a list of git commits for nouveau http://pastebin.com/f5c80954e [23:33] RAOF: shouldn't be too hard to extract just what nouveau needs from -next [23:33] So, getting nouveau in the kernel by merging from their kernel tree implies merging in drm-next, because they frequently merge drm-next into their tree. [23:33] wel, hopefully :) [23:34] +l [23:35] If we want to add nouveau by means of a mega-patch we'll need to carefully merge in the drm changes nouveau requires, and check that they don't break our other drm drivers. [23:35] Someone told me that the drm-next commits required for nouveau were not stable with intel harwdare, anyone know about that? It was a hallway conversation at UDS [23:36] I don't know about that, no. [23:36] jbarnes, ^^ ? [23:36] radeon KMS will probably need some drm-next stuff also [23:37] here's my general thinking about all of this - please say something if I'm on crack . . . [23:37] If we want to test drm-next I can trivially extend nouveau-kernel-source to build the other drm drivers, too. [23:37] I'm beginning to understand the risks to nouveau, and there are a lot of them, and it also impacts our normal code flow. [23:38] The best thing would be to get it into the first alpha and see if it falls over. [23:38] I still don't have a solid understanding of what our benefits are as a distro to using nouveau [23:38] I do understand the benefits to nouveau. [23:39] I also see that Fedora appears to be dealing with a pile of graphics stability issues rigth now [23:39] sconklin, one of the main benefits we gain is a more active upstream (compared with -nv) [23:39] (and I admit "active upstream" can be a con as well as a pro depending on the situation...) [23:40] bryce: understood, but that upstream pretty much admits that they aren't ready for relases or a distro. [23:40] But . . . this could really get them some huge benefits also [23:40] Which is a pity, because they're a much better nvidia driver than nv. [23:40] didn't stop fedora. but then rh hired one of the nouveau developers. [23:41] sconklin, I still expect that most nvidia owners will still just use -nouveau as a bridge to installing -nvidia. [23:41] yeah, and trust me I know that "because Fedora does/doesn't do something" isn't a good reason to go either way on a decision. [23:42] fair enough :) [23:42] bryce: I agree. Nouveau is a much better 2d driver, but most people are going to want 3d. [23:42] bryce, and are all the drm bits either compatible or selectable between -nouveau and -nvidia? [23:42] what RHEL will do is maybe more relevant [23:42] nvidia doesn't have any drm bits. [23:42] sconklin: nvidia doesn't use drm at all [23:43] tormod: not necessarily - RHEL and Ubuntu have very different user bases. [23:43] sconklin, nvidia does its own thing [23:43] A problem nouveau _may_ introduce is binding to the hardware in the initramfs and preventing nvidia's kernel module from loading. I haven't tested that. [23:43] bryce, sconklin: I haven't heard anything about that either [23:43] bryce: sorry, I meant "any of the things in drm-next" [23:43] nouveau and intel should be mostly independent in the kernel [23:43] sconklin, ahh [23:44] ok I think I drifted off topic a little. [23:44] jbarnes: But nouveau requires a different drm.ko to the one we ship, and that's shared. [23:44] bryce: the ptches that you pastebin'd - is that the entire drm-next diff from our tree? [23:45] RAOF: yeah but it's mainly TTM functionality there afaik [23:45] RAOF, sconklin, so really what -nouveau buys us is an out-of-the-box kms 2D experience on first boot (ooh nice boot), followed by installation of -nvidia and the usual teeth grinding on binary blobs ;-) [23:45] unless they've also made some core mode setting changes or something [23:45] sconklin, no I think RAOF selected the specific ones needed. RAOF? [23:46] sconklin: It's the full diff of everything nouveau touches against our tree. [23:46] bryce, RAOF - plus we support open development, and provide some solid testing base and bug reporting for upstream. [23:46] sconklin: Upstream will unlikely to be terribly interested in our bugs, unless we track git closely. [23:46] don't tell Bryce there will be more bug reports :P [23:47] sconklin, right, and while in the near term you're right that this is to upstream's benefit mostly, since it's an LTS it hopefully means in the long term we'll be more able to deploy more fixes than if we stuck with -nv [23:47] RAOF: I intend to offer them the option of linking with lp through the upstream plugin, they probably won't want to. [23:47] although that's kind of hand-wavy... -nouveau is developing fast enough that I suspect backporting fixes to the LTS would only be realistic for some months before the codebases are too divergent. [23:48] bryce: I support that assessment, although the bottleneck would be the kernel, rather than libdrm (because that's much more nicely isolated) [23:48] bryce: right. and I can forsee a degenerate situation where we end up sort of stuck with the LTS, but the testing we did there lets us turn our a really good M release [23:49] Yes, what I was describing was the kernel. But also remember this - that starting with Lucid we'll probably also have the ability to run later kernels on Lucid userspace [23:49] We could track git closely in xorg-edgers and require bug reporters to retry with that; upstream would likely be interested in _those_ bugs. [23:50] which gives people a choice [23:50] so I'd like to propose a plan (for the kernel at least) [23:51] That we (very soon) pull nouveau and the required drm-next into Lucid. [23:51] That we invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue. [23:52] and whether to rebase to a more recent nouveau or to freeze and take selected patches. [23:52] If we freeze, then there's a good chance that by the time Lucid releases, linus's tree will have caught up with the drm-next that was used for nouveau. [23:52] sconklin, +1 sounds good to me [23:53] +1 from me, too. [23:53] and we'll just be supporting nouveau + selected patches, without any drm sync problems. [23:54] ok, I'll write this up and send it around to the kernel group (and who else) - and which mailing lists am I not on that I need to be? - X related? [23:54] linus's tree catch up with drm-next, isn't that 2.6.33 by definition? [23:54] tormod: rc1 :) [23:55] and lucid has settled for 2.6.32 right [23:55] yeah, I think that's right. [23:55] so we won't get it. [23:55] sconklin, ubuntu-x@lists.ubuntu.com [23:55] I would say here that pulling in drm-next is subject to veto by the kernel ack process [23:56] s/would/should/ [23:56] I can't make those decisions unilaterally [23:56] I wouldn't expect as much. [23:56] No, just trying to be clear [23:57] I wonder about alpha-1 that's like next week, right. shouldn't this be dogfood for at least a week? sounds like sorting out the right drm-next commits is not trivial [23:57] so I'll join the ubuntu-x list and then send this to both that and the kernel list, and shout if I get anything wrong, please [23:58] tormod: I know, and I'm getting beat up about some other unrelated things at the moment, so let me discuss the priorities with some people and see if I can get some help [23:58] you'll get broad coverage but maybe more than you'd like