=== marcog_ is now known as marcog === yfoel is now known as yofel [12:34] I can reliably trigger ttm_bo_validate to return ENOMEM on Radeon; any ideas how to debug - I assume something is asking for a stupid size [13:23] RAOF: Sarvatt: one question. what happened to the EGL texture pixmap KHR extension we had in your package at some point? [13:24] or did we never add it there [14:08] asac: guessing you're talking about mesa? it's there - EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenVG [14:08] EGL extensions string: [14:08] EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image [14:08] Sarvatt: is that in your ppa? [14:08] someone from our graphics group complained that after upgrade it was gone [14:09] * asac has to restart bbib [14:16] Sarvatt: back for a bit ;) [14:17] unity didnt start here :(( [14:19] asac: no not in a PPA, libegl1-mesa-drivers 7.9~git20100924-0ubuntu2 [14:19] Sarvatt: ah ok [14:20] what's wrong? [14:20] well [14:20] not sure [14:20] someone said he was running your ppa and now he doesnt have the extension anymore [14:21] but most likely he ran my version which now got superseded in your ppa or so [14:21] just guessing here [14:21] as long as its in archive its ok [14:21] you might want to include all the gles etc. goodies in your ppa at some points [14:21] I am :) [14:21] since august [14:23] Sarvatt: so why is that extension not in your ppa? ;) ... or maybe its missing in the headers? [14:23] which ppa? xorg-edgers? [14:23] hm [14:23] * Sarvatt has about 20 ppa's with mesa in it [14:24] but there shouldn't be any missing that extension [14:24] heh [14:25] ok so you say xorg-edgers has it now? [14:25] and main archive? thats good enough [14:25] thanks [14:25] * asac tries unity one more time ... stay tuned [14:42] ricotz: so, should I add a Recommends: ia32-libs-mesa-dri-experimental [amd64] to edgers libgl1-mesa-dri-experimental? [14:44] Sarvatt, did you talked to YokoZar? [14:45] nope just went over the logs in ubuntu-devel where you guys were talking, sounds like its appropriate in edgers for now at least until the archive one catches up [14:45] it might be more convinient to have this Recommend [14:46] yah thats what I said :) [14:46] then do it ;) [14:46] so its automatically installed when you install it [14:46] okie [14:46] i wasn't sure if you guys were renaming the package or anything [14:47] ia32-libs really needs better versioning :) [14:48] yeah, the date should be updated, but they might want to keep in sync with debian [14:48] i mean the date string in the version [14:49] yeah, 20090808 is silly since its been completely refreshed so many times since then [14:50] right [15:40] mvo: can you remove nvidia-173 from your blacklist, please? We have a driver that works now and there's no need to migrate users to nouveau [15:42] Sarvatt: seen 644943? [15:42] * Sarvatt looks [15:43] first guess - http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=69d65f9184006eac790efcff78a0e425160e95aa [15:44] i'm seeing the same thing in gnome-terminal and xchat with 2.12 with compiz enabled and its fixed by that [15:44] sounds quite plausible. [15:45] i guess the ones reporting it from nvidia could have a similar bug there. [15:50] thanks for the heads up, was about to look for bugs with that exact same issue to ask for testing since i've only reproduced/fixed it locally [15:52] tseliot, mvo: see the end of http://paste2.org/p/1016479, could the missing file be the reason why jockey doesn't create an xorg.conf for the user? [15:54] tjaalton: it could be but that's not really an error [15:54] tseliot: maybe it is for jockey [15:55] tjaalton: yes, let me check the code [16:01] tjaalton: is the package correctly installed? [16:03] tseliot: knittl reported it yesterday, so maybe he knows better :) [16:04] I'll leave you to it, need to run -> [16:04] ok [16:05] so I've got 2 x-x-v-intel patches that need to go through the SRU process, would it be better to target 2 separate uploads or batch them together? one of them is extremely safe - http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8784c4f5a1524fb979b00c7ce7981cbc1dcf0ec0 [16:06] tseliot, i was saying yesterday that according to the postinst script, that error is expected in i386 [16:07] bjsnider: yes, and it doesn't cause dpkg to fail [16:07] right at the end of that pastebin it just says it failed and doesn't specifically say why [16:07] hence I find it hard to believe that it can cause that failure [16:07] i was saying the same thing yesterday [16:08] good [16:44] darn, that x-x-v-intel commit doesn't fix xterm, just gnome-terminal and xchat [16:49] the xchat one with compiz is *very* annoying, fonts resize themselves and disappear at will [16:49] http://sarvatt.com/downloads/xterm.png [16:50] shiny [17:09] xterm problem is still there on master of everything except server 1.9 branch, couldn't be that easy of course [17:33] tjaalton: hm? i was afk [17:45] knittl: tseliot left already [17:53] hm ok [17:54] maybe I need to upgrade my box to see if I can reproduce it.. [17:59] jcristau: are you guys seeing the xterm problem on intel in debian too? [18:00] not afaik [18:00] the reason i saw that bug is i'm subscribed to xterm lp bug mail :) [18:00] Sarvatt: is that just typing or moving back and forward? [18:01] with xterm its just typing, and it goes away on its on if you let it sit or move the window [18:01] Sarvatt: Hmm seems fine here on 945GM [18:02] i can reproduce it [18:02] in xchat/gnome-terminal on 945 i'm getting fonts disappearing or moving around with the inconsolata font at 10 with slight hinting without the patch I pushed to git [18:02] * penguin42 is on the 'default' font whatever that is [18:06] is 'ttm' an allocator for memory on the card itself? i.e. if it's saying ENOMEM is it complaining aboutmemory on the card rather than system? [18:20] ok the xterm problem might be a compiz problem it looks like, can't reproduce with compiz from git [18:20] and if it's not in debian it's somewhere between 0.8.4 and 0.8.6 or in one of the patches we carry [18:26] could be an xserver 1.7 vs 1.9 difference, too? [18:29] * Sarvatt checks on a f14 livecd [18:34] anyone around in here using xorg-edgers on lucid with an intel GPU by any chance? :) [18:35] if so could you launch xterm and type a bunch of characters and see if you get any corruption around them? [18:42] Sarvatt: Sorry, my machines are upto Maverick [18:43] Sarvatt: Question; The 945GM's 2048 horizotnal limit, is that a hard limit or are there some combinations that it lets it go wider? [18:44] you can go up to 4096x4096 if you don't use compositing, but you'll lose Xv and such as well [18:44] Sarvatt: So when does the GUI stop you doing that; I see two bugs people saying the GUI won't elt them put the monitors side by side, one of which says it worked in Lucid (bug 654515 and bug 651994) [18:44] Launchpad bug 654515 in xorg (Ubuntu) "Dual-head setup only possible with stacked screen combination (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/654515 [18:44] Launchpad bug 651994 in gnome-control-center (Ubuntu) "Dual-monitor possible with top-bottom screen configuration only (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/651994 [18:46] it stops with a black screen if you try to change it after compiz is already started because it isn't smart enough to disable compiz after the fact when it resizes [18:47] It looks like in that case though something is limiting it to 2048 [18:50] Sarvatt: It seems reasonable for it to stop them going above 2k horizontal [19:39] hmm, if i run xterm inside of an xtruss trace I can't reproduce it either [19:53] looks like Mobility 9600 really isn't very happy with modeset [19:58] penguin42, ttm is supposed to manage graphics ram, not system ram [19:59] bjsnider: Hmm ok, that makes sense - so getting out of memory from it is slightly less surprising than if it was system memory [19:59] bjsnider: But still, it's a bit unfortunate [19:59] how much graphics memory does that thing have? [20:01] intel gfx uses a portion of the main memory [20:01] bjsnider: 512MB, although I think only 256 is mapped via PCI [20:02] bjsnider: I can reliably trigger the ttm code giving -ENOMEM using google maps in chromium on KDE with desktop effects [20:03] tjaalton, i didn't think intel chips had any discreet graphics ram [20:03] (this is on Radeon) [20:04] (and why the heck did .Xauthority move?) [20:04] because gdm [20:04] ok, missed that line then :) [20:05] jcristau: Is there a standrd right answer as to how people are supposed to connect to an existing X display if they ssh in ? [20:13] penguin42: make gdm not be stupid :/ [20:15] is there a reason why gdm started doing it this way? I just had someone asking aobut how to get x11vnc going, and there isn't a simple answer [20:15] no idea [20:26] a mobility 9600 with 256/512MB vram? no way.. [20:27] most of those had 64 [20:27] sure you aren't looking at the GART size? [20:29] Sarvatt: No, mine is an HD4350 with 256/512 - the 9600 was a separate thing [20:29] oh sorry [20:30] Sarvatt: The Mobility 9600 is I'm seeing people who need nomodeset for it [20:30] doing 10 things at once and misread [20:34] if there are a couple of bugs assigned to linux that are in the intel drm code should they be tagged or marked in some particular way? [20:37] "`xorg-needs-kernel-fix`This is an xorg bug which is dependent on a kernel patch" is the closest thing really, but thats more for bugs against X packages that are really in the kernel [20:39] ok, was just looking for a way to flag it to the guys who knew - I've added the function/offset to the title of both of them [20:40] if you have a backtrace it helps a lot to put that in the subject of the bug somewhere so we can find it with a search [20:42] Sarvatt: Yeh, I've got 3 of them all that are in intel_release_load_detect_pipe+0x21 [20:43] null pointer dereference? [20:43] lucid stock kernel or maverick? [20:43] i've seen a few of those but haven't seen the fix [20:44] maverick stock; actually I think there are about 6 of them [20:46] http://bit.ly/cHVm7a that's all 7 === yofel_ is now known as yofel [22:59] Sarvatt: You'd do both patches (and any follow up patches needed for that flush commit) in a single SRU. Which might fix multiple open bugs. [23:23] RAOF: ahh ok, I was thinking about reverting that and trying to get the sandybridge fix through since the bugs referenced in the changelog aren't actually fixed by it. darn xterm having a different problem than gnome-terminal and xchat [23:24] Who uses xterm, anyway? :) [23:25] gotta find other bugs (or report them *gasp*) for the other compiz text rendering problem if anything :) [23:26] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8784c4f5a1524fb979b00c7ce7981cbc1dcf0ec0 doesn't work [23:26] Da da daaaaaaaa! [23:26] gstreamer-properties still tries to auto select Xv [23:26] Is there an overlay adaptor available? [23:26] I mean, that just disables the textured video port. [23:28] device says unsupported in both cases and there are no options for textured or overlay, the one i pushed to git actually works though :D [23:29] And gstreamer-properties doesn't auto-select Xv in that instance? [23:29] rebooting into the upstream intel to see what xvinfo says [23:30] nope, xv is disabled completely and it doesn't hang, with the upstream one it hangs still playing a video in totem with autoselect in gstreamer-properties [23:31] Yay us, I guess. [23:34] I just used parts of what was in the bug report referenced in the commit, they probably didn't want to add the whole xvideo option back to the driver but i'm grabbing some info now to add to the report about how it doesn't work [23:34] what do you guys think about putting http://lists.freedesktop.org/archives/intel-gfx/2010-October/008286.html in for an sru? [23:35] http://lists.freedesktop.org/archives/intel-gfx/2010-October/008299.html [23:35] (I suspect it wouldn't pass sru team review, but figure it needs asked) [23:38] it'd be nice but i think its a big stretch personally [23:40] I think it'd be pretty hard to argue that adding support for monitor hotplug events is a bugfix :) [23:40] * penguin42 is now curious, something does happen automagically on monitor hot plugs - so what does that change? [23:44] Fair question. [23:45] I thought gnome-settings-daemon was watching udev & doing stuff, but that doesn't appear to be the case. [23:46] (especially because I keep meaning to file a bug to say that the default behaviour is not flexible enough since it always appears on the wrong side of my laptop!) [23:47] penguin42: Come to UDS (or participate remotely)! We'll be having a “what to do with multihead” session at some point. :) [23:48] * penguin42 might be able to do some of those, they're evenings for me [23:50] RAOF: Relaly wants it to remember particular states for particular monitors; e.g. if I plug that monitor in then it goes on the left, if I plug that one in it's a projector and .... [23:50] gnome-settings-daemon _should_ work there; it does for me™.