| bryceh | tacked it onto the end of https://wiki.ubuntu.com/X/InterpretingIntelGpuDump | 00:01 |
|---|---|---|
| bryceh | looking at the oneiric gpu lockups, they seem to follow this trend | 00:04 |
| bryceh | wonder what 0x6xxxxxxx signifies | 00:05 |
| 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:20 |
| 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:21 |
| RAOF | We do still have that package; it's got classic r300 and r600 drivers, and i915g. Oh, and llvmpipe. | 00:22 |
| 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. | 00:25 |
| bjsnider | RAOF, still awake and whatnot? | 01:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| bjsnider | you mean as new drivers are added, the state trackers have to be modified to take that into account? | 01:34 |
| RAOF | Yes. | 01:36 |
| 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:37 |
| 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:38 |
| bryceh | hmm, weird, why does ubuntu-bug xkb-data work but ubuntu-bug xkeyboard-config doesn't? | 01:47 |
| RAOF | bryceh: Because xkeyboard-config isn't a binary package? | 01:48 |
| bryceh | it must be | 01:49 |
| bryceh | my understanding of apport hook naming must be off | 01:49 |
| bryceh | hmm, no, seems my understanding is right, it's just not working like it's supposed to | 01:53 |
| 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:54 |
| bryceh | ahh, but it doesn't support filing against the source package name itself! | 01:55 |
| bryceh | which is weird. | 01:55 |
| RAOF | Time for pittiping! | 02:02 |
| bryceh | indeed; going to dig through some python code a bit first | 02:03 |
| bryceh | (aha found it) | 02:20 |
| bryceh | ehh wonkiness | 02:22 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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 | 02:38 |
| bryceh | fwiw, found the issue already reported as bug #359810. Posted my fix there | 06:52 |
| 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:28 |
| tjaalton | for instance when KMS doesn't work | 09:29 |
| jibel | I get bug 831884 with today's desktop ISOs on 2 intel systems. | 10:10 |
| jibel | X fails to start on Live CD on intel: [drm] failed to set drm interface version | 10:11 |
| tjaalton | hum, where's ubotu | 10:30 |
| tjaalton | jibel: which package did you file it against? | 10:30 |
| jibel | tjaalton, xserver-xorg-video-intel http://pad.lv/831884 | 10:32 |
| tjaalton | jibel: not seen that one before | 11:10 |
| tjaalton | jibel: from which machine did you file the bug? | 11:16 |
| tjaalton | since it's intel too and running oneiric | 11:16 |
| jibel | tjaalton, I generated the report from the ASUSTeK Computer INC. 1015PE with N10 graphics card | 11:56 |
| jibel | tjaalton, but I get the exact same problem on a Dell N4010 with an Arrandale booting from USB. | 11:58 |
| jibel | https://bugs.launchpad.net/bugs/585853 looks similar. | 12:12 |
| jibel | that would confirm a problem with lightdm | 12:12 |
| tjaalton | jibel: yeah, so it's a race condition between plymouth and lightdm.. | 12:19 |
| 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:23 |
| seb128 | stop the blame it on lightdm game ;-) | 12:25 |
| === Prf_Jako1 is now known as Prf_Jakob | ||
| === thade_w|2 is now known as Alexia_Death_ | ||
| === shadeslayer_ is now known as shadeslayer | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!