[01:38] vish, that was fast - http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=77b13a02c70842a58e0590d0243f0ae016c5a640 [01:38] let me know if its working for you [08:29] hmm, do we even have an fglrx that works in lucid? [08:29] kinda funny to ask people test it.. [09:09] Sarvatt: sure, it seems to be working fine.. [although i didnt know what triggers it to happen] I'll watch the gdm log for a week for any activity [09:10] also , shouldnt the errors go to Xorg.0.log ? i think that would need to be corrected too? [11:39] * Ng spies an ubuntu job advert for an X integration engineer [14:06] yeah i was thinking the thing tjaalton :D [14:46] hmm [14:46] libdrm_radeon and libdrm_nouveau are missing from ia32-libs [15:10] bryceh: http://paste.ubuntu.com/367635/ :) [15:10] (with 100_rethrow_signals.patch) [15:14] uncommented line 302, stops segfaulting when things FatalError http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/100_rethrow_signals.patch;h=97545e5e5e75151537e40ccd611ae3c5067d0797;hb=refs/heads/ubuntu [15:56] Sarvatt: yeah, maybe I should merge mesa/libdrm so -ati can be synced. then we'd have preliminary r800 support.. === yofel_ is now known as yofel [16:22] hmm ubuntu-x-swat regression testing eh [16:22] but nvidia geforce 2 and above? [16:22] are we testing nouveau? [16:23] i mean nvidia hasn't exactly been very nice with their -96 drivers. [16:23] catching fglrx regressions early. is that a joke? [16:23] they claim they maintain it, but it's still a pile of crap that makes my screen quiver like jelly. [16:31] nvidia lacks the resources to properly maintain the old drivers [17:05] tjaalton: you dont even need to update libdrm or mesa, the r800 support is 2D non KMS only. i doubt r800 dri will make it until mesa 7.9 even since 7.8 is going to branch in a week or two to get ready for release [17:08] i was just guessing they have a fglrx that works with xserver 1.7 for people to beta test, don't know why they said geforce 2 or higher also since there is no nvidia proprietary driver that works for geforce 2's on xserver 1.7 as far as I know [17:08] ask ara :) [17:09] too late. [17:09] 8 seconds too late ;-) [17:09] lol [17:09] i can't wait for nouveau to spawn proper 3D support for nv1X [17:10] then i won't have to put up with a jelly-like screen [17:10] i dont think it ever will? [17:10] =( [17:10] they were doing mesa classic for that [17:10] it said it was in progress [17:10] oh? [17:11] i mean.. [17:11] WIP [17:11] in the feature matrix [17:11] http://nouveau.freedesktop.org/wiki/FeatureMatrix [17:15] ah I mean I dont think it'll be gallium based like nv20+ ones are, they're doing a classic mesa driver for those old ones as far as I know [17:16] Sarvatt: yep, looks like they're moving that way [17:17] i see. [17:17] but why separate them? [17:17] are the nv10+ ones so old that gallium just won't work or something? [17:17] yes [17:18] * hyperair sighs =\ [17:19] its a shame they sold nv1x cards for so darn long, people were buying up those geforce mx's for years and years after they were junk :D [17:20] heh lol [17:20] i think mine was bought while it was still one of the better cards around [17:21] i don't even know what family mine is. 10de:018a. [17:21] but then it's old enough that it may not see something newer than lenny, so. [17:28] hi [17:28] is this the ubuntu X team? [17:39] Sarvatt: oh right, -ati only depends libdrm 2.4.17, not -1 [17:39] +on [17:44] hello [17:44] i read on phoronix about the fglrx driver and i would like to test it [17:45] i have a radeon 4850 [17:47] i dont think that article is accurate [17:47] 8.660 is the same driver that was in karmic [17:47] i read the mailing list [17:47] from ara [17:48] did ara ever say there was a new driver though? [17:48] this one https://lists.ubuntu.com/archives/ubuntu-qa/2010-February/000775.html [17:48] hmm i guess no [17:49] indus, can you send me an email, instead, please [17:49] ara, yes sorry i wil; [17:49] will [17:49] indus, thanks [17:49] but just want to make sure if this is for lucid [17:50] ok nvm ill send an email [17:50] indus, yes ,it is for lucid [17:50] ok mail coming up [17:54] ara, sent [17:54] indus, thanks, I will get back to you later this week [17:55] ok no problem [17:55] bye then [17:55] thank you [17:56] one question about the open source driver, does it support the 4000 serries ATI [17:57] yes [17:58] hmm didnt think it did, i mean straight from the lucid repos or with ppa [18:00] no ppa. [18:00] ok cool i test lucid today then [18:00] bye and thanks [18:27] ara: so there's a new fglrx for the testers to try? [18:28] tjaalton, not sure, but the point is that they don't get properly tested, anyway [18:30] ara: the current one doesn't work with the xserver in lucid [18:56] ara, tjaalton: there's no new fglrx to test yet but we'll have something in time for the release. I don't think I'm allowed to say more about it [19:00] tseliot: too late for testing though [19:01] tjaalton: I can't tell you when but yes, there might be little time to test it [19:01] since I doubt they'll be able to fix it in time when issues pop up [19:07] tjaalton: well, they have their own schedule.. [19:07] but of course I agree with you on this [19:07] slackers :) [19:25] ;) [19:26] heya [19:29] tjaalton, yeah the purpose of the testing is not to do a one-off test of the latest, but rather to do regular weekly testing, so if some change elsewhere in the system breaks the proprietary drivers, we'll have a chance to catch it [19:29] tjaalton, this is to help us avoid the situation we hit last release where we didn't really notice -nvidia had been badly broken by the upstart changes until the week after release [19:30] so it's good they'll start testing before we get new -nvidia/-fglrx, so they can get a good baseline to compare against [19:31] ara, I noticed that this morning 5 people joined the Ubuntu-X team :-) [19:31] bryce_, I will pass you later on the list of volunteers... it's crazy... I have been all morning processing emails [19:32] wow [19:33] ara, good work :-) [19:33] bryce_, hopefully some of them will stick around :D [19:33] yeah [19:33] bryce_: ok [19:34] tjaalton, btw for the shlibs stuff, what would be a good example package for me to look at? I was modeling it after libxrandr, is there a better package to look at? [19:35] grumbl... google street map is really a killer feature [19:35] bryce_: libdrm [19:35] "killer", that's the word [19:36] bryce_: but maybe it's overkill if libeagle is going away anyway [19:37] ok [19:52] tseliot, have you started any of the work to port fglrx packaging over to the new way of doing things? I made some changes on phorogit, so just wanted to make sure you are set up and good to go with operating on there so we dont step on each other's toes if one another does a few more pieces [20:06] superm1: not yet. I'm in Portland at a sprint and I should be able to do it soon [20:07] tseliot, okay well just make sure to check phorogit in case i get any of that in order before you do [20:07] i switched the package name over to fglrx already [20:07] superm1: also, I will make additional changes to both jockey and nvidia which will apply to fglrx too [20:07] Ok [20:07] superm1: sure [21:02] why does jockey offer fglrx? [21:02] even if it doesn't work [21:02] there are several bugs against xorg-server because of that [21:03] like bug 508860 [21:03] Bug 508860 on http://launchpad.net/bugs/508860 is private [21:03] duh [21:03] bug 508860 [21:03] Bug 508860 on http://launchpad.net/bugs/508860 is private [21:03] like hell it is [21:03] anyway.. [21:07] tjaalton, getting a bit upset with fglrx? [21:08] it's the best option, after all of the others [21:10] bjsnider: eh? I just don't like seeing dozens of crashers against xorg-server [21:10] +filed [21:10] pretending fglrx doesn't exist works fine for me so far :) [21:11] tjaalton, maybe it's a good idea to improve the xorg-server apport hook to go and change the package to fglrx-installer immediately if it sees *fglrx* installed on the system [21:11] and likewise for nvidia [21:11] that'll at least keep the bug reports clean [21:12] superm1: true [21:14] superm1: though now you can have them both installed at the same time, so why bother? :) [21:15] haha. well then at that point - go and query if fglrx is modprobe'd or nvidia and adjust package accordingly [21:16] yeah that's a better metric [21:26] same goes for the virtualbox crashers [21:26] there are maybe hundreds of dupes [21:26] most moved to vbox of course [21:28] tjaalton, okay well just piggyback that on https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/516264 [21:28] Ubuntu bug 516264 in xorg-server "Xorg-server apport hook should detect fglrx/nvidia" [Undecided,New] [21:28] might as well solve all those in one swoop if possible [21:39] superm1: done [21:41] does vbox take down the kernel that much? [21:44] regardless of how often it's taking down xorg-server, if it's providing external pieces in, it shouldn't be lodging it's bugs in xorg-server's set of bugs [21:51] bjsnider: You were after 3D support in nouveau for your ancient nvidia card? The DDX already registers a different glx provider on those old cards, and it looks like a sorta-functional nv0x - nv2x driver is on its way to be merged back into mesa. [21:52] RAOF, i wasn't [21:52] Ah, sorry. 'twas hyperair. [21:53] RAOF: =O [21:53] that's great news! [21:53] what's DDX? [21:54] The X component of the driver stack. [21:54] ah [21:54] Current status of that 3D is apparently, and I quote: “However the killer feature is 'it actually draws stuff'” [21:55] xD [21:55] well isn't that nice. [21:55] (And some simple games may even run at a decent FPS) [21:55] oho, really? [21:56] it won't be outclassing my i965 anytime soon eh =p [21:56] it wouldn't be very fast even if the code was a perfect as if god has written it, i imagine [21:56] well if compiz works i'm happy. [21:57] or would that be expecting too much? =p [21:57] compiz, that thing that's being replaced by gnome-shell? [21:58] gnome-shell's not replacing compiz anytime soon on my macine(s) [21:58] Given that the much, much better developed nv4x & nv5x gallium drivers *mostly* run compiz, I think you may be expecting a liiiitle too much. [21:58] RAOF: heh figures. i'll just scrap GNOME and jump to LXDE or something on that machine. [21:59] bjsnider: i don't suppose nouveau would run the shell either, would it? [21:59] it's opengl either way [21:59] it's not xrender [22:00] compiz is opengl too, isn't it? [22:00] yeah, that's what i mean [22:00] so both won't work eh [22:00] well, at least compiz++ brings support for crippled drivers [22:01] gnome-shell doesn't, and probably will never [22:01] not to mention that it eats eats more RAM than firefox does >_> [22:01] how do you know? [22:02] bjsnider: iirc there was an argument on some mailing list or other. [22:03] something about the shell not getting a backward compat mode, because of the way it's designed, blah blah blah drivers should have been fixed by then, blah blah something about we shouldn't hold ourselves back because of a few crap drivers [22:03] i don't think anything's written in stone [22:04] but the most fun part is how they keep convincing themselves that compiz is a pile of bloated crap that brings nothing but eyecandy and no usability features when gnome-shell takes up 5x the amount of memory compiz does. [22:04] compiz is bloated crap [22:05] there's no question about it [22:05] well then, so is GNOME. [22:05] and the shell is 5x more bloated than compiz, so where does that put it? [22:05] bloated, incomplete, unusable crap? [22:05] it's certainly incomplete [22:06] right, and while it's this incomplete, it's already eating up 5x the amount of memory compiz does. [22:06] i'm using it right now, so it can't be considered unusable [22:06] when it's complete, how much will it take? [22:06] right, so it's "usable", but nowhere near the usability compiz gives me. [22:06] hyperair: when it's complete you'll have 1TB memory. and a flying car. [22:06] just for the record, i like having my screen edge triggers at the bottom of my screen. [22:06] jcristau: that sounds about right, yeah. [22:07] usability, like, animated transparent gears, snow, and fire on the desktop? [22:07] jcristau: no actually, i don't think it'll ever be completed. halfway along the line, they're going to decide that it's become very unmanageable, akin to gnome-panel, and scrap it for a... GNOME SHELL2! [22:07] bjsnider: there. that's the problem with you gnome-shell guys. [22:07] gnome-shell-ng [22:07] bjsnider: when i say usability, you pick the most useless plugins out of compiz and slam the entire compiz for it [22:08] bjsnider: open your eyes damnit. [22:08] hahah [22:08] so you admit that there is feature bloat in compiz [22:08] bjsnider: i disabled those plugins. [22:08] bjsnider: but that's all they are. "plugins" [22:08] if i toss them out the window, it means that they aren't running, they don't eat up space on my hard disk, and all in all, there is no bloat. [22:09] a few compiz plugins should be builtin, the rest should be thrown away. and then you get something halfway sane. [22:09] i like my scale plugin. [22:09] it beats anything gnome-shell can offer me at the moment. [22:09] i can't make out the useful ones from the bloat because they're all piled in there together [22:10] bjsnider: that's why i told you to open your eyes. [22:10] the more you look at those crap demo videos uploaded, the more you think "compiz is all bloat" [22:11] because those demo videos attempt to showcase all these useless effects while not actually showcasing any of the really useful ones [22:11] it's not all bloat, only 95% of it is bloat [22:11] bjsnider: better than gnome-shell, which can't even match up to 5% of compiz's functionality. [22:11] assuming your figures are correct [22:12] sure it does [22:12] oh right, if you want to count in memory usage, i suppose gnome-shell achieves 500% [22:12] yes [22:13] because some random joker decided "let's use javascript!" [22:13] and everyone was drugged so heavily that they all agreed >_> [22:14] there's a gnome-shell irc channel where you can voice your complaints directly to the developers... [22:14] i nearly got kicked for "trolling" [22:14] hahahaa [22:15] i don't know *why* they would think that [22:15] FWIW, I quite like many of the ideas embodied in gnome-shell. [22:15] it's utterly ridiculous. they'll bar out your choices, in favour of theirs, and then when you don't agree with it, they blame you for trolling and ignore you. [22:15] I don't think that's an accurate description; certainly not of the mailing list. [22:15] RAOF: that was on IRC. [22:16] Every new idea is not necessarily a good idea. Gnome-shell stinks a bit. [22:16] new features have been added that you can check out in rico's ppa [22:16] Ubuntu-X: All gnome-shell, all the time. :/ [22:16] i think that's the one [22:18] well, they kicked us out of the gnome-shell channel because they thought our hectoring and badgering was trolling, but we really have good ideas [22:18] don't get me wrong, i love GNOME and it pains me to have to move to anywhere else, but i want my panel, and i want my compiz. otherwise you let me have back my bottom screen-edge triggers, my infinitely customizable keybindings, and something akin to scale + scale addons + scale text filtering [22:18] hyperair: Problem is, they'll dumb it down enough to the point of not giving you a choice of having it back. [22:19] Cobalt: yeah, exactly. [22:20] And bill it to the price of progress. And brilliant new ideas. Of how to interact with your data. Never mind that over the years you already streamlined the way you do things, and are quite happy for things to go on the same way. [22:20] tjaalton, superm1, I added a thingee to apport to detect if the user is running vbox and if so tell them the issue is unreportable [22:20] tjaalton, superm1, that's been in there for some months, so if we're *still* seeing vbox bugs filed against xorg-server we should see how those are coming in [22:20] I agree we should exclude them [22:31] bryce_: Did you get in contact with nvidia re: nouveau ctxprogs? Have you heard back? [22:31] RAOF, not yet, I did just touch base with a couple of the kernel engineers [22:33] Did they have anything interesting to say? [22:35] yes [22:37] I'm currently preparing something approximating a debian/copyright for a nouveau-firmware package to add to the testing packages in xorg-edgers/nouveau. Should I stop? [22:37] RAOF, the kernel team is looking at how it should be packaged, probably in some separate package. andy will get back to us on it [22:38] RAOF, continue on with it [22:38] we're not taking it as a blocker at this time [22:39] Ok. Once I've got that bit, I was thinking of writing a call-for-testing to ubuntu-x & ubuntu-devel; those bits in xorg-edgers/nouveau should (a) not break anything on non-nvidia hardware, and (b) work. [22:40] that sounds great [22:40] RAOF also andy said he can update the kernel [22:40] we also talked about supportability post-release [22:41] he said that the kernel team has an exception from having to do srus for linux-backport-modules [22:41] so if we take the approach of having nouveau in l-b-m then it gives the flexibility of putting out new git snap shots of the driver post-release if it looks sane enough to do so [22:42] That would be good. [22:43] I also asked if we can also include the nvidia binary package from l-b-m on the livecd, and he said that should be doable; we'd need to go through the foundations team for that [22:43] So we wouldn't have to try to backport commits. Great. I notice that there are a bunch of nv5x fixes pending on the nouveau mailing list already :) [22:43] Would that mean that l-b-m-nouveau would be pulled in by the kernel metapackage? [22:44] right [22:44] Excellent. [22:47] Ok. I'm going to stop stressing about debian/copyright and just put in all the information I think is pertinent. Someone else is going to need to go over it anyway! [22:47] sounds good [22:48] thanks for raising it as an issue, I've added to my todo list to follow up on it later on and make sure everything's square [22:52] RAOF, mirco's borrowing the desktop today but I think tomorrow I'll get nouveau going on it again and re-test stuff. I'd really like to get compiz running successfully, and sort out why it's not vt-switching [22:54] bryce_: You'll need newer dri2 protocol headers if you want to build mesa from git (and it's really the only way to fly ;)). If it's a GeForce8 or newer you'll also need the nouveau-firmware package before any acceleration works. [22:56] ok thanks, yeah it's a G86, so perhaps that's why compiz failed [22:56] Yes. It might also be why VT switching is failing, but I'd hope not. [23:13] tseliot, bryce_: so my the usb id for my tablet isn't in 69-xserver-xorg-input-wacom.rules fwiw [23:15] bdmurray, bryce: does it work correctly if you add your id in the udev rule? [23:16] tseliot: I haven't tried yet, add it and then what? [23:17] bryce_, not sure if the vbox stuff is still showing up. just know the fglrx/nvidia is [23:18] superm1, yeah I didn't fuss with that in the apport rule [23:18] on next boot (as you can't unplug it) the device should be detected and should show up in "xinput list" [23:18] and work [23:18] however I do have a script to process the xorg queue and look for nvidia/fglrx bugs and move them to fglrx-installer or nvidia-{mumble} [23:19] you can fake unplug it [23:19] superm1, I think we could probably improve the apport script itself to file the bug directly [23:19] udevadm trigger --action={add,remove} or something [23:19] or stuff an event in sysfs [23:19] bryce_, so can't you just change the Package in the crash report in those scenarios? [23:20] tseliot: so what would I use for SYMLINK in the udev rule then? [23:21] superm1, yep that's exactly what I meant [23:22] cool, glad we're on the same page :) [23:22] bdmurray: I guess "input/tablet-$MODEL_NAME" should be fine [23:23] whatever your model iss [23:23] is [23:23] or you can simply call it "input/tablet-brian-test" [23:45] tseliot: no change afaict [23:52] bdmurray: if that didn't do it, you might want to ask the kernel team about it