[00:00] <RAOF> Among other things I think that steam does some GL vendor string parsing and freaks out about gallium drivers.
[00:01] <RAOF> The nouveau drivers would be pretty featureful, but significantly less stable.
[00:01] <RAOF> And significantly less fast, too.
[00:05] <lifeless> brb
[00:08] <lifeless> right, where was I
[00:08] <lifeless> oh yes
[00:08] <RAOF> In Sacrifice?
[00:10] <lifeless> heh
[00:11] <lifeless> so in lucid
[00:11] <RAOF> 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] <lifeless> and I just upgraded my games machine, so its new
[00:12] <lifeless> when it goes fullscreen, most of the time, its offset to the bottom-right
[00:12] <lifeless> *but the desktop shows in the gap*
[00:13] <RAOF> Ah.  Silly cedega.
[00:13] <lifeless> worked in karmic
[00:14] <Sarvatt> intels gpu's are such crap noone would buy a seperate card and they know it :)
[00:16] <RAOF> 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] <RAOF> Worked in Karmic, eh?
[00:16] <lifeless> RAOF: this occurs with both i915 or whatever my laptop has, and the nvidia in my games machine
[00:16] <lifeless> RAOF: and it was pixel perfect yesterday morning before the upgrade
[00:17] <Sarvatt> what upgrade?
[00:17] <lifeless> karmic-lucid
[00:17] <lifeless> my games machine was shipped transtasmin so this was the first chance to do it
[00:17] <lifeless> http://imagebin.org/100511
[00:17] <lifeless> RAOF: ^
[00:17] <RAOF> I think this is unlikely to be an X problem.
[00:17] <lifeless> shows both the offset, and the other thing I wanted to query you on
[00:18] <RAOF> Oh, a third thing? :)
[00:18] <lifeless> yes
[00:18] <lifeless> choosepixelformat failed
[00:19] <lifeless> which google tells me was fixed in 2006 with glx1.3
[00:19] <lifeless> and glxinfo claims the nvidia driver is glx1.4
[00:19] <lifeless> whats particularly special is alt-tab to and from the fullscreen app aligns it correctly on the screen
[00:20] <RAOF> 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] <lifeless> well, I know that I know not, in this space.
[00:20] <lifeless> I'm going to get a vanilla wine install of steam up
[00:21] <lifeless> and see if its better
[00:21] <Sarvatt> yeah that'd be the first thing i'd try too
[00:21] <lifeless> though that itself appears to be black magic
[00:22] <Sarvatt> ? it installs fine here
[00:22] <Sarvatt> i'm in the process of installing counterstrike now in it
[00:24] <Sarvatt> pretty sure you can just use the cedega one too since its just wine
[00:25] <lifeless> blows up when I run regular wine on it
[00:25] <lifeless> with WINE_ENV or whatever set
[00:25] <lifeless> cleaner to start fresh, I think
[00:28] <Sarvatt> looks like wine with the blob starts things at 60hz when it changes resolutions
[00:28] <Sarvatt> the blob lies about what refresh rate you're at for its twinview crap
[00:29] <Sarvatt> try adding Option		"DynamicTwinView"	"false" to your xorg.conf?
[00:30] <Sarvatt> found an old forums post from 07 with the same problem it looks like - http://ubuntuforums.org/showthread.php?t=629173
[00:30] <lifeless> I'm in awe of your googlejuice
[00:31] <Sarvatt> wine fullscreen xserver 1.7 found it :)
[00:31] <lifeless> ah 
[00:31] <lifeless> thats for the offset thing, not the pixel format
[00:31] <lifeless> right
[00:33] <Sarvatt> looks like disabling compiz will fix the choosepixelformat error
[00:34] <lifeless> I have visual effects set to None already
[00:35] <lifeless> I thought that disabled compiz ?
[00:35] <Sarvatt> oh, darn :(
[00:36] <Sarvatt> http://forums.steampowered.com/forums/showthread.php?t=1282981
[00:37] <Sarvatt> looks like it picks directx mode by default and that switched it to opengl so it works
[00:38] <lifeless> that screenshot was set to gl mode :)
[00:38] <lifeless> d3d mode goes boom
[00:39] <lifeless> I'm pulling down cs in a fresh wine setup
[00:39] <lifeless> will report back in a couple hours I guess
[00:40] <lifeless> for now, bzr stuff awaits
[02:17] <Sarvatt> intel needs a rebuild :( looks like the server was stuck in NEW
[02:18] <Sarvatt>  Provides: xserver-xorg-video-6
[02:43] <lifeless> RAOF: so, lucid wine does a bit better
[02:43] <lifeless> Sarvatt: the twinview thing helped
[03:34] <ripps> 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] <ripps> Sarvatt: ^
[03:36] <RAOF> ripps: Yes, you will.  Not everything's built for the new server yet.
[03:37] <ripps> RAOF: ah, okay. Any idea when they'll roll out?
[03:37] <RAOF> Today.
[03:42] <lifeless> RAOF: cedega is still naffed :-) chalk one up for open sores
[03:43] <RAOF> Heh.
[04:08] <lifeless> RAOF: now, just have to remove pulseaudio and everything should be happy again
[04:47] <RAOF> Ok.  Weirded out by that mesa backtrace.
[09:12] <ntr0py> 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] <ntr0py> 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] <bryceh> ntr0py, http://ubuntu.com/support
[09:17] <ntr0py> 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] <ntr0py> bryceh: What should i do with your url??
[09:25] <bryceh> 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] <ntr0py> 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] <bryceh> 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] <bryceh> 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] <bryceh> patches definitely welcomed on that one, as the number of developers who support the proprietary driver is pretty limited.
[09:33] <bryceh> anyway, nite.
[09:33] <RAOF> bryceh: Good night!
[09:34] <ntr0py> 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] <RAOF> ntr0py: Something like that would be the way to do it, yeah.
[09:34]  * RAOF is also off.
[09:38] <ntr0py> Any ideas how i could wait with gdm's start on nvidia module having build and beeing ready for use in upstart?
[10:16] <seb128> the current intel driver got built with the old xserver
[10:16] <seb128> should it be rebuilt to get the new abi?
[10:17] <jcristau> yes.
[10:17] <seb128> is there a list of things that need to be rebuilt still somewhere?
[10:18] <seb128> 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] <jcristau> don't know of a reason you should hold off
[10:20] <seb128> ok thanks
[10:20] <seb128> I will let a bit for somebody to comment if there is a reason or do an upload in an hour otherwise
[10:21] <jcristau> it's the middle of Sarvatt's night and RAOF said he was off an hour ago :/
[10:22] <seb128> seems quite some other drivers didn't get rebuild though
[10:25] <seb128> let's give some build retries
[10:25] <seb128> soyuz depwait handling got turned off yesterday
[10:26] <seb128> they had issues with it since the new update
[10:26] <bigjools> it's coming back RSN :)
[10:26] <seb128> how rsn is?
[10:26] <bigjools> it's getting cherry picked right now
[10:27] <seb128> which means it will land in production today?
[10:27] <seb128> ie it will be active once cherry picked?
[10:27] <seb128> or does it still need to wait a rollout?
[10:27] <bigjools> it'll be in production when it's picked
[10:27] <seb128> ok thanks
[10:28] <seb128> I will stop to manually retry all the drivers then
[13:24] <asac> whats the story about gallium driver? what benefit/use case is that targetting?
[13:30] <RAOF> 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] <seb128> RAOF, seems they fixed depwait now
[13:32] <seb128> RAOF, do you plan to upload your no change rebuilds?
[13:33] <RAOF> I don't have upload rights for them.  I was going to beg for for sponsorship from Luke tomorrow.
[13:34] <seb128> do you have them ready somewhere?
[13:34] <RAOF> Yeah.  I'll put them on my webserver
[13:34] <seb128> so it's just debsign and upload?
[13:34] <RAOF> Right.
[13:35] <seb128> can you give the url on #ubuntu-desktop?
[13:37] <ripps> grr... still can't downgrade from xorg-edgers yet... when are they gonna finish building those packages.
[13:40] <RAOF> 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] <asac> RAOF: so is that something that will become interesting for ARM (or already is?)
[13:46] <jcristau> as long as arm means sgx...
[13:47] <asac> ok so its vendor responsibility to make that happen i guess ...
[13:47] <asac> but is that of benefit for us?
[13:47] <asac> e.g. should i go to vendors and tell them to do gallium?
[13:48] <RAOF> Only if it makes sense for their hardware.
[13:49] <asac> please elaborate a bit ;)
[13:55] <RAOF> 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] <RAOF> 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] <RAOF> 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] <RAOF> 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] <asac> 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] <asac> ok ... so all modern stuff is using gallium?
[14:06] <RAOF> A lot of modern development is using gallium.
[14:07] <RAOF> 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] <asac> ok so there is consent that gallium is the way forward for modern hardware. thanks for the background
[14:08] <RAOF> 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] <RAOF> 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] <RAOF> 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] <Dr_Jakob> RAOF: Anything that has shaders and want to implement either GL or DX is suitable for gallium
[14:24] <Dr_Jakob> Which is all modern hardware
[14:24] <Dr_Jakob> including low powered ARM gpu's..
[14:25] <RAOF> Dr_Jakob: Didn't know you idled here!
[14:25] <Dr_Jakob> I do now :)
[14:26] <RAOF> 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] <Dr_Jakob> I dunno about the mali GPU but for SGX most people pay PowerVR for their closed source driver.
[14:31] <RAOF> 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] <hyperair> aaargh
[17:47] <hyperair> 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] <ilmari> hyperair: gpu hang or driver deadlock?
[17:48] <hyperair> er
[17:48] <hyperair> how do i tell which?
[17:48] <ilmari> which gpu?
[17:48] <hyperair> intel gpu
[17:48] <hyperair> er
[17:48] <hyperair> 2a02
[17:48] <hyperair> 965
[17:48] <hyperair> X3100
[17:48] <hyperair> the first number is my pci-id
[17:49] <hyperair> the last two are the two different model numbers my gpu appears to go by
[17:49] <hyperair> well i'm using xorg-edgers, so i can't really blame anyone but myself for getting these wonderful hangs >_.
[17:49] <ilmari> ah
[17:51] <ilmari> I used to get gpu lockups on lucid, but that stopped. now I get x/kernel deadlocks instead :(
[17:51] <ilmari> on arrandale (core i7 integrated graphics)
[17:53] <hyperair> ilmari: how do you tell the difference between a gpu lockup and an x/kernel deadlock?
[18:04] <ilmari> hyperair: by SSHing in when it happens and looking at dmesg, Xorg.0.log, intel_gpu_dump
[18:05] <hyperair> ilmari: ah i see. well soudn hangs for me, so i'm sure it's a deadlock then =p
[18:05] <hyperair> time to start mp3gain again..
[18:05] <hyperair> and hope that it doesn't fail miserably this time >_>
[18:07] <ilmari> also SysRq-d (show held locks, requires a kernel with lock debugging), SysRq-w (show blocked tasksk)
[18:07] <hyperair> eh?
[18:08] <ilmari> to show  what's blocking
[18:08] <hyperair> no sysrq keys all crash for me
[18:08] <hyperair> i mean
[18:08] <hyperair> the sysrq keys no longer do anything.
[18:08] <ilmari> not even sysrq-b? wow
[18:08] <ilmari> (preferrably preceded by s and u)
[18:09] <hyperair> not even that.
[18:09] <ilmari> that sounds like a GPU or other hardware hang
[18:10] <hyperair> =\
[18:11] <ilmari> my deadlock is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/568138
[18:11] <ubot4> 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] <hyperair> AAAAAAAAAAAAAAAAAAAAAAAARGH!
[18:29] <hyperair> AGAIN!
[18:39] <Sarvatt> hyperair: 945 and g33 are fine here, no idea whats up with yours
[18:39]  * hyperair switches from forbid-version to hold
[18:39] <Sarvatt> what kernel?
[18:39] <hyperair> .35-rc2
[18:41] <Sarvatt> maybe try rc1 again and see if its ok there still?
[18:43] <hyperair> nah, things only went sour after last night's upgrade
[18:44] <hyperair> after mp3gain finishes, i'll turn on X to see what's going on.
[18:45] <Sarvatt> machine dead when it hangs or can you get any more info out of it?
[18:45] <Sarvatt> there were huge changes in 965 mesa yesterday
[18:45] <hyperair> haaaaaaaangs.
[18:46] <Sarvatt> maybe try disabling compiz?
[18:46] <Sarvatt> so ya can blame mesa
[18:47] <hyperair> and go non-composited for hours on end until it hangs?
[18:47] <hyperair> nothanks.
[18:47] <hyperair> i'd end up ignoring the machine, which would in turn ignore me and refuse to hang.
[18:49] <Sarvatt> metacity compositing? :D
[18:54] <ThisOtherGuy> hi all - can anyone help me with this: http://pastebin.com/7wdqrVdH
[19:11] <hyperair> Sarvatt: ._. that sounds terrible.
[19:12] <hyperair> 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] <Sarvatt> hyperair: build compiz from git where opengl is optional? :D
[19:14] <hyperair> Sarvatt: don't have the plugins require opengl?
[19:14] <hyperair> 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] <Sarvatt> i dunno, lets see. i dont think they do though
[19:15] <Sarvatt> 	    <requirement>
[19:15] <Sarvatt> 		<plugin>opengl</plugin>
[19:15] <Sarvatt> so scale does :(
[19:16] <hyperair> heheh
[19:20] <Sarvatt> could always just purge xorg-edgers and use 2.11 from x-updates :D
[19:20] <Sarvatt> of course mesa is going to suck then
[19:31] <Sarvatt> why did we make nvidia-graphics-drivers provide a video abi again? it supports multiple abi's with the same package..
[19:31] <Sarvatt> (needs to be no change rebuilt too)
[19:33] <Sarvatt> nvidia-173 and lower dont work with 1.8 either yet, i think they'll work with the IgnoreABI option though