[00:40] kaay chromium dlopen's /usr/lib/libGL.so.1 apparently to work around a problem in the nvidia blob libGL, ours is in /usr/lib/foo/, there is no libgl dependency on the package, and libgl1-mesa-dri is a build dep? [00:41] guess we dont need the libgl dep anyway since it doesnt work :) [00:50] We need to work out whether we care that we're breaking the linux OpenGL ABI. [01:35] why does chromium need opengl? [01:52] Because it wants to do hardware accelerated graphics, I guess. [01:52] Also, WebGL™ [01:53] thanks for the trademark [01:53] i was worried it wasn't trademarked but you have assuaged my fears [01:54] * RAOF loves his gnome-keyring Do plugin. [01:54] so now al we need is a flawless opengl implementation on linux [01:54] should be the case in about 300 years [01:55] WebGL should work now, at least. [02:16] somebody probably once said that about opengl [02:17] And OpenGL works now* [02:17] *: For some values of works :) [02:19] i could challenge that, but it's like shooting fish in a barrel, isn't it? [02:20] by the way, what is mesa up to now? opengl which version? [02:20] Mu [02:21] (As in: the question is incorrect) [02:21] 2.1 still? [02:21] No. [02:21] Roughly speaking, somewhere between 2.0 and 4 [02:22] ok, what's it up to on modern hardware that has a decent mesa driver? [02:22] It *claims* 2.1, but I don't think it fully supports all the 2.1 features. Similarly, it supports 3.x features. [02:22] that's probably not even enough qualifications [02:23] And some GL 4.x features, too. [02:23] and that's mainy for the last intel chips before they started going to that closed-source company for hardware right? [02:25] No; that's for radeon (and to a lesser extent nouveau). [02:25] And some features are basically driver independent. [02:26] (Like the "use the ES 2.0 profile for GLSL on desktop GL" feature) [02:26] let me ax you a specific question i've been wondering about [02:27] you work with the nouveau guys right? [02:27] if you found a serious flaw in the nouveau driver, could you personally code in a solution? [02:28] It depends; I could probably fix a serious but shallow problem, but I don't have a good grasp of the deep. [02:28] (That's something I plan to work on over the Natty timeframe) [02:29] well, i'm not talking about the kinds of patches to the nvidia blob that kick around and change 3 linkes or whatever [02:29] i'm talking about something requiring significant changes [02:29] hundreds of lines [02:30] Again, it depends on the actual problem. [02:30] Let's take, for example, my most recent kernel hacking: the Intel 965 resolution change wierdness. [02:30] i doubt you could. i doubt anyone could fix the kinds of problems i have in mind except the nouveau devs themselves [02:31] and in that sense, nouveau and nvidia are the same. we are depending in both cases on those developers and ONLY those developers to fix things FOR US [02:32] We *can* provide more useful bug reports for the nouveau developers. [02:32] i knew you'd say that [02:32] Well, that's probably because it's true :) [02:33] did you see those benchmarks on phoronix where nouveau is one third as fast as nvidia ont he same hardware? [02:33] Man, that's pretty good. [02:33] what if i asked you to, in the natty timeframe, fix it so that the performance was even par? [02:33] No. [02:33] and who could do that? [02:33] Nvidia, given 2 years. [02:34] The performance of the nvidia driver has taken *hundreds* of full-time developers *years* to produce. [02:34] The free drivers are unlikely to reach performance parity with either the nvidia or fglrx blobs unless they become the development focus of the respective companies. [02:34] ok, lemme rephrase: as fast as the theroetical limit of the gallium framework given what is known about nvidia hardware [02:38] I don't know; "theoretical limit" is a bit problematic, because the gallium framework is basically mutable, *and* hasn't really seen a huge amount of profiling - if you found a serious bottleneck, you could fix it. [02:39] alright, further qualification: your subjective view of it's theoretical limit [02:39] the question is, could you, RAOF, personally push the driver that far in the natty timeframe? [02:40] No. [02:40] could anyone at canonical? [02:40] I don't think *anyone* could. [02:40] But, no, I don't think there's anyone better for that at Canonical. [02:41] well, the nouveau guys could if it was their only goal, leaving everything else aside [02:42] i suspect that's the same deal for all graphics drivers. so us normal regular users can't do much but bellyache about it: same as nvidia [02:44] I don't think that's a useful metric, really. [02:44] Regular users certainly *can* do things; and we've contributed code to the free drivers. [02:45] well, nvidia has a bug reporting system too [02:45] it's not as transparent as launchpad though [02:45] but it's there [02:46] But we can't contribute code. [02:47] And I mean that in the most expansive sense of "we". [02:47] you just said you couldn't contribute anything more than trivial changes [02:47] and if you can't, reguylar users can't either [02:48] Well, there's a bit of a difference between "I probably can't fix the deep problems that you're thinking of *now*" and "can't contribute anything more than trivial changes". [02:49] I'm not an expert in the internals of nouveau at the moment, but the thing about open-source is that I could *become* one. [02:50] how hard would it be to become an experton nouveau's internals compared to, say, gnome-shell, which is javascript? [02:50] More difficult, certainly. [02:50] (i'm cheating, since js was chosen specifically to invite contributions) [02:50] *Particularly* because there's no official documentation. [02:51] It's relatively much easier to pick up i915. [02:51] yeah, well i thought i read an article where the nouveau guys said they didn't need any since they'd reverse-engineered everything [02:52] do a lot of non-intel people contribute to i915? [02:52] Yes. [02:52] to be fair though, that is not exactly on par with nvidia graphics hardware, is it? [02:53] A fair number of non-AMD people contribute to radeon, too. [02:53] what about contributors who aren't being paid to do so? [02:53] There are a bunch. [02:53] Certainly a couple. [02:54] The nice thing about documentation is egde cases. Which sometimes the documentation doesn't contain anyway, but when it *does* contain them it's really, really nice. [03:05] edge cases? [03:11] bjsnider, edge case as in a chip model that has some unique feature or implements a feature in a weird way [03:12] Things like the i965 resolution change bug: (sometimes!) when changing to a lower resolution, the display would go all wonky. [03:14] Perusing the documentation, it turned out that the hardware cursor was required to have at least one pixel on the screen; when switching down, with the mouse in an area which was outside the new resolution, we'd have the cursor fully outside the new framebuffer. [03:15] Constraining the cursor so that it remains on the framebuffer fixed this. [03:15] And the bug would have been significantly more difficult to diagnose if I didn't have the documentation. [03:16] Without it, you're left with "it looks like the digital display looses sync sometimes when we decrese resolution with the mouse in a particular spot!?" [03:22] so all we need is the documentation, but nvidia can't release it because of nda's with other companies, and so we won't have it anyway [03:22] Well, not all we need. [03:23] It *would* be helpful, but we also need manpower (which is easier to acquire with documentation, though) [04:36] bryceh, Sarvatt: Do you think we can solve bug #636311 with a change in the conf-files? I haven't quite figured out a way to distinguish the two different devices the keyboard shows up as. [04:36] Launchpad bug 636311 in xserver-xorg-input-evdev (Ubuntu) (and 2 other projects) "Keyboard special keys interfere with mouse (affects: 12) (dups: 1) (heat: 68)" [High,Incomplete] https://launchpad.net/bugs/636311 [04:38] Oh, hm. That could be done in udev, by not tagging the second device with IS_KEYBOARD. === ara__ is now known as ara [18:06] the SUSE xserver crash handler is so nice - https://bugs.freedesktop.org/attachment.cgi?id=39285 [18:10] is that the patches emmes just sent? [18:10] looks impressive [18:10] oh wow they sent it upstream? [18:11] i saw it about 6 months ago in their source packages, was meaning to try to get it going on our stuff [18:11] 14193 N Fri 08/10/2010 18:25+0200 Matthias Hopf (1.5K) [PATCH] Create reasonable backtraces via gdb automatically [18:11] yeah thats the same thing though === ara__ is now known as ara === ara__ is now known as ara [21:00] Sarvatt, do you know where the debian packaging for xinput is maintained? [21:01] I can't find it on git.debian.org [21:01] jcristau does it outside of pkg-xorg [21:01] one sec [21:01] the full list takes awhile to load on this netbook :) [21:01] http://git.debian.org/?p=users/jcristau/xinput.git;a=summary [21:02] ahh, ok [21:02] thanks! [21:04] Sarvatt, is there a way to tell auto-xorg-git where that repo is? [21:04] it seems confused :) [21:05] yeah it doesnt work for things outside of pkg-xorg :( [21:05] ok, I'll hack it up so it does [21:05] :) [22:55] i should probably get that into pkg-xorg. === yofel_ is now known as yofel