[08:31] tjaalton: -intel merge: http://people.ubuntu.com/~bryce/Uploads/ [08:32] tjaalton: also included a couple other patches. builds ok. would appreciate a review. I'll upload tomorrow. [08:34] bryce: why not merge 2.3.0 from experimental?-) [08:34] and could we finally drop i810 [08:35] tjaalton: in part because I want to get 2 patches validated that I'm looking to backport to hardy [08:35] no-one uses intrepid.. [08:35] heh, I do! [08:35] so using hardy-proposed is a better way imho [08:35] (well, for my test box) [08:35] ah ok :) [08:36] the one patch is already in hardy-proposed [08:36] the packages don't have to be in sync between intrepid and hardy-updates [08:36] also, I think for 2.3.0 we'll be dropping a lot of patches [08:36] sure [08:39] tjaalton: also I got word that 2.3.1 is coming out very soon; perhaps that's the one we should merge. [08:39] ok [08:40] anyway, doing a merge to get one patch in hardy is maybe overkill :) [08:41] and probably will get turned down [08:42] actually the reason I'm doing a merge is because I tried doing a regular upload of the patch, and got a reject due to md5sum issues, and I'm guessing the merge needs to go through first [08:44] I think it's because -2ubuntu13 is not yet in -updates [08:44] hm no [08:44] you should be able to upload ubuntu14 [08:44] to -proposed [08:45] er, I meant -1ubuntu13 and 14 [08:45] no, I mean I wasn't able to upload to intrepid. I was able to upload it to hardy-proposed [08:45] ah ok [08:46] do you have the error message [08:46] ? [08:46] yeah [08:46] Rejected: [08:46] MD5 sum of uploaded file does not match existing file in archive [08:46] Files specified in DSC are broken or missing, skipping package unpack verification. [08:46] it's rather obscure what the problem is. I tried redoing it from scratch 2-3 times, exact same error. [08:47] eh, perhaps it's all not worth the bother. [08:47] you tried to upload -1u13 to intrepid? that would fail yes [08:47] oh? why would it fail? [08:48] because it's there already :) [08:48] hmm, I could swear I'd checked [08:48] only that the pocket is hardy-proposed [08:48] you uploaded it :) [08:48] oh [08:48] feh! [08:48] you should use different versioning [08:49] like if intrepid had -1ubuntu1, then to get that in hardy you'd upload it as -1u1~hardy1 [08:49] like -1u12.1 ? [08:49] that's another way yes [08:49] but merge 2.3.0 and be done with it for good :) [08:49] yeah [08:49] although not for the reasons I'd assumed ;-) [08:49] then when 2.3.1 is released it's easy to re-merge [08:50] yup [08:50] so, apart from some patches, there shouldn't be any other changes that we need [08:50] libpciaccess should be pushed to main though [08:51] well, I'll do -2ubuntu1 first, just to get all the patches together and since I have it ready, then work on 2.3.x next [08:51] yeah we definitely need to put a priority on that [08:51] ok, the merge looks good [08:51] is 19_check_exa_pitch_to_fix_rotate_crash.patch from upstream or your head?-) [08:52] (didn't look in the diff, just .changes) [08:52] upstream [08:52] ok cool [08:52] but it's not one I'm super confident about. Probably ok for intrepid but I wanted more testing/verification before putting in for hardy [08:54] yep [09:09] uploaded [10:18] i'm guessing intrepid will likely have xserver 1.5? [10:18] yeah [10:19] i'll upload a new xorg-server rev today, rebased against the latest server-1.4-branch, fwiw [10:24] (but first i need the new xtrans) [10:25] jcristau: it builds against mesa 7.0.3? [10:25] tjaalton: "it"? [10:25] the server [10:25] 1.5 doesn't [10:26] ah so you don't have packages yet, only the tree? [10:26] I'm just confused :) [10:26] i have packages in experimental, built with --disable-glx --disable-dri --disable-dri2 [10:26] :) [10:27] right, remember seeing those [10:28] but there's a good chance lenny will release with 1.4 anyway :/ [10:28] is it still planned for sep/oct? [10:29] something like that [10:29] in that case 1.4 is definately a safer bet ;) [10:29] yeah [10:30] although so does intrepid, but we've decided to push the envelope with it :) [10:31] 1.4 is getting boring [11:32] hmm. still shipping the old i810 driver? [11:39] yes. [11:39] for testing.. [13:07] yay, pixman synced.. that was fast [13:21] How does Screen Resolutions applet get it's mode list ? [13:22] it uses xrandr [13:22] How does Screen Resolutions applet or X server get it's mode list ? [13:22] the X server gets it from the monitor [13:22] okay. xrandr is wrong in detecting modes for my monitor [13:22] kahrytan: log? [13:22] and xrandr gets it from the X server [13:22] What log? it's a GUI app [13:23] the X log [13:23] kahrytan: the xserver log, /var/log/Xorg.0.log [13:23] So [13:24] kahrytan has reported this issues as bug 220952 [13:24] Launchpad bug 220952 in mandriva "X Support and Config needed for Viewsonic VA1916W" [Unknown,Confirmed] https://launchpad.net/bugs/220952 [13:24] X in Hardy is bugged. [13:25] It doesnt know how to detect my monitor. [13:25] nvidia blob [13:25] It has nothing to do with nvidia [13:25] how so? [13:26] I have tried with NV, Nvidia and without either. [13:26] no logfile on the bug [13:26] please attach one [13:26] tjaalton: http://launchpadlibrarian.net/14028337/NV_Output_Xorg.log [13:26] You want one w/o the nvidia/nv use [13:26] oops [13:27] no xorg.conf though [13:27] and, that's not the full log [13:27] please attach both [13:27] xorg.conf is messy [13:27] then remove it and try again [13:28] and attach the log from that [13:28] How [13:28] safely [13:28] move the xorg.conf aside and restart the server [13:28] it will generate new one from default? [13:28] mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak; /etc/init.d/gdm restart [13:28] or something [13:29] It wont use NV/Nvidia will it? [13:29] it will use nv [13:29] it should use nv [13:29] should, yes [13:29] NV doesnt do OpenGl [13:30] you don't need 3d to test this [13:30] i know [13:30] brb [13:42] Xorg.conf didnt regenerate on it's own [13:42] no need to [13:42] the server autoconfigures itself [13:42] but it doesnt create the file [13:43] no, it doesn't [13:43] So no need to attach [13:43] the log... [13:43] need to attach the full log [13:43] (if there is still a problem) [13:43] X uses NV driver? [13:43] just attach the log and we'll see [13:44] it detects your card and uses the best match [13:44] falls back to vesa [13:44] if no better alternative [13:45] It must rely on NV for modes [13:46] please. attach. the. log :) [13:47] i know NV detects cuz log says it [13:48] https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/220952 [13:48] Launchpad bug 220952 in mandriva "X Support and Config needed for Viewsonic VA1916W" [Unknown,Confirmed] [13:48] reading [13:50] what does 'xrandr' on the terminal say? [13:50] kahrytan: so the problem is that when you start some games they change the resolution and end up with something the monitor doesn't like? [13:50] DDC did a crappy job at detecting [13:50] jcristau, Yes. [13:52] tjaalton, attach that too? [13:52] yes please [13:52] i did turn nvidia back on though [13:52] sigh [13:53] cuz gnome was slow w/o it [13:53] Nvidia does the same in detecting when in verbose mode. [13:54] does xrandr -s 800x600 work? [13:57] jcristau, thank you for that great suggestion. I had to reboot [13:58] then try with nv [13:58] so we can blame nvidia :) === kahrytan_ is now known as kahrytan [13:59] lol [13:59] Please, no nvidia bashing [14:00] why not? take a look at the bugs against linux-restricted-modules* [14:00] How do I reset xrandr to good rate ? [14:01] Because it is not very uh.. ubuntu thing to do. [14:02] which? [14:02] damn [14:07] Im back [14:07] Ive tested xrandr -s 800x600 w/o nv and with it. [14:08] tjaalton, jcristau; guess the verdict [14:08] everythin works like a charm? [14:08] x likes to use the lowest rate for resolution. [14:08] g [14:09] 56Hz? [14:09] Lowest for NV is 56 [14:10] It worked with NV/non-NV [14:11] And Nvidia does list 56hz [14:12] X forked nvidia reports. [14:14] Hello? [14:14] No talkers? === jw2328_ is now known as james_w [14:14] work [14:15] what do you mean "It worked with NV/non-NV"? [14:15] yeah [14:15] NV does say 56, Nvidia does say 56. [14:15] X just does 56 for NV and not for Nvidia. [14:15] so with nv 56Hz works? [14:15] yeah [14:16] so nvidia bug [14:16] no [14:16] X bug [14:16] explain why [14:16] cuz it's obviously not using 56hz for Nivida [14:16] uh [14:17] f*ck [14:18] How do i tell xrandr to use a specifix rate? [14:18] man xrandr [14:19] but nvidia doesn't support randr-1.2 [14:19] so I don't think you can specify the rate [14:19] or maybe it is that kind of bug [14:19] nvidia not supporting new version of xrandr? [14:19] if you change the driver and it then fails to work -> driver bug [14:20] yes, that's how it goes in the proprietary world [14:20] they lag behind [14:20] Not lag [14:20] nv doesn't support it either, except for G8x chips [14:21] Nvidia will eventually open up [14:21] when others do the same [14:21] others already did [14:21] I hear ATI hasnt really [14:22] kahrytan: look, I adminster 300+ desktops which use nvidia, so I know the driver is not perfect [14:22] +i [14:22] you hear weird stuff [14:22] Does the driver for ati suck ? [14:22] fglrx certainly does [14:22] every driver sucks for some hardware, sure [14:22] Who makes that driver? [14:24] fglrx? ATI/AMD [14:24] And wheres the oss one? [14:25] I blame xrandr for breaking nvidia [14:27] no, if nvidia can't do 56Hz then it's nvidia bug [14:27] bug reassigned already [14:27] back to work-> [14:27] does X uses xrandr for changing resolutions/rates? [14:28] tjaalton, answer? [14:30] does X uses xrandr for changing resolutions/rates? [19:52] * bryce reads backlog - tjaalton erf that looked painful [19:53] tjaalton: anyway I agree when 2.3.1 is merged that would be a good time to finally turn off i810. We should probably also put a priority on upstreaming all the remaining 8xx bugs in our tracker