[00:00] i'd quite like to see a 2 month delay where people actually keep the packages frozen so it can stabilize :) [00:00] Sarvatt: come join the other side. [00:00] I didn't say 12 month! [00:01] :) [00:01] ;) [00:23] is xserver 1.8 has a solution to the Poulsbo cards ? [00:24] no, quite the opposite [00:25] you want to stick with older releases if you want to use poulsbo because they only ever put out drivers for the older releases [02:09] Sarvatt: Next time you roll a lbm-nouveau for xorg-edgers could you add http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blobdiff;f=drivers/gpu/drm/drm_edid.c;h=7e608f4a0df95563e81e40d3efbaa57903fadbba;hp=f97e7c42ac8e1f7bdf53573e491feb0a80f2989f;hb=44fef22416886a04d432043f741a6faf2c6ffefd;hpb=725398322d05486109375fbb85c3404108881e17 to the drm? [02:19] uploading now [02:20] Oh, that was quick! [03:07] Well, there we have it. [03:10] gallium nvfx, while it seems to have improved compiz speeds considerably, hasn't prevented nouveau from locking up waiting for gem. [03:26] try NOUVEAU_VTXIDX_IN_VRAM=1 compiz --replace? [03:27] What is *that* meant to do? [03:27] http://cgit.freedesktop.org/mesa/mesa/commit/?id=3428a305150e98c8002e0fb339f5667c5533c0d1 [03:30] Hm. I don't think that's what I'm seeing; my problem is X becoming unkillable while waiting in gem_something_or_other_cpu_init [03:51] radeon external monitor flickering bug, didn't someone here have that problem? superm1? - http://bugs.freedesktop.org/show_bug.cgi?id=25741 [03:51] Freedesktop bug 25741 in DRM/Radeon "[R600/KMS] external display flickering" [Normal,Resolved: fixed] [03:51] Sarvatt, external monitor doesn't work at all for me with radeon kms [03:52] at least not when X starts [03:55] ok will try to see if I can dig into it more, working on a list of drm patches we need to send to the kernel team list. did you have a bug or can ya tell me the GPU generation? how is the external monitor connected? [03:55] Sarvatt, i haven't file a bug yet. let me check the GPU info [03:55] it's in a port replicator, hooked up via DVI [03:56] lets see, how do i translate this to a generation? 01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80) [03:56] can ya get the pci id? [03:57] 1002:4e54 [03:57] RV350, thanks [03:58] er wait, i think i see something really weird going on that might explain things.. [03:58] http://pastebin.com/Y3TLzChg [03:58] does that mean it's trying to use VESA? [03:58] Yes. [03:58] yeah.. [03:59] Is modesetting enabled? That's (a) not going to end well, and (b) be resolved with the recent vesa upload. [03:59] -radeon is installed though [03:59] can't open the ati driver [03:59] i wonder if on the upgrade it decided not to pull in -ati though, i didnt realize they were separate packages, didn't even think to check that [03:59] Or, rather, given the rest of that log, will result in X failing entirely 'cause it can't open the ati driver or the fbdev driver. [04:00] do you have xserver-xorg-video-ati installed? [04:00] yah that explains it [04:00] it appears i dont [04:00] Do you have xserver-xorg-video-all installed? [04:00] odd [04:00] i'm sure he doesn't [04:00] i had all sorts of upgrade problems on this box [04:00] it was a hardy->lucid jump [04:01] i've filed bugs where i could, but i'm certain that this is caused by some of the earlier ones that are resolved now [04:01] superm1, yeah I tried doing that on a box earlier this month and it was a PITA [04:01] ended up just wiping it [04:01] i salvaged this, but there was a lot of --force-overwrite and --force-depends going on [04:02] i should have waited on it i think [04:02] yep [04:02] hmm yeah thats a odd bug, theres no xserver-xorg-video-radeon in hardy, it pushed him from -ati to -radeon [04:02] yeah I ran into that one too with -radeon [04:03] xserver-xorg-video-radeon Replaces: xserver-xorg-video-ati (<= 1:6.8.191-1) [04:03] oh swell, no internal display now [04:03] let me get this fully upgraded to current packages and i should be able to at least file an accurate bug [04:04] can boot with radeon.modeset=0 to get it working to file the bug at least, thats pretty major [04:05] should xserver-xorg-video-radeon conflict as well as replace the old ati maybe? [04:07] i've got external display, so even if it's not fixed after the upgrade, i should at least be able to work off that for filing the bug [04:09] unless you were on the -15 kernel and it breaks both upgrading to -17 :D [04:09] don't you go jinxing me [04:09] luckily i'm on -16 though :) [04:19] i've noticed radeon users tend to have some crazy setups that are just asking for trouble, dvi to hdmi to hdmi switch to receiver to tv and such :D [04:21] haha [04:22] This is strange - like really really strange, twilight zone of strange. VGA ports have DDC buses, but sometimes for some reasons the BIOS says we don't and we oops - AMD mentioned bios bugs so we'll have to add quirks. [04:22] yay.. [04:22] Sarvatt: it's not in a ppa yet, but it'll happen today with the drivers [04:23] looks like the amd64 build of the new wacom failed [04:24] make[3]: *** No rule to make target `wcmTilt2Rotation.lo', needed by `wacom_drv.la'. Stop. [04:26] funny how 2.6.33's radeon seems less stable than 2.6.32 going by the bug reports, a lot of flickering screen or external monitor problems [04:27] Sarvatt, well it looks like i got my internal display back with the upgrade to -17, yay, no bugs necessary [04:27] theres like 15 commits queued up for 2.6.33.2 though [04:27] oh phew good to hear [04:28] glad because I couldn't find anything rv3xx specific [04:32] hmm, need to get breakfast before replying to the thread [04:43] Woot! While this box may claim it's a power supply it's really a graphics card so I can join you in the wonders of radeonland. [04:49] drives me nuts when people file bugs against xorg "well I have no idea what is causing my random bug, but I'll just guess and file against xorg" [04:50] Without using ubuntu-bug? [04:50] I mean I sympathize that it's hard to figure out what to file bugs against, but we're not a babysitting service and there's plenty of guides out there to help [04:50] no, he used ubuntu-bug [04:51] lp #544836 [04:51] Launchpad bug 544836 in ubuntu "Slow boot performance" [Undecided,Invalid] https://launchpad.net/bugs/544836 [04:51] probably a compiz or nautilus bug [04:52] I wonder if just running “ubuntu-bug” and getting the symptom-based reporty thing would have sent it somewhere more useful. [04:52] possibly [04:53] or maybe I'm just grumpy after doing my taxes this evening with a fussy baby screaming at the same time [04:53] :( [04:53] is vinagre something like vbox that has its own X bits? [04:54] It's a VNC server, isn't it? [04:54] yeah [04:54] I haven't ever played with it [04:54] interesting vbox *is* installed, wonder if it is causing a conflict [04:55] RAOF: you know, we could just do it with libpciaccess [04:55] if (pci_device_has_kernel_driver(dev)) [04:55] Sarvatt: For the VESA fun? [04:55] Or for framebuffer McGraw? [04:55] vesa fun without libdrm [04:56] What happens when someone runs nouveau with nomodeset? [04:56] RAOF bad stuff [04:56] in fact I tried that [04:57] just get corruption [04:57] I thought I tried that and it fell back nicely to something that didn't die... [04:57] It *should* fall back to vesa, and since nouveau hasn't programmed a mode that shouldn't cause flames to shoot from the GPU's eyes. [04:57] nv needs updating to check that too :D [04:58] in fact I wanted to ask - we don't have documentation on the X/KernelModeSetting page for un-KMSing -nouveau and going back to -nv [04:58] blacklist=nouveau [04:59] I seem to recall testing it at the sprint with alberto and it worked on that hardware, but the one with my tv attached was a no-go [05:02] i wonder if our fglrx works with xserver 1.8's video abi.. [05:04] ha [05:04] heck, why does nouveau even have the vgacon hook to work with nomodeset still in the first place [05:05] VESA drives my netbook as well as I could expect when nomodeset is passed [05:05] Sarvatt: Because people might want to use libdrm_nouveau directly without actually using the driver - CUDA type stuff. [05:06] does nv work RAOF? [05:06] Sarvatt: the video abi is the same [05:06] i dont mean with your patch, I mean with an actual xserver 1.8 [05:07] hmm no [05:07] abi changed a few times and i think they just bumped it once [05:07] it was changed yes [05:07] just a long time ago [05:07] thats when i dropped xserver master from xorg-edgers :D [05:08] ah it was in december, it touched the input and extension abi as well [05:15] Hm. Why does nv not try to drive the display? [05:18] Sarvatt: Yup. nv works, but for some reason will only load if I specify it in xorg.conf. [05:22] Sarvatt, gonna try running fix-titles on ati... [05:23] bryceh: did you make it not change already fixed ones? [05:24] just did [05:24] sweet! [05:24] hang on found one more issue... dryrunning again [05:36] hmm, need to get a diffstat from the backported patches.. seems like diffstat accepts multiple patches [05:36] as arguments [05:43] but it's not accurate [05:44] 39 files changed, 1348 insertions(+), 344 deletions(-) [05:44] minus the libudev which we already had [05:44] which is over 400 insertions [05:46] and of the rest 155 touch the manpage [05:47] *190 touch the manpages [05:51] sorry, 230 :) [06:13] will have to try a hardy-lucid upgrade this weekend and see if that ati/radeon problem is happening to everyone [06:17] oh mvo has logs, thanks google :) [06:20] Setting up xserver-xorg-video-radeon (1:6.12.99+git20100126.e5933fd7-0ubuntu2) ... [06:20] Setting up xserver-xorg-video-ati (1:6.12.99+git20100126.e5933fd7-0ubuntu2) ... [07:31] bryceh: you forgot to finalize the changelog [07:31] but I've done it now [07:36] uh [07:40] uploading the backport to my ppa.. [08:04] xserver, evdev and synaptics uploaded here https://edge.launchpad.net/~tjaalton/+archive/test [08:06] hmm, looks like evtouch doesn't have a proper hotplug udev rule currently [09:33] * Ng booted a lucid beta1 USB stick last night on a friend's new Vaio. It has a Core i5 and whatever the accompanying Intel chipset is... [09:33] *very* broken. the display had what appeared to be inverted colours, or at least very wrong, and the touchpad didn't work at all [09:35] It was a Vaio Z11X9E/B [09:36] doubt those are supported yet [09:36] but, lunch-> [09:39] I wonder if that sort of thing is worth an entry in the release notes [12:08] superm1: as regards your upload of jockey, I'm working on the fglrx handler and I'll re-enable it soon [12:09] sigh, the ppa build backlog is huge === libv_ is now known as libv [13:48] tseliot, what else needed to be changed other than the package name? [13:48] that should at least allow people to enable it now i'd think [13:49] nope [13:50] * tseliot -> phone call [14:26] Ng: that should be supported fine, try booting with blacklist=vga16fb? [14:26] not sure about the touchpad though [14:26] Sarvatt: I'm unlikely to be near the machine again for a week or two unfortuntaely [14:27] but I will try that :) [14:27] by then it should be fixed hopefully if that was the problem :) === _thade_ is now known as Alexia_Death === Sinnerman is now known as Cobalt [16:53] tjaalton: are you going to upload a new revision of mesa anytime soon? [16:59] tseliot: 7.7.1 should be released tomorrow [17:00] tjaalton: I was asking as I committed my fix in git and bug #248392 needs it [17:00] Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392 [17:01] that's an old bug, it can probably wait a few days?-) [17:02] or you upload now and shuffle the changelog in git [17:03] afk -> [17:07] tjaalton: no, I was just asking [17:53] Sarvatt, btw you'd signed up for the task to review patches in other distros... just wanted to check if you've had some time to do this and if so how it turned out? === radoe_ is now known as radoe === |Alexia_Death| is now known as Alexia_death_ === Alexia_death_ is now known as Alexia_Death_ === JanC_ is now known as JanC === BUGabundo is now known as BUGabundo_dinner [22:17] tjaalton, I'm looking at backporting the Xv changes for i8xx from 2.10 [22:17] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=2.10&ofs=100 [22:18] looks pretty self contained - the bits from Daniel Vetter between when 2.9.0 was released and before Eric started cutting out UMS bits === BUGabundo_dinner is now known as BUGabundo [22:32] Yay! One (class of) kms edid quirks seems dealt with upstream. [22:40] RAOF, kewl, are you flagging it for the kernel team to backport? [22:42] Yes. I'm not sure precisely how to flag the bug for maximum effect, though. [22:42] here's how: [22:42] a) tag it 'xorg-needs-kernel-fix' [22:42] I've heard there is a report they look at with these tagged bugs. dunno if that is still true but good just in case [22:43] b) nominate it for 'lucid' and set milestone to 'beta-2' [22:43] that should get it on the release team's radar at the very least [22:44] c) If you want to ensure it gets attention, also mention the bug to JFo on #ubuntu-kernel and ask he puts it in the kernel team's hopper [22:44] d) if it is extremely critical and you really don't want it to get lost, also assign it to one of the kernel engineers, like apw or sconklin. But this should be used only in really critical cases [22:45] I don't think it warrants that. [22:45] e) Raise the bug on the kernel-team@ mailing list. This is good for really earth shattering or highly risky things [22:46] for most bugs that I care for the kernel team to see I just do (a) and maybe (b) [22:46] and then (c) for important stuff [22:48] Thanks. [23:04] hmm, the Xv patch is pretty large [23:40] bryceh: i've got the xv changes in sid fwiw [23:54] jcristau, ah great