[01:25] YES. I WIN. [01:25] quirks=0x0486:0x0185:0x40 [01:27] * RAOF considers opening up his laptop so he can help it push the bits around faster by hand. Less slow, more speed, damnit! [01:27] nooooooooooo! the cursor doesn't track correctly when xrandr rotated! noooooooooo! [01:28] Fixed in xserver 1.9 [01:28] RAOF: was that directed at me? [01:28] (Although I think you'll need to manually set the input transformation matrix) [01:28] Yup. [01:28] I'm on a roll tonight, tell me what to do [01:29] * RAOF tries to remember… [01:29] So, if you're using Xserver 1.9 you can set an input transformation on your input device. [01:30] It's a 3x3 perspective matrix, so you basically just want the last column to be 1s, the last row to be 0s, and the top-left 2x2 submatrix to be a rotation matrix for your xrandr transform. [01:30] X.Org X Server 1.7.6 [01:30] so I preusme I'm not running 1.9 [01:30] No. [01:30] so close! [01:31] man I have been fighting with this t91mt and the touchscreen under lucid [01:35] RAOF: so wait, how come xrandr under Karmic worked fine? [01:37] As in: it rotated your input device, too? [01:37] yep. [01:37] infact, I have a live usb stick I can test that on too. 1 sec [01:44] yep works fine [01:44] Ah. So the basic rotation case should still be handled. [01:47] I'm not sure what the difference is [01:54] I'm not familiar with what you've had to do to make it work in Lucid — in an ideal world, it should work as well as karmic (hah!) [02:04] hah [02:04] well, the kernel in lucid blacklisted the touchscreen from hiddev [02:04] so I unblacklisted it [02:05] then I had to quirk it with the multitouch quirk [02:05] now it works and reports correct axises, except when xrandr rotated. [02:10] RAOF, do you have a few minutes to chat? [02:10] bryceh: Yeah. [02:10] RAOF, I want to talk a bit about handling X bug reports that are filed against lucid [02:11] I was going through the -ati bug reports looking for ones to test my new upstreamer tools on, and it struck me that the vast majority of bug reports are against lucid [02:11] in fact nearly all of these were reported post-release [02:12] as usual most are kinda low quality, but not all of them [02:13] in the past before we tagged releases, bugs reported against prior releases were always kind of a nuisance to me, but when I started tagging them and was able to filter them out, I found it quite helpful [02:13] as I could just ignore anything not tagged with the current development release [02:14] So we've got a bit of a decision tree here, right? [02:15] Does the lucid bug probably have enough information to fix it? No: ask for retesting against Maverick, Yes: go to part 2 [02:15] RAOF, I guess I've gotten kinda bigoted against bug reports against non-development versions, and consider them to basically not much more than technical support requires [02:15] RAOF, yeah that's true we have a tree [02:15] Part 2: If this bug were fixed, would it be SRUable? No: Ask to retest against Maverick. Yes: … um? [02:15] but what I want to talk about is if we could just lop the entire limb off? [02:16] IOW, when someone files a bug report against a released version, have a script close the bug with a kindly message, or convert it to a question, or similar [02:17] That's pretty tempting. On the other hand, there may well be bugs reported post-release that we do want to fix *in that release*, particularly LTS releases. [02:17] so my question to you really is, to what degree do you care about bugs reported against released versions of ubuntu? Do you think having them open helps you in some way? [02:17] right [02:18] however I get the sense that we defer from closing 99 bugs so as to keep 1 open that we want to fix [02:18] Yes. [02:18] but then, reading through 99 bugs gets tedious, so I'm not sure how often we actually find that 1 bug ;-) [02:19] RAOF, what's been your experience so far with SRU'ing X bugs to lucid? [02:19] Perhaps what we want is to (a) auto close, with a nice message but (b) send them somewhere where we can periodically review them and re-open? [02:20] bryceh: Mostly my experience has been: poke the kernel team to fix it. [02:20] *nod* yeah that's exactly what I was mulling over myself [02:21] RAOF, ok yeah I think I've done a few SRUs but of those they were all either bugs that had been reported prior to the release which I had been working on, or ones I'd noticed myself [02:21] That matches my experience. [02:22] ok cool [02:22] How would auto-close interact with regressions introduced in an SRU, though? [02:22] alright, well my time is going to be pretty chopped up this next month, so dunno if I'll ever get a chance to work on it, but I've got an idea on how to render this into a script [02:23] that's a good question [02:23] That could possibly be incorporated into the script. [02:24] Actually, that would be useful regardless of auto-close or not: [02:24] Highlight bugs reported in the 10 days after an update goes from -proposed to -updates. [02:24] yep [02:25] and it could verify that the user had the requisite version installed, so it still filters out unrelated bug reports [02:26] ok cool [02:26] hey I have something cool for you :-) [02:26] That would be pretty handy. [02:26] Oh? [02:26] http://www2.bryceharrington.org:8080/cgi-bin/send_upstream.cgi [02:26] RAOF, this is the bug upstreamer I demoed at UDS [02:26] OOooooooooh [02:27] it's now been generalized sufficiently that others can use it [02:27] once I get a few people test driving it successfully (and have a couple other features added in) I'll publish it for general use [02:28] RAOF, mostly I've tested it with -ati and -intel bugs [02:28] I'll give it a whirlygig. [02:28] there may be some problems using it against source packages that don't have upstream bug tracker info set... but these should be rare (tell me if you run into one) [02:28] RAOF, thanks [02:29] one of the upcoming features (which is ultra cool) is sending attachments as well. We've got the code to do it, but it needs some integration work [02:29] Kamran, my GSoC student, put it together [02:29] here's the evidence that it works: https://bugs.freedesktop.org/show_bug.cgi?id=28969 [02:29] Freedesktop bug 28969 in Driver/intel "[Intel Arrandale] Screen flickers" [Normal,New] [02:30] RAOF, I don't know if you've been upstreaming many bugs so far, but if so this'll majorly save time [02:30] I haven't been upstreaming too many bugs at this point. [02:30] RAOF, also if while using it you have ideas on improving it let me know [02:31] I most assuredly shall! [02:31] Incidentally, pitti's new add_drm_info hook is a bit of a winner. [02:31] oh? [02:33] I've landed that change I was talking about to make launchpad show the first/last 40 comments on highly commented bugs. Went in earlier this afternoon [02:33] In some respects its duplicates the xrandr output, but it's got the edid in an easier to use form, and is right there on the bug info. [02:33] should show up on edge in a day or so [02:33] oh nice [02:33] Cool. That'll be *substantially* more useful than just the first 80 :) [02:33] yeah that was on my todo list to get that edid info parsed better [02:33] yeah I hope so [02:34] aaaand I happened to make it 1.5% faster at rendering the bug page :-) [02:34] :) [02:36] Yay! Kernel's finished building. [03:03] RAOF, http://pastebin.ubuntu.com/460901/ [03:03] copyediting appreciated (especially anything we could leave *out* to shorten the message) [03:19] bryceh: Maybe http://pastebin.ubuntu.com/460905/ ? [03:46] RAOF, yeah that's better === Amaranth_ is now known as Amaranth [06:32] Bah. Die, cursor, die! === \vish is now known as vish [10:11] RAOF: regarding the slowness, are they all on maverick? i'm hitting some really strange problems making my machines really slow too [10:11] I/O problems with 2.6.35 after a few hours it looks like, goes away after a reboot [10:13] i can't get more than 1MB/second out of my HDD when it happens, haven't had it with 2.6.35-7 yet knock on wood [10:27] Sarvatt: Yeah, they are. [10:28] only I/O slowness? [10:28] I suspect something might be leaking video memory again? 1.6GiB of gem objects, and although there was only ~200MiB of the 2GiB RAM used it seemed to be paging out to swap. [10:29] there's ureadahead causing an extra 500MB memory load on all my systems too :D [10:29] oh boy things are leaking again? [10:30] 58MB here so its not a problem on edgers it looks like [10:30] After restarting X it dropped back to 70ish. [10:31] sure it wasn't 160MB? [10:31] Pretty sure. [10:31] is there any incompatibilities with llvmpipe via xorg-edgers ppa on lucid? [10:31] what do you mean incompatibilities? [10:31] I counted the triplets. [10:31] bug #603507, does anybody has seen similar issues? [10:31] Launchpad bug 603507 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[intel] clutter views not updated correctly with the new clutter (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/603507 [10:32] i compare it to GTT total, if its got an extra digit it's gigs :D [10:32] not sure if that's a driver issue or a clutter one... [10:32] Sarvatt: I want to test llvmpipe but was wondering if lucid is supported, in other words if I should have to upgrade to mavrick to test llvmpipe [10:33] scar_: nope its on lucid too [10:33] seb128: any quick ways to test that bug? [10:33] ok great, then also is it necessary for me to use the xorg-edgers ppa or can I use x-updates? [10:34] Sarvatt, run unity on maverick if you have intel [10:34] or unity --popup [10:34] I'm running unity right now on Intel. [10:34] Sarvatt, or some of the gnome-games using clutter [10:34] the worms one has the issue as well [10:34] RAOF, under GNOME or an unity session?K [10:35] In a unity session - it needs to be run under GNOME? [10:35] nibbles isn't working [10:35] Sarvatt, working as displayed content? [10:35] quadrapassel is fine [10:35] displaying [10:36] RAOF, right, I'm unclear what the issue is exactly [10:36] unity session works fine [10:36] but running unity --popup under GNOME doesn't [10:36] nor does the worm game, it never displays the board [10:36] Hm. [10:36] it works fine with clutter 1.2.4 [10:36] or it works fine on clutter 1.2.10 and nvidia [10:36] There is a known problem with fullscreen flash, which could possibly be related. [10:36] That'll be resolved when we move to intel 2.12. [10:37] Which should be soon! [10:37] i would say its a mesa or clutter bug [10:37] hey njpatel [10:37] hey hey [10:38] njpatel added a comment to the bug [10:39] That does sound like a very similar behaviour to the flash problem. [10:40] could you add a reference to that flash bug on launchpad? [10:40] I'll hunt it down. [10:40] thanks [10:43] https://bugs.freedesktop.org/show_bug.cgi?id=28573 is what I was thinking of. [10:43] Freedesktop bug 28573 in Driver/intel "[i965] Fullscreen flash and windowed SDL games fail to update the screen" [Normal,Reopened] [10:46] dont suppose http://git.clutter-project.org/clutter-gtk/commit/?id=d50240f524870fd80b2cc5bb96a7bf9b8e10c754 might be related? [10:47] njpatel, ^ what do you think? [10:47] Sarvatt, it seems worth trying [10:47] let me try [10:47] CLUTTER_VBLANK=none fixes it seb128 [10:47] so it might be [10:48] indeed [10:48] seb128, that clutter bug sounds like it could be the issue [10:48] thanks for the CLUTTER_VBLANK=none workaround [10:49] i cant remember the clutter debug option to only disable INTEL_swap_events, argh [10:50] it would make sense that it only affects maverick though even though lucid had 1.2.x because INTEL_swap_events are in xserver 1.8+ only [11:05] yep its stuck in event processing without CLUTTER_VBLANK=none [11:06] ok, that patches to clutter-gtk fixes the issue [11:06] I'm uploading that to maverick, thanks guys [11:06] njpatel, ^ [11:07] \o/ good to hear [11:08] seb128, awesome [11:08] Sarvatt, thanks! [11:10] scar_: sorry, missed your question, xorg-edgers is required [11:15] Sarvatt: no problem, just finished updating. If I break my x-server and can't get up back up after trying a few xorg.conf changes... do you suppose i can just remove the ppa and do update & upgrade to try and revert? [11:15] upgrade won't downgrade [11:15] scar_: sudo apt-get install ppa-purge then just run sudo ppa-purge xorg-edgers [11:16] ok thanks, hopefully I won't need to use that [11:17] i'd install it anyway now while you can and if things are broken you can just run it in a recovery console :) [11:18] * scar_ sighs and holds down the shift button [11:19] Sarvatt, hi [11:19] heyo [11:19] is the disappearing mouse cursor normal or is it a bug [11:20] it's normal [11:20] its the unclutter package [11:20] jcristau, so it is a feature? [11:20] "feature" yeah [11:20] ok ;-) [11:21] can I remove nvidia proprietary via apt-get purge nvidia-glx ? [11:21] nvidia-current [11:21] apt-get has no purge command, it has remove [11:21] yeah it does! [11:23] has for years, i haven't been using debian distros that long but i've used apt-get purge the whole time i have [11:24] any idea how I can pipe Xorg -configure to more? or even a file... [11:24] why are you running Xorg -configure? [11:25] if its for the blob you want nvidia-xconfig, if you're moving away from the blob you want to just remove it completely [11:25] xorg.conf I mean [11:25] before and after the xorg-edgers i had to use xorg.conf other wise my pc hangs on startup [11:26] my geforce 2 doesn't like nouveau [11:26] scar_, you can use "COMMAND 2>1& | tee OUTPUTFILE" [11:27] Sarvatt: really? heh. [11:27] the famous stdout stderr redirections :) [11:27] Sarvatt: ooh [11:28] * cmdline/apt-get.cc: really applies Julien Danjou patch to add 'purge' command line argument (closes: #133421). [11:28] 2007. it's brand new! [11:28] no wonder i didn't know about it [11:37] Kernel driver in use: nouveau, which is awesome, but still getting Xlib: extension "GLX" missing on display ":0.0". Should I try creating xorg.conf again to force GLX to load? [11:38] also xrandr only shows 640x480 and 800x600, I think I need to change my monitor's verical and horisontal sync [11:38] scar_: you still have nvidia installed [11:38] sorry, since you have a geforce 2 its not nvidia-current that you have to purge [11:39] I think so tried to purge nvidia-current but it did nothing [11:39] I also did rmmod nvidia [11:39] its sudo apt-get purge nvidia-96 i believe? [11:40] also what distro are you using? [11:40] if its lucid you want to sudo apt-get install linux-image-2.6.35-7-generic [11:40] ubuntu i368 lucid' [11:40] you need the newer kernel to actually use nouveau otherwise you are using the fbdev X driver [11:41] I did aptitude search nvidia, it shows A next to nvidia-96-modaliases, nvidia-common, nvidia-current-modaliases and nvidia-settings [11:42] oh maybe it got removed on upgrade then, just installing the kernel might fix it [11:42] no i dont think it did if you're getting the glx missing error, hmm.. [11:43] does purging nvidia-96 do anything? [11:44] i've got to run, about to pass out here. hope ya can get it going, removing nvidia installing the new kernel and installing libgl1-mesa-dri-gallium should do it though [11:44] I'm going to try that now, the other option is llvmpipe which i initially wanted to try out, but have no idea how to use/configure it, but yeah first going to remove all this proprietary borked drivers [11:45] llvmpipe is just swrast [11:45] if you get nouveau working you dont need it, but you can use it by using LIBGL_ALWAYS_SOFTWARE=1 yourapp [11:53] after purging nvidia-96 I've now got 2d and 3d rendering via 2.1 Mesa 7.9-devel (still not nouveau) [11:54] * scar_ rases his hands in the air and screams no more lag when scrolling !!! :D [11:54] whats the OpenGL renderer string? [11:54] because that vendor string is the same as nouveau's [11:54] err version string [11:55] software rasterizer? [11:56] yes, Software Rasterizer [11:56] you installed and rebooted into the new kernel too right? [11:56] I guess that's clasic mesa [11:57] I'm using 2.6.32-23-generic-pae [11:57] ah no nouveau 3D because you are using fbdev and not nouveau [11:57] nouveau in that ppa requires a 2.6.34 or newer kernel [11:57] thats why you're using swrast too [11:58] yeah software rasterizer is classic mesa [11:58] OpenGL vendor string: VMware, Inc. [11:58] OpenGL renderer string: Gallium 0.4 on llvmpipe [11:58] OpenGL version string: 2.1 Mesa 7.9-devel [11:58] OpenGL shading language version string: 1.20 [11:58] thats what gallium swrast looks like [11:59] I see, so obtaining the new kernel would you recommend using mavrick or is there a ppa i can use for that too? [11:59] linux-image-2.6.35-7-generic is in the PPA [12:00] the maverick kernel [12:00] its in xorg-edgers just not installed automatically [12:00] w0w that's quite a change [12:00] 32 to 35 [12:01] the lucid kernel is a frankenstein of 2.6.32 and 2.6.33 parts :) [12:03] backports++ [12:04] you can use this PPA if you want automatic updates https://edge.launchpad.net/~kernel-ppa/+archive/ppa [12:05] when maverick releases that ppa will be directly in lucid too [12:06] deb http://edge.launchpad.net/~kernel-ppa/+archive/ppa lucid main <- does that look good to you or should I use mavrick? [12:06] yep thats right [12:07] i'm not sure what you install for the automatic updates though.. [12:07] linux-image-generic-lts-backport-maverick i think [12:07] or linux-image-lts-backport-maverick [12:08] I will try it soon.. [12:30] oh yeah, forgot the copy-fb patch was broken pretty horribly in intel 2.12 :( [12:38] how so? [12:38] broken as in buggy or as in "doesn't apply any more" [12:38] ? [12:38] needs major refreshing [12:39] aah [12:39] doesn't apply [12:39] that's better [12:39] * tseliot -> lunch [12:40] just merged ati and was going to do intel and remembered that I had a heck of a time trying to refresh it when it broke in git [12:43] don't suppose I could bug you to sponsor ati 6.13.1 sometime tseliot? :) http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=shortlog;h=refs/heads/ubuntu http://sarvatt.com/downloads/merges/ati/ [12:56] RAOF: about to submit sync requests for the updates needed for xserver 1.9, any idea if that really is going to be an option? i don't see fglrx updating in time since the abi bump is pretty significant this time around and they *just* introduced their new XA [12:59] ricotz: some people reporting that your last ia32libs today broke flash? [13:00] Sarvatt, lucid or maverick? [13:00] mhh, i am using the native 64bit flash plugin [13:02] they didn't say [13:02] http://ubuntuforums.org/archive/index.php/t-1476691.html [13:02] 'screw fglrx' not an option i guess? :) [13:03] probably not since theres people paying canonical to make ubuntu work on hardware that only works with fglrx i'm guessing :) [13:04] but i have no idea [13:04] i would have thought those people would use an lts [13:04] but maybe not [13:09] don't suppose you know an easy way to get a list of symbols that changed between abi's in the server by any chance? :) [13:10] like nvidia fails to load because WindowTable is undefined in 1.9, just want to look over what the blob drivers are using thats gone [13:13] a diff on /usr/include/xorg/* would give an idea [13:15] or diff of objdump -T Xorg | grep Base, but that won't tell you if prototypes or structures changed [13:16] http://cgit.freedesktop.org/xorg/xserver/log/include?qt=grep&q=abi looks like its good enough since the commits are obvious, i just wasn't sure if there was an easier way [13:18] anyway, uploading 1.9rc4 to experimental now. [13:24] morning Sarvatt [13:25] Sarvatt: btw, ty for the help w/ the touchscreen [13:25] Sarvatt: the xinput axis stuff you linked me was the final bit I needed, I'm 100% set now [13:30] sweet, glad to hear it, thats the part i couldn't do remotely :) [13:31] my computer hangs in 2.6.35-7 even in recovery mode, it looks like it's trying to startx in recovery mode though... [13:36] Sarvatt: yes, of course I can sponsor the upload. I'm also using radeon and Maverick on my main machine :-) [13:37] as regards fglrx, it will remain broken until they support xserver 1.9. I guess that's acceptable [13:38] oh, nvidia would break too though, ouch [13:40] meh nvidia is fast at picking up new abis [13:41] faster than amd for sure [13:41] fast enough? well.. [13:42] <20100702171226.GA8867@soprano.nvidia.com> [13:42] what is it? [13:42] a mail [13:43] at one point nvidia released two drivers per year. then in more recent times they were releaseing two per week. now it's more conservative again. puzzling [13:43] yes, I picked that up [13:43] http://mid.gmane.org/20100702171226.GA8867@soprano.nvidia.com [13:43] better? :) [13:43] definitely [13:44] mid.gmane.org is ♥ [13:44] :-) [13:55] jcristau: ack, did you already upload xserver? [13:55] Sarvatt: yeah [13:55] oh ok you added x11proto-xinerama-dev to xserver-xorg-dev, phew [13:55] Sarvatt: I assume you tested -radeon [13:56] I have no machines to test it on but I compile tested it [13:57] Sarvatt: ok, let me test the package with my card here, then , if all goes well, I'll upload it [13:57] https://edge.launchpad.net/~sarvatt/+archive/ppa/+sourcepub/1228102/+listing-archive-extra [13:58] ah, good, I won't have to build the package [13:59] Sarvatt: also, I think I'll move the nvidia headers back where they used to be and remove the Conflicts with mesa-common-dev [14:00] Sarvatt: http://ubuntuforums.org/showpost.php?p=9526140&postcount=5 [14:01] * tseliot tries the new radeon [14:06] the new radeon driver seems to work well here [14:07] tseliot: yeah I got a complaint email about that header move [14:08] silly people thinking they needed nvidia-current-dev for GL headers :) [14:08] hehe [14:08] Sarvatt: did you ever manage to get vmwgfx running? [14:09] Dr_Jakob: without 3D yeah, my vmware trial ran out though :) [14:09] Sarvatt, who was the email from? [14:09] Heh, just use player it should work just as fine. [14:09] Paulo Dias [14:09] did it have to do with mythtv? [14:10] Sarvatt: I can see if I can't get you a ws key tho. [14:10] The following packages are BROKEN: [14:10] libgl1-mesa-dev [14:10] The following packages will be REMOVED: [14:10] mesa-common-dev{a} [14:10] The following packages will be upgraded: [14:10] nvidia-current-dev [14:11] noooo I deleted my VM, I thought player didn't work with the gallium stuff! [14:11] I'll simply revert my change and everything should be back to normal(ish) [14:11] changes [14:12] Sarvatt: :-/ [14:12] Sarvatt: so all I need to do is install the xorg edgers and it should work? [14:12] depends, lucid or maverick host? :) [14:12] actually that doesn't matter, its the guest i'm thinking of [14:13] lucid guest. [14:13] if its a lucid guest you need to update the kernel manually, its in the PPA though [14:13] linux-image-2.6.35-7-generic at the moment [14:14] ok whats that ppa called? [14:14] and all the normal decrapification of vga16fb and stuff :) [14:14] https://launchpad.net/~xorg-edgers/+archive/ppa [14:14] kernel ppa? [14:14] its in xorg-edgers I meant [14:14] ah [14:14] just have to manually update the kernel [14:14] ah cool [14:14] oh yeah you need to install libgl1-mesa-dri-gallium as well [14:15] sorry if it all changes soon, I need to rebase all of my mesa packaging on what actually went into debian one of these days and its called libgl1-mesa-dri-experimental there [14:15] heh [14:16] i cant use the mesa 7.8 packaging from debian/ubuntu as a base because the egl/gles stuff changed so much in 7.9 [14:16] yeah sorry about that, it might change again. [14:17] and there is no ABI rules between libEGL and the drivers so that might explode at anytime as well. [14:17] But that probably isn't so much of a problem for you guyys. [14:18] yeah it's only really shipped for headers and testing stuff anyway at the moment [14:19] ok [14:20] Sarvatt: do you know Andy from VMware? [14:20] nope, sure don't [14:20] Ok, nm then. [14:25] jcristau: do you guys not see weird bugs where the breaks: oldabi on xserver-xorg-core forces drivers not in xserver-xorg-{video,input}-all to be installed on a dist-upgrade in debian? [14:26] if i dont drop the breaks on the previous abi then xserver-xorg-core always gets held back and it installs stuff it shouldn't like nvidia and radeonhd here every time :( [14:27] * tseliot uploads radeon [14:27] Sarvatt: what i've seen is dist-upgrade removing all of X [14:28] yeah that happens too [14:28] i think that was when i didnt have input and video all installed [14:28] guess why i'm getting rid of the breaks entirely.. [14:29] i can't figure it out though, some voodoo in apt ordering [14:30] right now on one box i have no packages providing video 6 installed, and i uploaded xserver with the breaks intact, the next dist-upgrade tried to install nvidia-current and radeonhd which had video-6 and that put xserver-xorg-core on hold [14:32] and if i apt-get upgrade first which removes input/video-all the next dist-upgrade removes all of X [14:32] i gave up trying to understand whats going on and just started dropping the breaks, driving me bonkers :) [14:34] Sarvatt: see the 'Xorg dist upgrade troubles' thread i started on the debian-x and deity lists. maybe you can follow up there. [14:35] thanks tseliot! [14:36] Sarvatt: thanks to you. Videos seem smoother now here :-) [14:37] tseliot: did you see that fglrx 10.6 works with xserver 1.8? [14:38] Sarvatt: yes, the latest fglrx should do that [14:38] it just has a problem where BusID *has* to be specified in xorg.conf.. [14:38] ah i've seen something about that [14:38] not sure if they fixed that or plan to fix that but it didn't sound hopeful when i was following it [14:39] had to laugh. [14:39] I wanted to wait for the new release and to apply some changes I've been working on, so as to allow delayed build of the kernel module (the module is built on next boot if the user wishes so) [14:39] way to make it impossible to package ati! :) [14:40] that BusID thing is weird. I doesn't sound new to me though [14:40] before there was something about depth [14:40] that's nvidia, ugh [14:41] the defaultdepth problem should affect both fglrx and nvidia [14:42] as they don't support 8 bits depth [14:42] which is why we set that in xorg.conf through Jockey [14:43] these things sound like they would be one liners to fix (not the 8bit thing). good thing we don't have source. [14:43] is it? i got nvidia auto loading without an xorg.conf fine outside of that depth being required, it wouldn't be that hard i dont think to make the autoconfig logic just add that section for those two drivers [14:44] jcristau, you do have the kernel module's source [14:44] thanks for the help earlier [14:44] bjsnider: no i don't [14:44] just not the pre-built libs [14:44] no we dont [14:44] Sarvatt: yes, it should be easy to do that [14:44] and the kernel module is irrelevant anyway [14:45] they just have an open source shim interface to the actual kernel module blob [14:45] that's the wrapper [14:45] Sarvatt: adding hacks in autoconfig to work around trivial bugs in drivers considered harmful [14:45] but maybe that's just me [14:46] I think we all agree that certain things should be fixed in the driver [14:47] will all be moot with 1.10 where there's hopefully video xorg.conf.d support :) [14:47] however, if you want to get autoloading right with proprietary drivers, it's likely that hacks are needed [14:48] yes, that would definitely help [14:48] i guess that's why i couldn't care less about binary drivers [14:48] well the BusID thing is nasty, jockey is going to need to grow some logic to determine that [14:49] aticonfig --initial sets it up but it has to be run outside of X [14:49] Sarvatt: do you have a bug report about that? I'd like to report it to AMD [14:50] oh they know, its on the amd bug tracker [14:50] will try to dig it up [14:50] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587708 [14:50] Debian bug 587708 in fglrx-driver "[fglrx-driver] Driver crash after upgrade from 10-5 to 10-6" [Important,Open] [14:50] one of those 40+ page catalyst 10.6 threads on phoronix has bridgeman saying its intended that its required to run aticonfig after installing the driver always [14:51] haha [14:51] and we should be lucky it worked without it before :) [14:51] way to go there. [14:52] ouch [14:52] or should i say way to make radeon more attractive by the minute [14:53] http://ati.cchtml.com/buglist.cgi?quicksearch=busid [14:53] the debian bug points at http://ati.cchtml.com/show_bug.cgi?id=1848 [14:53] ati.cchtml.com bug 1848 in X Server "Without BusID fglrx crashes" [Critical,New] [14:55] oh yeah 10.6 is also broken with nforce chipsets [14:56] darn i dont see the main busid one on that list, guess i have to dig through phoronix [14:57] http://ati.cchtml.com/show_bug.cgi?id=1836 [14:57] ati.cchtml.com bug 1836 in X Server "xserver crash at startup with catalyst 10.6 on openSUSE 11.2/x86_64" [Critical,Resolved: fixed] [14:57] well theres another but nothing really in it [14:59] ok, I've sent them an email, hopefully we'll see what the current status is [15:00] resolved as fixed, really? [15:01] http://sarvatt.com/downloads/xserver.gdb.txt -- thats the backtrace I get without a BusID [15:05] looked like something i could fix on the server side to work around it but then i sold that box and stopped caring :) [15:19] bug status Opinion? [15:22] whee, that bug status closes all of the synaptics bugs just about then :) [15:28] Sarvatt: I'll take care of that fglrx bug. I'm not allowed to say more [15:28] woohoo! [15:33] :-) [15:39] haah not allowed to say more [17:29] :-) [17:30] Sarvatt, yeah I think there's quite a few bugs in xserver that could be closed with that [17:31] Sarvatt, the status is experimental and might go away in a few months if they find it doesn't do the job it's intended for [17:36] bryceh: remember the monster intel bug that led us to turn off automatic reporting? :) [17:36] heh [17:36] guess whats back because its not upstream and the patch was dropped? [17:36] oh no [17:37] ya upstreamed one that had an exact same hang dump as the monster one did :D [17:37] https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/603064 [17:37] Launchpad bug 603064 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i965gm] GPU lockup 77c6dfe5 (affects: 1) (heat: 8)" [High,Triaged] [17:38] i'm guessing g-p-m put his monitor to sleep while watching a movie in totem like what was happening before [17:39] mm, yeah good theory [17:40] oh hey btw Sarvatt, I got my upstreamer tool posted publically [17:40] upstreamer tool? [17:40] ooo! [17:40] Sarvatt, http://bryceharrington.org/cgi-bin/send_upstream.cgi [17:41] that's the tool I've been using all along to help me upstream bug reports, it's pretty handy. I've made it so it doesn't require my creds to run, so anyone can use it now [17:41] do you get to preview before it works its magic? [17:42] Sarvatt, I'd appreciate it if you would give it a test on one or two X bugs today or early next week; I'm hoping to get it more public once I've had a few people kick the tires with it [17:42] yep, it populates the bugzilla page so you can see what it'll do before committing anything [17:42] sure thing! cautious about doing it because i dont know what it does :) [17:42] ahh ok, nice [17:42] * bryceh nods [17:43] I'm interested to hear of any parts of it that cause fright, so I can de-fright them :-) [17:43] if you like it a lot, I also have a greasemonkey script which will automatically insert a link into bug pages, so it's really easy to launch into [17:47] bookmarked it and will give it a shot as soon as I get back, gotta run and powerwash a deck now though [17:48] * bryceh waves === apachelogger is now known as pythonlova [20:12] superm1: ping [20:12] jbarnes, pong [20:32] scared him away? :) [20:33] i guess intel-gpu-tools is a good candidate for a get-orig-source rule making a git checkout since its never going to have releases [20:33] drive-by jbarnesing [20:33] jbarnestorming [20:34] Sarvatt, never going to have releases? [20:34] that sounds dire [20:34] well they add new stuff to it all the time and anholt said he had no plans to release :) [20:35] O_o [20:35] Sarvatt: well you could bump it and call that a release [20:44] git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools && \ [20:44] cd intel-gpu-tools && autoreconf -v --install && \ [20:44] REVISION=$(git show --pretty=format:"%h" HEAD | head -n1) && cd .. && \ [20:44] PREFIX=intel-gpu-tools_1.0.2+git$(date +%Y%m%d)+$REVISION && \ [20:44] tar --exclude=.git --exclude=autom4te.cache -cf - intel-gpu-tools | gzip -9 >$PREFIX.orig.tar.gz && \ [20:44] rm -rf intel-gpu-tools [20:44] ^ that works for now for ppa updates at any rate [20:46] had to do the same thing for rendercheck packaging since that never has releases either