[05:56] bryceh: oh you took the task to send the patches upstream, nice :) [05:56] i just had a brief look at the remaining patches yesterday and spotted these two [05:56] bryceh: btw, you bumped the package revision of xorg-server ;) [07:32] Sarvatt, thanks for pushing the driver updates that fast [07:33] tjaalton, dch's fault :-) [07:41] don't use -i ;) [07:42] tut tut, use -i all the time [07:44] it already increments the version when the previous entry is finalized, so -i is rarely needed [07:46] huh [07:49] morning btw [07:50] bryceh: ahh, you need DEBCHANGE_RELEASE_HEURISTIC="changelog" in .devscripts [07:50] then it works properly [07:51] tjaalton, aha thanks [07:52] normally i just edit the changelog directly, but dch adds the multimaint-tags [07:53] yeah same [07:54] Moshi moshi. [07:58] so the big api change got merged in xserver master, and for 1.13 we might see some of the hotplug/offload functionality too [08:00] anyway, 12,5h until the meeting ;) [08:01] tjaalton: i think that's the default in recent devscripts fwiw [08:02] oh [08:02] not on precise anyway [08:02] I tested it now and noticed the difference [08:03] 2.11.6ubuntu1 [08:03] but makes sense [08:03] yeah changed in 2.11.7 [08:04] i've had to put it in .devscripts for years so i'm happy it's finally changed :) [08:57] could someone check https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1008864 please? it appears that for some users the python equivalent of glxinfo in software-center causes a full X crash on intel: python /usr/share/pyshared/debtagshw/opengl.py is what they run [08:57] Launchpad bug 1008864 in software-center (Ubuntu) "software center crashes when clicking pay apps" [High,Triaged] [09:03] mvo: doesn't crash here with sandybridge on 3.4 kernel, will try with the precise one [09:04] tjaalton: thanks, maybe some odd cnfiguration on the users system? [09:04] mvo: not necessarily, intel drm is in rather bad shape on 3.2 :/ [09:05] some fixes in -proposed [09:05] good to hear [09:05] (about the fixes, not the bad shape ;) [09:05] :) [09:05] and more being validated [09:11] mvo: still doesn't crash :/ [10:19] tjaalton: When's the meeting, again? [10:20] RAOF: 21:30 UTC [10:20] so, 10h from now [10:20] bit early for you, late for me ;) [10:20] slightly late [10:22] no too bad, the other night I was up until 3am+ playing infamous2.. [10:33] sweet, intuos5 backport works [10:33] lunch-> === yofel_ is now known as yofel [18:11] in 12.04 i have a Dell U3011 monitor with 2560x1600 resolution, but after fresh install i only see 1600x1024 as max resolution [18:12] how do I go about forcing 2560x1600 ? [18:13] which driver? [18:13] nvidia [18:13] nouveau i think [18:13] NVIDIA Quadro NVS 295 [18:13] check that it's actually being used and not vesa [18:13] tjaalton, how do I do this? [18:13] Xorg.0.log [18:14] where at? /etc/X11 ? [18:14] /var/log [18:14] /var/log ? [18:14] ok [18:14] brb [18:14] or 'dmesg|grep nouveau' [18:15] hmm if it's a fresh install then it should be used [18:15] thought there would be remnants of the nvidia blob [18:17] tjaalton, wonder how many reasons we could dream up for why a system would max out at a lower resolution. [18:18] bryceh_: :) [18:18] bet there's at least a couple dozen [18:18] there are many, but let's rule out the obvious ones first.. [18:18] like, kms disabled for one reason or another [18:18] tjaalton, most obvious being stray xorg.conf? [18:19] bcurtiswx: are you sure that your card has enough power, in other words it has the extra power cable attached? [18:19] I used to have such issues many times, damn hw builders [18:20] bryceh_: well, not if it's a fresh install, but yeah [18:20] tjaalton, not sure about extra power cord, it's a brand new build delivered yesterday from DELL [18:20] i don't think it would be underpowered [18:20] ahhhhhh [18:21] bcurtiswx, so it has proper resolution initially, but you wiped the Dell image and reinstalled, and now you don't have it? [18:21] tjaalton, i grep dmesg for vesa dn nouveau and VESA comes up with results while nouveau does not [18:21] s/dn/in [18:21] tjaalton, should we ask him for the Xorg.0.log, or would that be cheating like looking at the lid on the puzzle box? [18:22] i can get that for ya [18:22] heh [18:22] is there a way to send a text file to pastebin ? [18:22] pastebinit! [18:22] bcurtiswx: install pastebinit, then run 'pastebinit /var/log/Xorg.0.log' [18:22] ok brb [18:22] echo! [18:23] + [18:24] bryceh_, tjaalton http://paste.ubuntu.com/1027284/ [18:24] ah, -nvidia [18:25] use the nvidia graphics config utility thingee [18:26] ? [18:26] bcurtiswx: you have it hooked up via a single link cable it looks like [18:26] is that dvi or dp? [18:27] its a DVI cord plugged into one that looks like HDMI but it's not quite [18:27] if its dvi you need a dual link cable to use the full resolution [18:27] [ 33.660] (--) NVIDIA(0): DELL U3011 (DFP-0): Internal Single Link TMDS [18:27] ah yeah could be that too [18:28] you need an actual dual link dvi cable the whole way or to use displayport, cant do it over HDMI either [18:28] huh, that would not have been on my two dozen reasons list [18:32] would've been on mine :) [18:32] and it's using the blob [18:32] so not exactly fresh install [18:32] to the letter :) [18:33] i had a similar monitor for several years, and they're quite picky [18:33] those 2560x1600 monitors are pains in the butt [18:33] this 27" 25x14 is pretty nice [18:33] :) [18:34] oh ya got one? [18:34] if only it wouldn't turn off by itself several times a day [18:34] yeah [18:34] for two months now [18:34] samsung sa850t [18:39] bcurtiswx: err so [18:39] http://www.nvidia.com/object/product_quadro_nvs_295_us.html [18:39] says you need to use displayport [18:40] guess ya can get a displayport to dual link dvi adapter [18:41] or just use a dp cable [18:41] since the monitor has a dp port [18:41] bcurtiswx: if you're near woodbridge I can give ya a dp cable :P [18:41] OK, i hooked up a second cable [18:41] its one screen that Ubuntu sees as two [18:42] how do I make it work? [18:42] huh? [18:42] OK my monitor has TWO DVI hookups [18:42] and i have two DVI-DP connections [18:43] don't do that [18:43] tjaalton, then what shal I do ? [18:44] its the dvi-dp adapters that are limiting you to single link bandwidth [18:44] ya need a displayport cable [18:44] use either a displayport cable, or a dual-link dvi-cable with a dp->dl-dvi adapter [18:44] the cables like $5 vs a $50 dual link dvi to displayport adapter [18:44] yes, the cheap passive adapters only do single-link [18:44] i know, I have two :) [18:45] i have one cord that takes on DVI and splits it into two [18:45] one* [18:46] that what you mean? [18:46] no [18:46] dl-dvi is a cable that has all the pins connected [18:46] but that won't work either unless you have a proper dp->dl-dvi adapter [18:46] which is an active box with a power source [18:47] and costs money [18:47] well, more than the 15EUR a passive one is [18:47] maybe 50 [18:47] what ya need is something like this http://www.amazon.com/PTC-Premium-Series-DisplayPort-Displayport/dp/B001MIB0SU/ref=sr_1_1?ie=UTF8&qid=1339008125&sr=8-1 [18:47] i'm not sure if you have full sized displayport or mini on the gpu though [18:47] but ya said it looked like hdmi so probably full sized [18:52] bcurtiswx: aren't you in fairfax? http://www.microcenter.com/single_product_results.phtml?product_id=0308064 is the only one i can find for sale in a local shop [18:52] Sarvatt, yes i'm at GMU in fairfax [18:53] what's with that displayport to displayport hookup? [18:53] it's the best you can get [18:53] and cheapest [18:53] we have a cord with displayport on both ends [18:53] so use that [18:54] how? the card is displayport and monitor is DVI [18:54] the monitor has displayport [18:54] dell says it does at least [18:54] hmm, maybe i'm blind (wouldn't surprise me) [18:54] brb [18:54] it has a dp, two dl-dvi, two hdmi-1.3, vga.. [18:55] or it's not U3011 :) [18:55] bcurtiswx: right next to the orange audio plug [18:55] :) [18:58] it's right next to the DVI plug which we couldn't see the DP port without not being lazy [18:58] http://sarvatt.com/dp.png [18:58] thanks, gonna go switch that up [18:59] cool beans [18:59] that should "just work" [19:06] hybrid graphics is fun [19:06] I keep hitting the hard problems early :D [19:10] Sarvatt, bryceh_, Thanks :) I feel dumb, but It works and thats the important part [19:10] Sarvatt, I'm in Falls Church now === schmidtm_ is now known as schmidtm [20:31] meeting time? [20:31] bryceh_, mlankhorst, RAOF, Sarvatt [20:32] uh [20:32] 1h from now [20:32] sorry :) [20:32] didn't realize the uk time isn't utc during summer time [21:12] :-) [21:22] morning [21:22] di [21:24] Heh. [21:33] bryce, mlankhorst, Sarvatt, tjaalton: *Now* it's meeting time :) [21:33] finally === bryceh_ is now known as bryceh [21:35] wb [21:35] so [21:35] but yeah lets see *checks email* [21:36] lts first? [21:36] sure [21:36] mlankhorst, alrighty take it, where we at? [21:36] well the repository is up so I think at this point we just need to land the stack in Q first :) [21:37] I have been spending some time on upstream atm, helping airlied with his hybrid graphics work [21:37] ok, any outstanding issues aside from the uninstallation problem? [21:37] it's not going to be supported afaict [21:37] ok [21:38] so it's not that big a deal [21:38] we'll need to document it where appropriate, but guess we can consider that good enough [21:38] ok, next item was copying nouveau ddx [21:38] I think that's fine. anyone got concerns there? [21:39] well the support for that is in debian now, will still require 3.4 kernel [21:39] but fine for quantal? [21:39] And fine for the LTS backports, too; that's exactly why we depend on the lts kernel backport :) [21:39] mlankhorst, does current nouveau ddx *require* 3.4, or just that you don't get the latest functionality unless running 3.4? [21:40] bryceh: some fermi changes landed that will disable accel for fermi unless you have 3.4 [21:40] ok so yeah, quantal and ppas which depend on the lts kernel backport. guess that means not in x-updates ppa though [21:41] about that, what should be my focus atm? I've been helping airlied with his hybrid work on the nouveau side [21:42] that's fine [21:42] That seems valuable to me [21:43] mostly on the nvidiaside because i know it better :) [21:43] yeah, also bug reports filed against precise [21:43] about the backports; maybe drop -backport from the name to follow the kernel name [21:43] tjaalton, might wait and see what vanhoof finds out for name suggestions, but yeah [21:43] Has the nomenclature for those packages stabilised? [21:44] mlankhorst: there were some nouveau bugs filed against libdrm that I moved to -nouveau, so if you have some time to take a look that would be great [21:44] bryceh: right [21:44] RAOF, I think the kernel team JFDI'd [21:44] -lts-quantal [21:44] is what it has now [21:44] but hybrid graphics will require at least 3.5 [21:44] maybe 3.6 depending on synch support [21:44] we'll have it [21:44] 3.5-rc1 is already being prepared [21:44] ok, so next topic is hybrid gfx [21:45] and hybrid is still ways off :) [21:45] We might not have 3.6 :) [21:45] oops [21:45] xserver master now has the api groundwork for the new functionality [21:45] mlankhorst, I gather this is the main topic you wanted to see discussion on? [21:46] and airlied sent an email commenting on the 1.13 release schedule and what he might want to see happening this cycle [21:46] indeed :) [21:47] so, probably not all of it but output slaves (hotplug usb etc) and dri2 offload [21:47] tjaalton: Yeah I was helping airlied a bit by writing some tests for behavior, showing how nvidia hardware worked and help understand problem a bit later [21:47] and even fix a firmware bug [21:47] My email is being slow; was there a tentative date for 1.13? [21:47] september-ish [21:47] yeah [21:47] early sep [21:48] 4th [21:49] but maybe the patches for synching could be cherry picked [21:49] if it happens not to land in 3.5, it might not be that big depending on what intel hw supports [21:49] yeah cherry-picking is possible, at least if we know what to cherry-pick early on [21:50] Or we could feed that request to the kernel team; is 3.6 still looking possible, given appropriate motivation? [21:50] the specific changes will be small though [21:50] that decision is made mid-august or so? [21:51] so maybe I should rest a bit on coding on the hybrid stuff for now and only influence the decisions about it still being made [21:51] the synching will probably be done inside the kernel only [21:51] whatever is the latest is what's best for intel anyway.. has been the case for a long time [21:52] I'm sure haswell will work *swimmingly* with 3.5! :) [21:52] in any case I think apart from input to the linaro guys about this dmabuf stuff [21:52] that there's not much more I can do here atm [21:52] RAOF: ! :) [21:52] mlankhorst, could be, yeah [21:53] mlankhorst, do you have hybrid hw? [21:53] bryceh: just one laptop atm :) [21:53] mlankhorst, if not then yeah probably backburner it for time being and just follow discussion [21:54] but speaking of which I had to ask you about hardware so if you have some that looks interesting and maybe some radeon as well :) [21:54] I don't think hybrid is **so** important that it'd warrant doing a franken-drm for it [21:55] well we should be able to turn it off the proper way at least with the 1.13 changes [21:55] there's not much left in the drm left aiui [21:55] uh [21:55] i mean, turn off graphics card like raof's [21:55] Not much *more* to do in the drm :) [21:56] that [21:56] mlankhorst, what I tend to do is have a few PC boxes and random assortment of cards to mix and match. Especially for nvidia/radeon testing that's what I'd suggest [21:56] RAOF: Yeah the patches will probably be small though [21:57] especially since nouveau already has synch code in place [21:57] you can get a variety of low end video cards pretty cheaply; for most testing purposes those will be adequate, then once and a while pick up a high end card just for fun [21:57] bryceh: true, but what about radeon+intel hybrid? [21:57] Right. So, likely to be either cherrypickable, or another motivation to use 3.6. [21:58] mlankhorst, for that you'll need a laptop, and requisitioning one from pete is probably the least hassly way to do it [21:58] mlankhorst: tseliot should have those, and RAOF has one too I believe [21:58] mlankhorst: I'm not sure if the BIOSes support it, but you should be able to do radeon+intel hybrid on a desktop, too? [21:58] if we can get the synch changes in, it would be nice to have [21:58] RAOF: All the ones I have seemed to always disable intel. :/ [21:59] mlankhorst, magic words seem to be "I'm interested in broken hybrid graphics laptops that I can work on fixing" ;-) [21:59] hehehhe [22:00] mlankhorst, at uds we talked about the feasibility of replicating a hybrid box via a PC with onboard video + pci-e card, and sounded like it might be another thing to try out at least for some testing purposes [22:00] bryceh: yeah but it seems the card just disappears atm, if i had a less buggy bios. [22:01] mlankhorst, so, write up a request to send to pete. I can proof-read it for you ahead of time if you'd like. [22:01] sure [22:02] mlankhorst, ok anything else on hybrid? [22:02] nope, next topic? [22:02] SNA! [22:02] snaaaah snaaaah [22:02] RAOF, feel like switching it on now? [22:02] oh that's needed for hybrid btw [22:02] is upstream enabling it soon? [22:02] of course [22:03] because of Y-major tiling [22:03] sna's needed for hybrid? [22:03] tjaalton, I think it is already switched on by debian and we're forcing it off [22:03] * bryceh doublechecks [22:03] Only in experimental. [22:03] * RAOF merged 2.19 in last week. Or Monday. Or something. [22:03] right [22:03] RAOF: Probably going to be because of the blitter being braindead and sna actually using the 3d hardware for it [22:03] * No SNA for unstable, it's too fast of a moving target for now. [22:03] yeah I remember airlied mentioning that [22:04] The last thing I heard about sna from !ickle was airlied talking about corruption that a fellow RHer was seeing when they tried it. [22:04] he's not going to fix uxa :) [22:04] And ickle saying ?yeah, you need at least the very latest everything or I don't care? [22:04] hehe [22:04] "typical" [22:05] *sigh* [22:05] anyway, I would like to propose we switch it on now and kick the tires on it and make a decision prior to alpha-2 [22:05] So we could turn it on, and if we need it for hybrid and we *want* hybrid (which I think we do), then we should do so now and ensure we hit as many problems as early as possible. [22:06] oh btw for nouveau ddx i want to ask darktama first, after that it could probably be copied from experimental [22:06] if nothing else we can do the bug-forwarding-to-intel dance for a bit [22:06] not until quantal has 3.5-rc1 though? :) [22:06] and by we I mean me :-/ [22:06] or any 3.5-rc [22:06] rc1? optimistic [22:06] no i mean turning sna on [22:07] tjaalton, why? [22:07] oh sure [22:07] bryceh: it's closer to upstream than 3.4 [22:07] tjaalton, ah you mean for bug forwarding? [22:07] by the way no guarantee hybrid will be complete this cycle, if not definitely for next though :) [22:07] bryceh: yeah [22:08] Fortunately the synch changes are kernel only [22:08] mlankhorst: right, but we might get some of the features [22:08] tjaalton, *shrug* they always want us to have the user test against -drm-intel-next-experimental-not-yet-maybe anyway [22:08] so don't think waiting for 3.5-rc to hit is going to matter much [22:09] well, turn it on only after _some_ initial testing on quantal? :) [22:09] tjaalton, so maybe switch it on in edgers for a week and see if anyone cries uncle first? [22:10] sounds good. Sarvatt? [22:10] lgmt [22:10] lgtm* [22:10] lgtm? [22:10] ah [22:10] looks good to me [22:11] <- n00b [22:11] I'll give it a bash on my systems, too. [22:11] same [22:12] RAOF, you want the task of turning it on or shall I? [22:12] i'm still running precise, because of all the bugs [22:12] in precise :) [22:12] bryceh: I'll turn it on. [22:12] ok sounds good [22:13] next topic... speaking of bugs in precise... 8.0.3? [22:13] yeah, Sarvatt pushed the merge to git [22:13] last time we talked about it, thinking was we could maybe get the whole thing through SRU? do we want to try that? [22:14] sure, but it needs to get in quantal first, after alpha1 [22:14] was thinking if we did piglit runs on precise with and without it, and showed no regressions, it would help [22:14] That would indeed help. [22:15] I've got systems set up for doing piglit runs on the various drivers, so can take that part of the task [22:15] then maybe a meta-bug with the commit diff explained in detail, in order to dispel fears that it might look too scary [22:15] (damn wifi resetting all the time) [22:15] i thought the release team hated meta bugs? [22:15] sure they do [22:16] they do hate unexplained diff bits more though :-) [22:16] but since there are no other bugs to use.. [22:16] There are *no* existing launchpad bugs fixed by 8.0.3? [22:16] speaking of which can we SRU synaptics soon? [22:16] although based on past experience I tend to have low grokkage of mesa changelogs. would someone else be able to write that part up? [22:16] RAOF: probably yes, but don't think there are _verified_ bugs [22:17] tjaalton, is what sarvatt put in git good to go? Could I slap it in a ppa and expect it to build? [22:17] I would probably be able to do the metabug part, but I'm not sure if I'm the best person to do that. [22:17] if so, I could spam likely looking bugs to test it. [22:18] That sounds like a winner. [22:18] bryceh: it builds [22:18] It didn't crash when I logged in to desktop [22:18] (I didn't say anything about misrenders) [22:18] RAOF: heh, being on the sru team [22:18] RAOF, in the sense that you'd be the reviewer? [22:18] mlankhorst: That's not *quite* the level of testing we're hoping for on SRUs :) [22:19] RAOF: if you do it right you can do that with synaptics currently [22:19] :D [22:19] RAOF, in which case maybe it'd be better to have you write the meta bug and another SRU reviewer do the review? [22:19] bryceh: That would work. [22:19] RAOF, effectively giving the whole a double SRU review :-) [22:19] For added freshness! [22:19] okie doke, sounds like a plan [22:20] last topic, a few patches I noticed that need some actions [22:20] https://bugs.launchpad.net/~ubuntu-x-swat/+patches [22:20] #993427 - fglrx breakage with the kernel [22:21] oh do we care about vdpau? It's just going to excarbate the flash problem.. [22:21] basically needs tseliot to look at that one. I would do it myself but I'm not sure how we're doing git packaging stuff for fglrx now. anyone clue me in? [22:22] no idea [22:22] it's on github maybe [22:22] mlankhorst, bug #1002224 suggests we do care [22:22] Launchpad bug 1002224 in mesa (Ubuntu) "Please include gallium vdpau and xvmc driver support" [Wishlist,Triaged] https://launchpad.net/bugs/1002224 [22:22] nvidia & fglrx was on github last time I touched it. [22:22] bryceh: I mean, I understand vdpau and xvmc, and it's not that big of a win without hardware acceleration [22:22] mlankhorst, I +1'd it, and it looks good to me for sponsoring it, but wanted to run it by everyone else for sanity checking? [22:22] should we drop patch 610206 as silly? [22:22] i mean close bug 610206 [22:23] Launchpad bug 610206 in xorg-server (Ubuntu) "Build in input drivers for speed" [Wishlist,Triaged] https://launchpad.net/bugs/610206 [22:23] tjaalton, yeah go for it [22:24] RAOF, is tseliot cool with just having stuff pushed there, or does he actually want to review everything first? [22:24] I think we should, yes. [22:24] bryceh: I mean, it's not going to benefit anything yet. :/ [22:24] bryceh: I proposed a merge when I touched it, that seemed to work well. [22:24] mlankhorst, ah. is there risks for having it turned on? [22:25] mlankhorst: Doesn't r300/r600 have shader-based acceleration for at least some of vdpau? [22:25] RAOF, ok thanks, I'll give that a try [22:25] RAOF: for mpeg2.. in which case your cpu is fast enough to do everything [22:25] Heh. Of course! [22:25] and the bitstream processing is still done on software [22:26] I don't object to vdpau being turned on, though. If it breaks something it's simple to turn off. [22:27] i guess it could be turned on on the simple fact nvidia is even buggier because it's using overlays [22:27] Although obviously it should be wrapped by VAAPI [22:27] ? [22:27] RAOF: va-api is insane :P [22:27]