[00:40] <Sarvatt> 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] <Sarvatt> guess we dont need the libgl dep anyway since it doesnt work :)
[00:50] <RAOF> We need to work out whether we care that we're breaking the linux OpenGL ABI.
[01:35] <bjsnider> why does chromium need opengl?
[01:52] <RAOF> Because it wants to do hardware accelerated graphics, I guess.
[01:52] <RAOF> Also, WebGL™
[01:53] <bjsnider> thanks for the trademark
[01:53] <bjsnider> i was worried it wasn't trademarked but you have assuaged my fears
[01:54]  * RAOF loves his gnome-keyring Do plugin.
[01:54] <bjsnider> so now al we need is a flawless opengl implementation on linux
[01:54] <bjsnider> should be the case in about 300 years
[01:55] <RAOF> WebGL should work now, at least.
[02:16] <bjsnider> somebody probably once said that about opengl
[02:17] <RAOF> And OpenGL works now*
[02:17] <RAOF> *: For some values of works :)
[02:19] <bjsnider> i could challenge that, but it's like shooting fish in a barrel, isn't it?
[02:20] <bjsnider> by the way, what is mesa up to now? opengl which version?
[02:20] <RAOF> Mu
[02:21] <RAOF> (As in: the question is incorrect)
[02:21] <bjsnider> 2.1 still?
[02:21] <RAOF> No.
[02:21] <RAOF> Roughly speaking, somewhere between 2.0 and 4
[02:22] <bjsnider> ok, what's it up to on modern hardware that has a decent mesa driver?
[02:22] <RAOF> 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] <bjsnider> that's probably not even enough qualifications
[02:23] <RAOF> And some GL 4.x features, too.
[02:23] <bjsnider> and that's mainy for the last intel chips before they started going to that closed-source company for hardware right?
[02:25] <RAOF> No; that's for radeon (and to a lesser extent nouveau).
[02:25] <RAOF> And some features are basically driver independent.
[02:26] <RAOF> (Like the "use the ES 2.0 profile for GLSL on desktop GL" feature)
[02:26] <bjsnider> let me ax you a specific question i've been wondering about
[02:27] <bjsnider> you work with the nouveau guys right?
[02:27] <bjsnider> if you found a serious flaw in the nouveau driver, could you personally code in a solution?
[02:28] <RAOF> It depends; I could probably fix a serious but shallow problem, but I don't have a good grasp of the deep.
[02:28] <RAOF> (That's something I plan to work on over the Natty timeframe)
[02:29] <bjsnider> 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] <bjsnider> i'm talking about something requiring significant changes
[02:29] <bjsnider> hundreds of lines
[02:30] <RAOF> Again, it depends on the actual problem.
[02:30] <RAOF> Let's take, for example, my most recent kernel hacking: the Intel 965 resolution change wierdness.
[02:30] <bjsnider> i doubt you could. i doubt anyone could fix the kinds of problems i have in mind except the nouveau devs themselves
[02:31] <bjsnider> 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] <RAOF> We *can* provide more useful bug reports for the nouveau developers.
[02:32] <bjsnider> i knew you'd say that
[02:32] <RAOF> Well, that's probably because it's true :)
[02:33] <bjsnider> did you see those benchmarks on phoronix where nouveau is one third as fast as nvidia ont he same hardware?
[02:33] <RAOF> Man, that's pretty good.
[02:33] <bjsnider> what if i asked you to, in the natty timeframe, fix it so that the performance was even par?
[02:33] <RAOF> No.
[02:33] <bjsnider> and who could do that?
[02:33] <RAOF> Nvidia, given 2 years.
[02:34] <RAOF> The performance of the nvidia driver has taken *hundreds* of full-time developers *years* to produce.
[02:34] <RAOF> 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] <bjsnider> ok, lemme rephrase: as fast as the theroetical limit of the gallium framework given what is known about nvidia hardware
[02:38] <RAOF> 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] <bjsnider> alright, further qualification: your subjective view of it's theoretical limit
[02:39] <bjsnider> the question is, could you, RAOF, personally push the driver that far in the natty timeframe?
[02:40] <RAOF> No.
[02:40] <bjsnider> could anyone at canonical?
[02:40] <RAOF> I don't think *anyone* could.
[02:40] <RAOF> But, no, I don't think there's anyone better for that at Canonical.
[02:41] <bjsnider> well, the nouveau guys could if it was their only goal, leaving everything else aside
[02:42] <bjsnider> 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] <RAOF> I don't think that's a useful metric, really.
[02:44] <RAOF> Regular users certainly *can* do things; and we've contributed code to the free drivers.
[02:45] <bjsnider> well, nvidia has a bug reporting system too
[02:45] <bjsnider> it's not as transparent as launchpad though
[02:45] <bjsnider> but it's there
[02:46] <RAOF> But we can't contribute code.
[02:47] <RAOF> And I mean that in the most expansive sense of "we".
[02:47] <bjsnider> you just said you couldn't contribute anything more than trivial changes
[02:47] <bjsnider> and if you can't, reguylar users can't either
[02:48] <RAOF> 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] <RAOF> 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] <bjsnider> how hard would it be to become an experton nouveau's internals compared to, say, gnome-shell, which is javascript?
[02:50] <RAOF> More difficult, certainly.
[02:50] <bjsnider> (i'm cheating, since js was chosen specifically to invite contributions)
[02:50] <RAOF> *Particularly* because there's no official documentation.
[02:51] <RAOF> It's relatively much easier to pick up i915.
[02:51] <bjsnider> 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] <bjsnider> do a lot of non-intel people contribute to i915?
[02:52] <RAOF> Yes.
[02:52] <bjsnider> to be fair though, that is not exactly on par with nvidia graphics hardware, is it?
[02:53] <RAOF> A fair number of non-AMD people contribute to radeon, too.
[02:53] <bjsnider> what about contributors who aren't being paid to do so?
[02:53] <RAOF> There are a bunch.
[02:53] <RAOF> Certainly a couple.
[02:54] <RAOF> 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] <bjsnider> edge cases?
[03:11] <bryceh> bjsnider, edge case as in a chip model that has some unique feature or implements a feature in a weird way
[03:12] <RAOF> Things like the i965 resolution change bug: (sometimes!) when changing to a lower resolution, the display would go all wonky.
[03:14] <RAOF> 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] <RAOF> Constraining the cursor so that it remains on the framebuffer fixed this.
[03:15] <RAOF> And the bug would have been significantly more difficult to diagnose if I didn't have the documentation.
[03:16] <RAOF> 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] <bjsnider> 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] <RAOF> Well, not all we need.
[03:23] <RAOF> It *would* be helpful, but we also need manpower (which is easier to acquire with documentation, though)
[04:36] <RAOF> 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] <ubot4> 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] <RAOF> Oh, hm.  That could be done in udev, by not tagging the second device with IS_KEYBOARD.
[18:06] <Sarvatt> the SUSE xserver crash handler is so nice - https://bugs.freedesktop.org/attachment.cgi?id=39285
[18:10] <jcristau> is that the patches emmes just sent?
[18:10] <jcristau> looks impressive
[18:10] <Sarvatt> oh wow they sent it upstream?
[18:11] <Sarvatt> i saw it about 6 months ago in their source packages, was meaning to try to get it going on our stuff
[18:11] <jcristau> 14193 N   Fri 08/10/2010 18:25+0200 Matthias Hopf      (1.5K) [PATCH] Create reasonable backtraces via gdb automatically
[18:11] <Sarvatt> yeah thats the same thing though
[21:00] <cnd> Sarvatt, do you know where the debian packaging for xinput is maintained?
[21:01] <cnd> I can't find it on git.debian.org
[21:01] <Sarvatt> jcristau does it outside of pkg-xorg
[21:01] <Sarvatt> one sec
[21:01] <Sarvatt> the full list takes awhile to load on this netbook :)
[21:01] <Sarvatt> http://git.debian.org/?p=users/jcristau/xinput.git;a=summary
[21:02] <cnd> ahh, ok
[21:02] <cnd> thanks!
[21:04] <cnd> Sarvatt, is there a way to tell auto-xorg-git where that repo is?
[21:04] <cnd> it seems confused :)
[21:05] <Sarvatt> yeah it doesnt work for things outside of pkg-xorg :(
[21:05] <cnd> ok, I'll hack it up so it does
[21:05] <cnd> :)
[22:55] <jcristau> i should probably get that into pkg-xorg.