| RAOF | Argh. I hate you, git, and the way “git checkout master” doesn't necessarily get you the damn master branch. | 00:49 |
|---|---|---|
| Sarvatt | i didn't realize just how bad this multiple gpu situation has gotten until i just started shopping for a new laptop.. thanks to the new intels pretty much every laptop over $500 has switchable (or optimus) graphics now. optimus is a nightmare :( | 02:11 |
| Sarvatt | everything with a newer nvidia discreet gpu and intel cpu having optimus, and not being able to explicitly pick the nvidia gpu and all | 02:14 |
| johanbr | Sarvatt, get something with an ATI? | 02:15 |
| Sarvatt | yeah trying to find a decent 13.3" with ati hybrid thats not 2k+, it's a shame those nice asus' only have nvidia | 02:17 |
| Sarvatt | either that or go back a generation before optimus | 02:17 |
| Sarvatt | but i mean it's going to be a horrible linux experience for people with nvidia now | 02:18 |
| RAOF | How does that work with the binary drivers? I mean, apart from the intel GPU not working. | 02:19 |
| Sarvatt | it doesnt from what i can see | 02:19 |
| RAOF | Joy. | 02:19 |
| Sarvatt | you only get the intel | 02:19 |
| RAOF | vgaswitcheroo won't work either, will it, because optimus is some sort of crazy abomination where the nvidia GPU renders to the scanout buffer of the intel GPU, right? | 02:21 |
| johanbr | apparently it depends on the laptop: http://www.nvnews.net/vbulletin/showthread.php?p=2291702#post2291702 | 02:25 |
| Sarvatt | too bad the blob and intel cant coexist :) | 02:28 |
| Sarvatt | hmm new blobrelease for opengl 4.1 | 02:30 |
| Sarvatt | http://developer.nvidia.com/object/opengl_driver.html#notes | 02:32 |
| Sarvatt | wonder if it snuck in xserver 1.9 support | 02:32 |
| RAOF | Gah. What has decided to eat all my goats? | 05:11 |
| RAOF | And by “goats” I of course mean “memory” | 05:12 |
| RAOF | Ah, no. Actually I mean I/O. | 05:15 |
| RAOF | The unholy trinity strikes again - ubuntuone-syncdaemon, dpkg, and btrfs. | 05:15 |
| RAOF | Who wants to buy me an Apple Magic Trackpad so I can test multitouch? :) | 06:03 |
| bryceh | heya | 06:24 |
| RAOF | Howdie. | 06:24 |
| RAOF | How's the week treated you? | 06:25 |
| bryceh | great, been on vacation at the beach the past week | 06:25 |
| RAOF | Hah! | 06:26 |
| RAOF | Sounds like fun. | 06:26 |
| bryceh | the house we were in had wireless but the password they gave didn't work, so yeah | 06:26 |
| * RAOF is sitting in front of his fan-forced gas fireplace; the office is too cold! | 06:26 | |
| bryceh | so instead mostly I played with my son and fiddled with learning how to code cairo animation stuff | 06:26 |
| RAOF | Yay! | 06:27 |
| bryceh | RAOF, how things going for you? | 06:28 |
| RAOF | I spent some of my flight home from Prague working out how to do a proof of concept gobject-introspection-sharp binder. | 06:28 |
| RAOF | Looking up, now. | 06:28 |
| RAOF | I've not only woken up after the long, long flight, I think I've also beaten the low-grade ubuflu. | 06:29 |
| bryceh | oh yeah sounds like that was going around | 06:29 |
| RAOF | I don't think I've had it like others have had it. | 06:30 |
| bryceh | that's good | 06:30 |
| bryceh | being the X guy sucks in that everyone's handing you their germy laptops to fix | 06:30 |
| RAOF | I didn't get _too_ many laptops :) | 06:31 |
| bryceh | speaking of which... did many people hand you their germy laptops? :-) | 06:31 |
| bryceh | haha, well it's all-hands you have to really watch out for. uds is pretty intense too sometimes | 06:32 |
| RAOF | Heh. | 06:33 |
| RAOF | We can tag-team next UDS. | 06:33 |
| bryceh | yup | 06:33 |
| bryceh | actually I've been doing a lot of thinking about how to restructure things to work better for us | 06:33 |
| RAOF | Hm. Do tell! | 06:34 |
| bryceh | did some X strategery thinkin | 06:34 |
| bryceh | well, sounds like we're going to have some ample X resources in place for NN, so was thinking maybe this was our chance to really get organized and on top of everything | 06:34 |
| bryceh | but to do that we'd need to be more focused in *what* we do | 06:35 |
| bryceh | I think in the past there's been so much to do that the work ends up being much more 'reactive' | 06:35 |
| RAOF | Right. There's lots of firefighting. | 06:35 |
| bryceh | however there's really no reason it *has* to be that way | 06:35 |
| RAOF | Or do you mean more “if we contribute more upstream we get to have more influence on what happens, meaning we get a better ability to plan”? | 06:36 |
| bryceh | we just need to narrow down a few points of focus and set some boundaries so we can keep the firefighting at arm's length and focus on some specific projects to make things more solid | 06:36 |
| bryceh | well, I don't think it's a matter of *contributing* to upstream so much as *throttling* it | 06:37 |
| RAOF | I think collaborating with the DX team we could really get some useful focus. | 06:37 |
| bryceh | I think a lot of our bug problems occur because we allow in upstream code that's been heavily changed without sufficient testing | 06:38 |
| bryceh | which is something we *could* switch around and do differently | 06:38 |
| bryceh | and on a completely other angle | 06:38 |
| bryceh | as I've mentioned before I think we get a lot of bug reports that really are more of the type "help me, fix my computer", rather than, "Here is a way to make X better for Ubuntu" | 06:39 |
| bryceh | so I think we need to find ways to better distinguish the latter from the former, and focus exclusively on the latter | 06:39 |
| bryceh | and another angle... | 06:41 |
| bryceh | been thinking about different ways of organizing workloads. I can think of several schemes: | 06:41 |
| RAOF | I know the QA team has a pretty serious collection of hardware which we could potentially harness for the purposes of getting testing. | 06:41 |
| bryceh | 1. One option is to handle things generally, setting priorities on the fly as work comes in | 06:42 |
| bryceh | 2. Divide things by drivers, each of us taking one or two drivers to focus on | 06:42 |
| bryceh | 3. Divide things by work *type*, e.g. packaging vs. bug triage/upstreaming vs. bug fixing vs. special projects | 06:42 |
| bryceh | 4. Divide things by hardware type, e.g. 'tier-one hardware', 'tier-two hardware', ... | 06:43 |
| RAOF | 5. Have a frontend/backend type split, if we've got access to enough people. | 06:43 |
| bryceh | yep | 06:43 |
| bryceh | anyway, a topic for discussion at next UDS | 06:44 |
| RAOF | When we'll | 06:44 |
| RAOF | (hopefull) know the sort of resources we have a available! | 06:44 |
| bryceh | or maybe we could have a Ubuntu-X online summit prior to that, just to get organized ahead of time | 06:44 |
| bryceh | right | 06:44 |
| bryceh | on another angle... I'd like to push during NN to pull in some more community members into participation. grow ubuntu-x active members | 06:44 |
| bryceh | community members have been key for getting stuff done with ubuntu-x in the past, and will continue to be so | 06:45 |
| bryceh | on another angle... more coordination with debian | 06:45 |
| RAOF | I think we're doing reasonably well with that this cycle. | 06:45 |
| RAOF | Yay! I didn't glue my hands to my face with that xserver build! | 06:46 |
| bryceh | that's good to hear, I've been pretty piss poor at that | 06:46 |
| RAOF | It may have taken more than one build to get right, though ;) | 06:46 |
| bryceh | RAOF, also the launchpad team has some nifty workflow tracking systems that I think would be interesting to try applying to the ubuntu-x team | 06:47 |
| bryceh | it's particularly useful for getting the team to focus on *fewer* projects, and to do those well | 06:47 |
| RAOF | I'm interested to hear them; jml is the most organised person I know. | 06:47 |
| RAOF | (Even moreso than *you*!) | 06:48 |
| bryceh | hehe | 06:48 |
| bryceh | true | 06:48 |
| RAOF | jml talked about “kanban” when I breakfasted with him in Prague; that seemed interesting. | 06:50 |
| RAOF | Oh, man. btrfs, I hate you. | 06:53 |
| RAOF | Ah, no. 'twas mutter! | 06:58 |
| bryceh | right | 06:59 |
| bryceh | the kanban the launchpad team's using is good for long-cycle project work | 06:59 |
| bryceh | what I've been mulling is something a bit more tightly hooked in with launchpad, so it'll work for the types of shorter-cycle work we tend to do on X | 07:00 |
| bryceh | which I think could take the place of some of the various reports and lists I've been generating, and give it a better workflowy feel | 07:01 |
| bryceh | easier to show it than explain it :-) | 07:01 |
| RAOF | Something like a list we can work through and move things into the ‘finished’ bucket? | 07:02 |
| bryceh | of course, I have to code it before that :-) | 07:02 |
| bryceh | exactly | 07:02 |
| bryceh | actually there'd be multiple buckets | 07:02 |
| bryceh | so you'd work on something and then drag it to 'finished', 'upstreamed', 'needs-qa-testing' or so on | 07:02 |
| RAOF | Right. | 07:03 |
| bryceh | so we avoid just having a list of bugs assigned to ourselves with no context or status | 07:03 |
| RAOF | We instead have a couple of lists of bugs, and the list they're in indicates what sort of action we need to take on them. | 07:04 |
| bryceh | I also want to make it publically visible so when people come to ask for us to do something we can point them to something that shows exactly how full our plate is and gives them a 'Now Serving #' ticket | 07:04 |
| RAOF | :) | 07:04 |
| bryceh | right, one set for triaging, one set for forwarding upstream, one for analyzing/fixing, one for backporting patches, etc. | 07:05 |
| RAOF | So we can start on a list that we have an appropriate energy level for. | 07:05 |
| bryceh | perhaps also integrate packaging work and blueprint tasks in there, so we can track everything in one tool | 07:05 |
| bryceh | perhaps that can also generate our weekly status reports for us ;-) | 07:06 |
| RAOF | Moar automation! Moar! | 07:06 |
| bryceh | well, that's getting a bit blue sky... the dragging stuff into buckets is coded and works, and I think would help in the NN timeframe | 07:06 |
| bryceh | well, mostly coded | 07:07 |
| RAOF | Heh. | 07:07 |
| bryceh | it's cool though, all Cairo graphics stuff, no web browser needed | 07:07 |
| RAOF | Sweet. | 07:08 |
| RAOF | Cairo is fun. | 07:08 |
| bryceh | yep | 07:08 |
| bryceh | some of the differences from how inkscape works has required a bit of re-education | 07:08 |
| bryceh | waaay better than CSS fiddling though | 07:09 |
| bryceh | and no javascript in sight :-) | 07:09 |
| RAOF | I found postscript surprisingly fun, to :) | 07:10 |
| bryceh | reverse polish notation goodness | 07:11 |
| RAOF | Stack based languages FTW! | 07:11 |
| bryceh | RAOF, btw do you have some thoughts on how we could improve how we do X maintenance in NN? | 07:20 |
| RAOF | I think that one of the things we should do is ask the DX team what they're hitting in mesa & X, and put some work into that. | 07:22 |
| RAOF | I think we should have enough resources to be able to spend some time looking at what DX are doing, and what they'd like to work, and making it happen. | 07:22 |
| * bryceh nods | 07:23 | |
| bryceh | that's a good point... internal customer needs | 07:23 |
| RAOF | Yeah. We have them :) | 07:23 |
| bryceh | I've thought we could be better tied in with the technical support team as well | 07:24 |
| RAOF | And the QA team, I think, too. | 07:24 |
| bryceh | yeah, although I don't think we have an X person on the QA team side | 07:24 |
| RAOF | For example, did you know that unity has hand-written shaders because the mesa GLSL compiler produces broken shaders for what they wanted to do? | 07:24 |
| bryceh | we did do pretty well with Ara for testing though in lucid | 07:25 |
| RAOF | Yeah. | 07:25 |
| bryceh | ouch | 07:25 |
| RAOF | Oh, and unity just doesn't run at all on (at least) r600? | 07:25 |
| bryceh | is that just hw acceleration lackage? | 07:26 |
| RAOF | I'm not sure. It should be falling back more gracefully than it is, though. | 07:27 |
| bryceh | this gets back to my thinking about setting boundaries... i.e. we support thus and such feature on this and thass hardware | 07:27 |
| bryceh | and where there is a discrepancy between what we *think* we support and what we actually deliver, that becomes priority areas for us | 07:27 |
| RAOF | Right. RH basically wants a mesa sufficient to run gnome-shell, and prioritises that; once we've got the X resources, we should do something similar for unity. | 07:28 |
| RAOF | I think it might also be nice to be able to push code at the suite of QA machines, wherever they are, before it goes into the main archive. | 07:30 |
| bryceh | yep | 07:31 |
| bryceh | we've GOT to get something in place for automated testing of the X stack, even if it only has a slight coverage | 07:31 |
| RAOF | I wonder if the kernel would be interested in that too, actually. | 07:31 |
| bryceh | that's something I've been picking at for years but never really hammered into useful shape | 07:31 |
| RAOF | I'm pretty sure that QA *does* have a bunch of automated testing; it's just opaque to me. | 07:31 |
| bryceh | true, there's enough overlap here we could probably collaborate on it | 07:32 |
| bryceh | yeah I've described to them the types of reports that would be useful to me | 07:32 |
| RAOF | At the rally someone was asking about what numbers to look for in the X memory stats to indicate a leak, for example. | 07:33 |
| bryceh | like a performance chart run bi-weekly | 07:33 |
| RAOF | Yeah. | 07:34 |
| Dr_Jakob | If it is suposed to do any good you need to run it continiously... | 07:34 |
| Dr_Jakob | A lot of stuff can go into mesa in two weeks. | 07:34 |
| * RAOF always gets twice- & bi- confused :) | 07:35 | |
| bryceh | Dr_Jakob, not a chart of upstream git commits, but rather what is in Ubuntu | 07:35 |
| bryceh | we tend not to update mesa quite that frequently, so... ;-) | 07:36 |
| bryceh | but daily performance numbers would be lovely | 07:36 |
| bryceh | or even more frequently. | 07:36 |
| Dr_Jakob | We need something like Linaro but only for graphics. | 07:37 |
| bryceh | isn't that what X.org is? ;-) | 07:38 |
| Dr_Jakob | X.org doesn't have any developers. | 07:38 |
| bryceh | sure they do | 07:39 |
| bryceh | else where would all these bugs be coming from? | 07:39 |
| Dr_Jakob | Not hired/given to X.org... | 07:39 |
| bryceh | anyway, my point is structurally the organization exists | 07:39 |
| bryceh | what's lacking is the business case for putting funding / head-count towards manning it | 07:40 |
| bryceh | although a number of companies contribute heads towards development work anyway | 07:40 |
| Dr_Jakob | That whats always boggles my mind, the UI is like the most fundamental thing of the OS yet it always gets the short end of the stick. | 07:41 |
| * bryceh nods | 07:41 | |
| bryceh | kernel gets all the luv | 07:41 |
| bryceh | most linux-oriented companies have mostly just been focused on server business cases | 07:42 |
| bryceh | so X is sort of a nicety for them | 07:42 |
| bryceh | not something which drives profitability | 07:42 |
| Dr_Jakob | Myeah, tho the feel I get from Ubuntu its that its mostly a desktop outfit, yet your the one contributing the least to X.. | 07:43 |
| bryceh | how do you count 'contributing'? | 07:45 |
| Dr_Jakob | Also I should have probably said "Linaro for 3D" instead of X, the priorities from all the hired devs seems to be Modesetting first 3D last. | 07:45 |
| RAOF | Well, Chase has been contributing a bunch of multitouch patches, but I'm not sure how much that's in his own time. You're right, we don't have a lot of X hackers. | 07:45 |
| RAOF | xorg-edgers seems to be quite a useful contribution :) | 07:46 |
| Dr_Jakob | Again I probably should have said 3D instead of X, where I spend most of my time. | 07:46 |
| RAOF | Damn. Attaching gdb to mutter caused it to unfreeze :( | 07:47 |
| RAOF | Even there, xorg-edgers seems to provide a bunch of testers for the bleeding-edge mesa, some of which appear to file useful bugs/hang on IRC in useful ways. | 07:48 |
| RAOF | It's not the same as providing *code* to mesa. | 07:49 |
| Dr_Jakob | Yeah, xorg-edgers is nice for bug reports. | 07:49 |
| Dr_Jakob | but yeah code is nicer, especially tested code. | 07:50 |
| Dr_Jakob | s/tested/debugged/ | 07:50 |
| RAOF | Hah. | 07:50 |
| RAOF | We might be able to direct some people towards contributing code, too, but mesa & X is not particularly amenable to drive-by contributions. | 07:51 |
| Dr_Jakob | The problem is you deal with compilers, asyncorness system, network code, virtual memory and non-fault tolerent hardware. | 07:52 |
| Dr_Jakob | Graphics code probably has the highest cost per line of code. | 07:52 |
| Dr_Jakob | yeah | 07:52 |
| bryceh | Dr_Jakob, it's interesting you emphasize _tested_, and goes to my point. ubuntu-x does a heapload of testing, but since testing does not show up in git changelogs, we earn zero credit for the work | 07:53 |
| bryceh | someone contributing half a dozen git commits of untested buggy code gets more credit than any amount of testing/bug fixing/bug forwarding done at our end | 07:54 |
| Dr_Jakob | bryceh: I revised it "debugged" that includes fixing the problem :) | 07:54 |
| Dr_Jakob | it to* | 07:55 |
| bryceh | Dr_Jakob, the one thing you miss is "debugged *and delivered to users*" | 07:56 |
| bryceh | fixes do little good to you if they're sitting in some remote git tree | 07:57 |
| Dr_Jakob | I'm not saying you haven't done anything, I'm saying we can always need more people doing work on the drivers. | 07:57 |
| bryceh | er, you said "you're the one contributing the least to X" | 07:57 |
| bryceh | them's fightin' words ;-) | 07:58 |
| bryceh | (and a bad yet quite popular meme) | 07:58 |
| Dr_Jakob | vs RedHat & Novel yes. | 07:58 |
| RAOF | As long as you measure by LoC, certainly. | 07:59 |
| Dr_Jakob | Actually I don't really know what Novel does for X, so maybe they are just as bad.. | 07:59 |
| Dr_Jakob | Does Fedora have bleeding edge as well? | 08:00 |
| RAOF | Fedora kindof _is_ bleeding edge, but I'm not aware of anything like xorg-edgers there. | 08:00 |
| === yofel_ is now known as yofel | ||
| superm1 | RAOF, could you help me to understand what the negative implications are for running a system that supports KMS with fbdev for 2D stuff? Are there any? | 21:52 |
| superm1 | eg, lets say it's an intel system, and modesetting is enabled, but we choose to run X with fbdev | 21:52 |
| bryceh | superm1, lack of 3D is the main thing | 21:54 |
| superm1 | bryceh, so for say trying to come up with a more stable installation though, no real negative implications then | 21:55 |
| bryceh | superm1, you might also check video, like if Xv is available | 21:55 |
| superm1 | i'm looking at on recovery media forcing to vesa / fbdev for installation only maybe | 21:55 |
| bryceh | that's probably fine | 21:56 |
| superm1 | especially knowing there is a mess of problems with sugar bay stuff right now that might not necessarily be fixed by the time maverick launches | 21:56 |
| superm1 | okay cool thanks. i've added it as a configurable option in ubiquity | 21:57 |
| superm1 | debconf option is ubiquity/force_failsafe_graphics | 21:58 |
| * bryceh nods | 21:58 | |
| bryceh | we've used fbdev for the failsafe-x stuff | 21:58 |
| superm1 | the only real problem then is if the HW fails at modesetting, still need to patch initial kernel command line to nomodeset :) | 21:59 |
| bryceh | yeah | 21:59 |
| superm1 | it would be nice if there was actually a way to prod something in sysfs or procfs to turn on and off modesetting | 21:59 |
| bryceh | you could check if xrandr can be used from a fbdev session | 21:59 |
| bryceh | superm1, you could chat with one of the kernel guys, I'd spoken to them last UDS about making configuration of kms settings easier, and they seemed to already know of some plans afoot | 22:01 |
| superm1 | oh rlly? that would certainly be nice | 22:01 |
| superm1 | looks like you're right, xrandr doesn't work when you are booted with fbdev | 22:02 |
| superm1 | fortunately that shouldn't be too necessary during install | 22:02 |
| bryceh | ok yeah I suspected that | 22:02 |
| bryceh | oh, power saving stuff might also not be available with fbdev | 22:03 |
| bryceh | or at least screen blanking | 22:03 |
| superm1 | okay, that shouldn't be too big a deal either then | 22:04 |
| bryceh | superm1, specifically we were talking about making it easier to add quirks and to toggle debugging stuff, and they told me about the kernel getting support for having a loadable data nodule where you can set quirks and toggle parameters like the chosen resolution, and then pass that to the kernel | 22:05 |
| bryceh | it was a bit hand wavy, and I didn't follow up so dunno what the status is | 22:05 |
| bryceh | however I think it is exactly the sort of thing you guys will find useful for quirking/configuring some of this stuff | 22:05 |
| superm1 | ah, but that would still be stuff that was passed on the kernel command line then i take it | 22:05 |
| superm1 | oh wait, but loadable data module, maybe not | 22:06 |
| bryceh | I'm not sure what the exact interface is for it, might be sysfs | 22:06 |
| superm1 | who was it you were chatting with about this? i should just ping 'em and see | 22:06 |
| bryceh | andy mainly, chase and ogasawara were there too. | 22:06 |
| Sarvatt | superm1: as long as we get mesa 7.9 in sugar bay should be fine (famous last words..) | 23:21 |
| Sarvatt | then again there's still all kinds of problems with panels using eDP | 23:22 |
| Dr_Jakob | Sugar Bay? | 23:24 |
| Sarvatt | yeah next intel platform coming out with sandybridge cpu/gpu | 23:24 |
| Sarvatt | i6 | 23:25 |
| Dr_Jakob | Ah | 23:25 |
| Sarvatt | new socket yet again :( | 23:25 |
| Sarvatt | superm1: i bet you guys at dell are loving the fact that all intel laptops with nvidia GPU's will be unable to use the discreet gpu for a looong time in linux huh? | 23:28 |
| superm1 | wha? | 23:30 |
| superm1 | did I miss something? | 23:30 |
| Sarvatt | optimus | 23:30 |
| superm1 | oh, when there are multi nvidia gpu setups | 23:30 |
| superm1 | you can at least use one of the GPUs still | 23:31 |
| Sarvatt | only the intel, its an abomination where the nvidia gpu renders into the intel and i haven't seen any that let you pick one or the other in bios or via acpi yet so you're stuck with only the intel graphics built into the cpu | 23:32 |
| superm1 | oh yuck, i didn't realize it was that bad | 23:32 |
| Sarvatt | the old type of hybrids work somewhat but these optimus ones are nasty | 23:33 |
| superm1 | none of the platforms that have come by my group have actually had that stuff yet | 23:34 |
| Sarvatt | oh looks like alienware m11x is the only laptop with nvidia graphics on dell.com at the moment from a quick glance | 23:39 |
| superm1 | i know most of the machines that have it, but i haven't kept up on release dates, so i probably shouldn't say much beyond that | 23:41 |
| Sarvatt | I'll probably be working with those same machines here soon :) | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!