[00:00] Among other things I think that steam does some GL vendor string parsing and freaks out about gallium drivers. [00:01] The nouveau drivers would be pretty featureful, but significantly less stable. [00:01] And significantly less fast, too. [00:05] brb [00:08] right, where was I [00:08] oh yes [00:08] In Sacrifice? [00:10] heh [00:11] so in lucid [00:11] Cedega fullscreen being off by a couple of issues is likely to be either (a) cedega's fault or (b) a VGA connector issue. [00:11] and I just upgraded my games machine, so its new [00:12] when it goes fullscreen, most of the time, its offset to the bottom-right [00:12] *but the desktop shows in the gap* [00:13] Ah. Silly cedega. [00:13] worked in karmic [00:14] intels gpu's are such crap noone would buy a seperate card and they know it :) [00:16] And it turned out doing a GPU in software on top of a bunch of tiny x86 cores wasn't as easy as they thought, too. [00:16] Worked in Karmic, eh? [00:16] RAOF: this occurs with both i915 or whatever my laptop has, and the nvidia in my games machine [00:16] RAOF: and it was pixel perfect yesterday morning before the upgrade [00:17] what upgrade? [00:17] karmic-lucid [00:17] my games machine was shipped transtasmin so this was the first chance to do it [00:17] http://imagebin.org/100511 [00:17] RAOF: ^ [00:17] I think this is unlikely to be an X problem. [00:17] shows both the offset, and the other thing I wanted to query you on [00:18] Oh, a third thing? :) [00:18] yes [00:18] choosepixelformat failed [00:19] which google tells me was fixed in 2006 with glx1.3 [00:19] and glxinfo claims the nvidia driver is glx1.4 [00:19] whats particularly special is alt-tab to and from the fullscreen app aligns it correctly on the screen [00:20] I think google might be wrong, because the open drivers haven't been claiming glx1.3 support until… Lucid, until we disabled it. [00:20] well, I know that I know not, in this space. [00:20] I'm going to get a vanilla wine install of steam up [00:21] and see if its better [00:21] yeah that'd be the first thing i'd try too [00:21] though that itself appears to be black magic [00:22] ? it installs fine here [00:22] i'm in the process of installing counterstrike now in it [00:24] pretty sure you can just use the cedega one too since its just wine [00:25] blows up when I run regular wine on it [00:25] with WINE_ENV or whatever set [00:25] cleaner to start fresh, I think [00:28] looks like wine with the blob starts things at 60hz when it changes resolutions [00:28] the blob lies about what refresh rate you're at for its twinview crap [00:29] try adding Option "DynamicTwinView" "false" to your xorg.conf? [00:30] found an old forums post from 07 with the same problem it looks like - http://ubuntuforums.org/showthread.php?t=629173 [00:30] I'm in awe of your googlejuice [00:31] wine fullscreen xserver 1.7 found it :) [00:31] ah [00:31] thats for the offset thing, not the pixel format [00:31] right [00:33] looks like disabling compiz will fix the choosepixelformat error [00:34] I have visual effects set to None already [00:35] I thought that disabled compiz ? [00:35] oh, darn :( [00:36] http://forums.steampowered.com/forums/showthread.php?t=1282981 [00:37] looks like it picks directx mode by default and that switched it to opengl so it works [00:38] that screenshot was set to gl mode :) [00:38] d3d mode goes boom [00:39] I'm pulling down cs in a fresh wine setup [00:39] will report back in a couple hours I guess [00:40] for now, bzr stuff awaits [02:17] intel needs a rebuild :( looks like the server was stuck in NEW [02:18] Provides: xserver-xorg-video-6 [02:43] RAOF: so, lucid wine does a bit better [02:43] Sarvatt: the twinview thing helped [03:34] I'm trying to use ppa-purge to downgrade xorg-edgers to default maverick, but I'm having some kind of dependency problem with xserver-xorg-core and the virutal input packages. [03:36] Sarvatt: ^ [03:36] ripps: Yes, you will. Not everything's built for the new server yet. [03:37] RAOF: ah, okay. Any idea when they'll roll out? [03:37] Today. [03:42] RAOF: cedega is still naffed :-) chalk one up for open sores [03:43] Heh. [04:08] RAOF: now, just have to remove pulseaudio and everything should be happy again [04:47] Ok. Weirded out by that mesa backtrace. === lifeless_ is now known as lifeless [09:12] I have a very strange bug indicating gdm starts too early in upstart on lucid resulting in low graphics mode with nvidia-current installed via jockey... [09:15] This is very irritating for people installing the suggested nvidia driver via jockey and on next reboot they get "ubuntu is running in low graphics mode" error message... [09:16] ntr0py, http://ubuntu.com/support [09:17] To avoid the effect of this issue it is enough to delay the start of gdm for only 2 seconds on my system, but it leaves the causes (upstart race) untouched... [09:23] bryceh: What should i do with your url?? [09:25] ntr0py, if your interest is merely in getting your machine working with lucid, there are plenty of support channels to go through. This is a development channel. [09:28] bryceh: I do have a working machine with a the dirty hack avoiding the effects of this issue (delaying gdm start), but i think this is a bug in upstart (race condition). [09:30] then analyze it fully and submit a bug report (and perhaps a patch against the upstart rule if you're conversant in upstart) [09:32] however you might check if it's just that the nvidia kernel module didn't finish building before gdm tried to start X, which is already a known issue. [09:33] patches definitely welcomed on that one, as the number of developers who support the proprietary driver is pretty limited. [09:33] anyway, nite. [09:33] bryceh: Good night! [09:34] bryceh: I did analyse it finding out the hack and tried adding something in /etc/init/gdm.conf ("and graphics-device-added nvidiactl PRIMARY_DEVICE_FOR_DISPLAY=1"), but unfortunately im not familiar enough with upstart to do this... [09:34] ntr0py: Something like that would be the way to do it, yeah. [09:34] * RAOF is also off. [09:38] Any ideas how i could wait with gdm's start on nvidia module having build and beeing ready for use in upstart? [10:16] the current intel driver got built with the old xserver [10:16] should it be rebuilt to get the new abi? [10:17] yes. [10:17] is there a list of things that need to be rebuilt still somewhere? [10:18] jcristau, do you know if the rebuild is hold off for a reason or if I should just do a no change upload for it? [10:19] don't know of a reason you should hold off [10:20] ok thanks [10:20] I will let a bit for somebody to comment if there is a reason or do an upload in an hour otherwise [10:21] it's the middle of Sarvatt's night and RAOF said he was off an hour ago :/ [10:22] seems quite some other drivers didn't get rebuild though [10:25] let's give some build retries [10:25] soyuz depwait handling got turned off yesterday [10:26] they had issues with it since the new update [10:26] it's coming back RSN :) [10:26] how rsn is? [10:26] it's getting cherry picked right now [10:27] which means it will land in production today? [10:27] ie it will be active once cherry picked? [10:27] or does it still need to wait a rollout? [10:27] it'll be in production when it's picked [10:27] ok thanks [10:28] I will stop to manually retry all the drivers then [13:24] whats the story about gallium driver? what benefit/use case is that targetting? [13:30] seb128: I've got a set of no-change rebuilds locally plus a new siliconmotion upstream to build against 1.8. You're welcome to retry or upload no-change rebuilds for all the video drivers. [13:32] RAOF, seems they fixed depwait now [13:32] RAOF, do you plan to upload your no change rebuilds? [13:33] I don't have upload rights for them. I was going to beg for for sponsorship from Luke tomorrow. [13:34] do you have them ready somewhere? [13:34] Yeah. I'll put them on my webserver [13:34] so it's just debsign and upload? [13:34] Right. [13:35] can you give the url on #ubuntu-desktop? [13:37] grr... still can't downgrade from xorg-edgers yet... when are they gonna finish building those packages. [13:40] asac: The gallium architecture is meant to make it easier to write graphics drivers for modern cards. The idea is basically to have a low-level architecture which maps easily to modern graphics chips (which are all about programmable stuff) that you can build APIs on top of (OpenGL, OpenVG, DirectX, etc) [13:45] RAOF: so is that something that will become interesting for ARM (or already is?) [13:46] as long as arm means sgx... [13:47] ok so its vendor responsibility to make that happen i guess ... [13:47] but is that of benefit for us? [13:47] e.g. should i go to vendors and tell them to do gallium? [13:48] Only if it makes sense for their hardware. [13:49] please elaborate a bit ;) [13:55] The gallium architecture only makes sense for GPUs which look sufficiently like current desktop GPUs - where there's not much fixed-function hardware, and pretty much everything is programmable and shader-y and such. [13:59] If your GPU hardware looks sufficiently like that, then building your driver using the gallium code will make it easier to support lots of API frontends - OpenGL, GL|ES, OpenVG, etc. Video decode acceleration is also likely to be implemented there (at some point). [14:02] If your GPU hardware doesn't look like that - it doesn't have flexible shaders, it's got a lot of fixed-function stuff - then using the gallium code won't be helpful. [14:04] The classic mesa infrastructure is more suitable for fixed-function hardware, and is not going to be going away. We still need it to support the fixed-function desktop hardware, like pre r300 ATI, and older intel chips. [14:04] RAOF: whats your personal opinion? do you think the win through reduced efforts in writing driver frontends is worth this extra level of abstraction? [14:05] ok ... so all modern stuff is using gallium? [14:06] A lot of modern development is using gallium. [14:07] Almost all of the recent work on r300-r500 cards has been in the gallium driver, and gallium offers a much easier path to get to OpenGL 3 and 4 than the classic mesa drivers. We'll likely be shipping the r300 gallium driver instead of the r300 classic driver for Maverick. [14:08] ok so there is consent that gallium is the way forward for modern hardware. thanks for the background [14:08] Nouveau only has a gallium driver for nv30+. The older chips (nv04-nv2x, corresponding to TNT → GeForce 3) have a classic mesa driver. [14:09] asac: Right. Anything which looks like a modern desktop GPU should be using gallium. ARM GPUs have significantly different constraints, so I'm not sure how much like a modern desktop GPU they behave. [14:10] Hm. Anything which is supposed to support GL|ES v2 is probably enough like a desktop GPU to benefit from gallium. From what I read of GLES v2 it's very much about programmable pipelines and shaders, which is what gallium requires. [14:23] RAOF: Anything that has shaders and want to implement either GL or DX is suitable for gallium [14:24] Which is all modern hardware [14:24] including low powered ARM gpu's.. [14:25] Dr_Jakob: Didn't know you idled here! [14:25] I do now :) [14:26] I think I'd talked myself around to the position that ARM gpus probably wanted gallium, since they GLES v2 appears to be all about the shaders, too. :) [14:28] I dunno about the mali GPU but for SGX most people pay PowerVR for their closed source driver. [14:31] I think we're aiming to be in a position to show demand for opensource drivers, rather than actually having any drivers currently. [17:46] aaargh [17:47] third time crashing due to intel gpu hang, third time re-running mp3gain, and third time fixing corrupted banshee sqlite db. [17:47] * hyperair groans [17:48] hyperair: gpu hang or driver deadlock? [17:48] er [17:48] how do i tell which? [17:48] which gpu? [17:48] intel gpu [17:48] er [17:48] 2a02 [17:48] 965 [17:48] X3100 [17:48] the first number is my pci-id [17:49] the last two are the two different model numbers my gpu appears to go by [17:49] well i'm using xorg-edgers, so i can't really blame anyone but myself for getting these wonderful hangs >_. [17:49] ah [17:51] I used to get gpu lockups on lucid, but that stopped. now I get x/kernel deadlocks instead :( [17:51] on arrandale (core i7 integrated graphics) [17:53] ilmari: how do you tell the difference between a gpu lockup and an x/kernel deadlock? [18:04] hyperair: by SSHing in when it happens and looking at dmesg, Xorg.0.log, intel_gpu_dump [18:05] ilmari: ah i see. well soudn hangs for me, so i'm sure it's a deadlock then =p [18:05] time to start mp3gain again.. [18:05] and hope that it doesn't fail miserably this time >_> [18:07] also SysRq-d (show held locks, requires a kernel with lock debugging), SysRq-w (show blocked tasksk) [18:07] eh? [18:08] to show what's blocking [18:08] no sysrq keys all crash for me [18:08] i mean [18:08] the sysrq keys no longer do anything. [18:08] not even sysrq-b? wow [18:08] (preferrably preceded by s and u) [18:09] not even that. [18:09] that sounds like a GPU or other hardware hang [18:10] =\ [18:11] my deadlock is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/568138 [18:11] Launchpad bug 568138 in xserver-xorg-video-intel (Ubuntu) "[arrandale] deadlock in i915_gem_madvise_ioctl (affects: 6) (dups: 1) (heat: 36)" [Undecided,Confirmed] [18:29] AAAAAAAAAAAAAAAAAAAAAAAARGH! [18:29] AGAIN! [18:39] hyperair: 945 and g33 are fine here, no idea whats up with yours [18:39] * hyperair switches from forbid-version to hold [18:39] what kernel? [18:39] .35-rc2 [18:41] maybe try rc1 again and see if its ok there still? [18:43] nah, things only went sour after last night's upgrade [18:44] after mp3gain finishes, i'll turn on X to see what's going on. [18:45] machine dead when it hangs or can you get any more info out of it? [18:45] there were huge changes in 965 mesa yesterday [18:45] haaaaaaaangs. [18:46] maybe try disabling compiz? [18:46] so ya can blame mesa [18:47] and go non-composited for hours on end until it hangs? [18:47] nothanks. [18:47] i'd end up ignoring the machine, which would in turn ignore me and refuse to hang. [18:49] metacity compositing? :D [18:54] hi all - can anyone help me with this: http://pastebin.com/7wdqrVdH [19:11] Sarvatt: ._. that sounds terrible. [19:12] Sarvatt: i really meant compizless though. gnome-shell is still tolerable, but i can't really go without compiz's extra features, particularly scale for long before cracking and switching to my desktop [19:13] hyperair: build compiz from git where opengl is optional? :D [19:14] Sarvatt: don't have the plugins require opengl? [19:14] Sarvatt: actually i've been meaning to, but at the rate i'm crashing, i'll never get to clone compiz from git. [19:15] i dunno, lets see. i dont think they do though [19:15] [19:15] opengl [19:15] so scale does :( [19:16] heheh [19:20] could always just purge xorg-edgers and use 2.11 from x-updates :D [19:20] of course mesa is going to suck then === asac_ is now known as asac [19:31] why did we make nvidia-graphics-drivers provide a video abi again? it supports multiple abi's with the same package.. [19:31] (needs to be no change rebuilt too) [19:33] nvidia-173 and lower dont work with 1.8 either yet, i think they'll work with the IgnoreABI option though