| 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:40 |
|---|---|---|
| Sarvatt | guess we dont need the libgl dep anyway since it doesnt work :) | 00:41 |
| RAOF | We need to work out whether we care that we're breaking the linux OpenGL ABI. | 00:50 |
| bjsnider | why does chromium need opengl? | 01:35 |
| RAOF | Because it wants to do hardware accelerated graphics, I guess. | 01:52 |
| RAOF | Also, WebGL™ | 01:52 |
| bjsnider | thanks for the trademark | 01:53 |
| bjsnider | i was worried it wasn't trademarked but you have assuaged my fears | 01:53 |
| * 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:54 |
| RAOF | WebGL should work now, at least. | 01:55 |
| bjsnider | somebody probably once said that about opengl | 02:16 |
| RAOF | And OpenGL works now* | 02:17 |
| RAOF | *: For some values of works :) | 02:17 |
| bjsnider | i could challenge that, but it's like shooting fish in a barrel, isn't it? | 02:19 |
| bjsnider | by the way, what is mesa up to now? opengl which version? | 02:20 |
| RAOF | Mu | 02:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| RAOF | No; that's for radeon (and to a lesser extent nouveau). | 02:25 |
| RAOF | And some features are basically driver independent. | 02:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:38 |
| 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:39 |
| 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:40 |
| bjsnider | well, the nouveau guys could if it was their only goal, leaving everything else aside | 02:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| RAOF | But we can't contribute code. | 02:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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. | 02:54 |
| bjsnider | edge cases? | 03:05 |
| bryceh | bjsnider, edge case as in a chip model that has some unique feature or implements a feature in a weird way | 03:11 |
| RAOF | Things like the i965 resolution change bug: (sometimes!) when changing to a lower resolution, the display would go all wonky. | 03:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:22 |
| RAOF | It *would* be helpful, but we also need manpower (which is easier to acquire with documentation, though) | 03:23 |
| 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:36 |
| RAOF | Oh, hm. That could be done in udev, by not tagging the second device with IS_KEYBOARD. | 04:38 |
| === ara__ is now known as ara | ||
| Sarvatt | the SUSE xserver crash handler is so nice - https://bugs.freedesktop.org/attachment.cgi?id=39285 | 18:06 |
| jcristau | is that the patches emmes just sent? | 18:10 |
| jcristau | looks impressive | 18:10 |
| Sarvatt | oh wow they sent it upstream? | 18:10 |
| 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 | 18:11 |
| === ara__ is now known as ara | ||
| === ara__ is now known as ara | ||
| cnd | Sarvatt, do you know where the debian packaging for xinput is maintained? | 21:00 |
| 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:01 |
| cnd | ahh, ok | 21:02 |
| cnd | thanks! | 21:02 |
| cnd | Sarvatt, is there a way to tell auto-xorg-git where that repo is? | 21:04 |
| cnd | it seems confused :) | 21:04 |
| 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 | :) | 21:05 |
| jcristau | i should probably get that into pkg-xorg. | 22:55 |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!