[00:01] <bryceh> tacked it onto the end of https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
[00:04] <bryceh> looking at the oneiric gpu lockups, they seem to follow this trend
[00:05] <bryceh> wonder what 0x6xxxxxxx signifies
[00:20] <RAOF> bryceh, Sarvatt: Hm.  Andy's just enabled the vmwgfx kernel module in the latest kernel upload.  What do you think about turning on the associated mesa stuff?
[00:20] <bryceh> hrm
[00:21] <bryceh> how stable do we think it is?
[00:21] <RAOF> I have no idea.  Sarvatt, you've played with it, haven't you?
[00:21] <bryceh> something we could put into -experimental ?  (or do we still have that package?)
[00:22] <RAOF> We do still have that package; it's got classic r300 and r600 drivers, and i915g.  Oh, and llvmpipe.
[00:25] <bryceh> might not be a bad idea to stage it there for a bit just in case.
[00:25] <RAOF> Yeah.
[00:25] <bryceh> but I don't have strong feelings one way or the other
[00:25] <RAOF> We'd also have it build an xserver-xorg-video-vmware-ish package; it uses the xorg state tracker from gallium.
[01:24] <bjsnider> RAOF, still awake and whatnot?
[01:25] <RAOF> bjsnider: Yeah, 'course.
[01:25] <RAOF> (It's almost midday ;))
[01:25] <bjsnider> question about gallium
[01:25] <bjsnider> uh, ok
[01:25] <bjsnider> it's night
[01:26] <RAOF> What's the question?
[01:26] <bjsnider> anyway, if a state tracker is added to gallium, does a driver, nouveau for instance, have to do anything to add support for that tracker or is it automatic?
[01:27] <RAOF> I'm not entirely sure.  I think the answer is somewhere in the range from "no, it's automatic" to "yes, but only very minimal hookup assuming the driver supports the appropriate gallium interfaces".
[01:28] <bjsnider> i thought, in reading the original documentation, that the answer was "definitely no"
[01:28] <bjsnider> so if an opengl 4.xx state tracker is added all gallium drivers would immediately support it
[01:30] <RAOF> I think that's not necessarily going to be the case; I'm not sure if the existing gallium interfaces can express all of GL 4.x.
[01:30] <bjsnider> well, in that case, it's not going to be an issue for about 40 years
[01:31] <bjsnider> but even if it's a small state tracker that accelerates text off the gpu or something
[01:31] <RAOF> Or, rather, I'm pretty sure that some of GL 4.x, particularly geometry shaders, requires driver support that doesn't currently exist.
[01:32] <RAOF> I think my thinking might be slightly reversed; state trackers need to know something of the pipe drivers, but pipe drivers don't necessarily need to know about state trackers.
[01:33] <RAOF> So the gallium EGL tracker just has all the pipe drivers built in; it used to have code to select which pipe driver to dlopen, etc.
[01:34] <bjsnider> you mean as new drivers are added, the state trackers have to be modified to take that into account?
[01:36] <RAOF> Yes.
[01:37] <RAOF> Or, at least, the *targets* do.  If you wrote a new pipe driver capable of accelerating GLES, gallium's egl_gallium.so wouldn't use it until you'd updated some stuff.
[01:37] <bjsnider> well, either way it's a fair amount of work
[01:38] <RAOF> I don't think that's the case; I think it's a fairly small amount of work.  Once you've got the state tracker or pipe driver, of course.
[01:38] <bjsnider> but would that be thousands of lines of code or just a few dozen?
[01:38] <RAOF> I guess I could look at historical precedent - getting the xorg state tracker to work with nouveau, or ati.
[01:38] <RAOF> IIRC those were done in few commits of not much code.
[01:47] <bryceh> hmm, weird, why does ubuntu-bug xkb-data work but ubuntu-bug xkeyboard-config doesn't?
[01:48] <RAOF> bryceh: Because xkeyboard-config isn't a binary package?
[01:49] <bryceh> it must be
[01:49] <bryceh> my understanding of apport hook naming must be off
[01:53] <bryceh> hmm, no, seems my understanding is right, it's just not working like it's supposed to
[01:54] <bryceh> if you have a hook named 'source_foo.py' as opposed to just 'foo.py' it's supposed to include all binary packages produced by foo
[01:55] <bryceh> ahh, but it doesn't support filing against the source package name itself!
[01:55] <bryceh> which is weird.
[02:02] <RAOF> Time for pittiping!
[02:03] <bryceh> indeed; going to dig through some python code a bit first
[02:20] <bryceh> (aha found it)
[02:22] <bryceh> ehh wonkiness
[02:31] <bjsnider> that's the advantage of being a motu. when you find a bug in something you can just infiltrate the code and correct it.
[02:32] <bryceh> s/a motu/open source/ ;-)
[02:32] <bryceh> in this case, I don't have commit access to apport's bzr tree anyway, so still have to get the patch approved by pitti, so don't matter that I'm motu
[02:33] <bryceh> >>> cache = apt.Cache()
[02:33] <bryceh> >>> cache['xkb-data']
[02:33] <bryceh> <Package: name:'xkb-data' architecture='i386' id:1126L>
[02:33] <bryceh> >>> cache['xkeyboard-config']
[02:33] <bryceh> Traceback (most recent call last):
[02:33] <bryceh>   File "<stdin>", line 1, in <module>
[02:33] <bryceh>   File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 177, in __getitem__
[02:33] <bryceh>     raise KeyError('The cache has no package named %r' % key)
[02:33] <bryceh> KeyError: "The cache has no package named 'xkeyboard-config'"
[02:33] <bryceh> unfortunately... dunno how to look up source packages via apt.Cache()
[02:38] <bjsnider> i could look through the code but not correct the problem
[02:38] <bjsnider> well, i suppose there's a chance i could correct it
[02:38] <bjsnider> a borken clock is right twice a day
[06:52] <bryceh> fwiw, found the issue already reported as bug #359810.  Posted my fix there
[09:28] <tjaalton> hmm, would be nice to have a one-off debugging script to trigger via the kernel cmdline, and which would save the critical logs for later use
[09:29] <tjaalton> for instance when KMS doesn't work
[10:10] <jibel> I get bug 831884 with today's desktop ISOs on 2 intel systems. 
[10:11] <jibel> X fails to start on Live CD on intel: [drm] failed to set drm interface version
[10:30] <tjaalton> hum, where's ubotu
[10:30] <tjaalton> jibel: which package did you file it against?
[10:32] <jibel> tjaalton, xserver-xorg-video-intel http://pad.lv/831884
[11:10] <tjaalton> jibel: not seen that one before
[11:16] <tjaalton> jibel: from which machine did you file the bug?
[11:16] <tjaalton> since it's intel too and running oneiric
[11:56] <jibel> tjaalton, I generated the report from the ASUSTeK Computer INC. 1015PE with N10 graphics card
[11:58] <jibel> tjaalton, but I get the exact same problem on a Dell N4010 with an Arrandale booting from USB.
[12:12] <jibel> https://bugs.launchpad.net/bugs/585853 looks similar.
[12:12] <jibel> that would confirm a problem with lightdm
[12:19] <tjaalton> jibel: yeah, so it's a race condition between plymouth and lightdm..
[12:23] <jibel> tjaalton, yup, I'll ask the desktop team. I'll close the intel task once we narrowed it down. thanks for looking into it.
[12:25] <seb128> stop the blame it on lightdm game ;-)
=== Prf_Jako1 is now known as Prf_Jakob
=== thade_w|2 is now known as Alexia_Death_
=== shadeslayer_ is now known as shadeslayer