| thomi | RAOF: maybe. Unity has binary deps on lots of other things though, so you often can't release libdee (for example), unless you release the rest of the stack at the same time | 00:03 |
|---|---|---|
| RAOF | Oh, that totally makes sense. | 00:03 |
| robert_ancell | RAOF, do you know who I can talk to about lightdm still being in proposed? The one in main has a serious bug | 01:48 |
| RAOF | robert_ancell: Probably most people in #ubuntu-release? | 01:49 |
| robert_ancell | RAOF, ta | 01:49 |
| RAOF | I'd expect a random archive admin to know. | 01:49 |
| mlankhorst | RAOF: oh btw can lts-raring and mesa in raring be promoted to -updates? :P | 01:52 |
| duflu | robert_ancell: Could you do me a favour? | 02:12 |
| robert_ancell | duflu, sure | 02:13 |
| duflu | robert_ancell: Change the "development focus" to 0.9.11 on https://launchpad.net/compiz | 02:13 |
| duflu | ? | 02:13 |
| robert_ancell | duflu, done | 02:13 |
| duflu | robert_ancell: Thanks | 02:14 |
| Sarvatt | mlankhorst: that was extra annoying, finding out it was in -proposed after recommending it to people instead of edgers :) | 02:17 |
| Sarvatt | mlankhorst: but infinity was talking about making daily builds work so "any day now" | 02:18 |
| olli | RAOF, hey | 04:32 |
| RAOF | olli: Yo! | 04:32 |
| olli | just wanted to say thanks for proposing all the patches over the weekend | 04:32 |
| olli | :) | 04:32 |
| olli | seems like the intel one got the most traction so far | 04:33 |
| RAOF | Well, the most reaction at least :) | 04:34 |
| olli | RAOF, true | 04:37 |
| olli | so, it seems like we have missed all major upstream releases (at least Mesa and X iirc) | 04:38 |
| olli | not sure if "missed" is the right term | 04:38 |
| * duflu wanders off to lunch | 04:39 | |
| olli | enjoy duflu | 04:39 |
| olli | RAOF, how will we ship these in 13.10 then? | 04:39 |
| RAOF | By patching? | 04:39 |
| RAOF | Same way we did XI2-multitouch? | 04:39 |
| olli | heh, the amount of "?" indicates I was asking a stupid question ;) | 04:41 |
| olli | will you have to maintain 2 versions of the patches then, one for Mesa/X/... at 13.10 and one for the respective latest version | 04:41 |
| olli | will that be a big delta, if at all? | 04:41 |
| RAOF | Depends on how things change underneath. | 04:48 |
| RAOF | The patch as-of 13.10 though probably won't need _too_ much support that isn't simple backporting. | 04:49 |
| tvoss | RAOF, ping | 05:22 |
| RAOF | tvoss: Yo. | 05:22 |
| tvoss | RAOF, good morning :) got some time in your voip lair? | 05:22 |
| RAOF | Sure. | 05:22 |
| RAOF | My new, improved, VoIP lair! | 05:23 |
| tvoss | RAOF, \o/ let me grab coffee | 05:25 |
| tvoss | RAOF, can you open a hangout and add me to it, would like to join on the ipad | 05:27 |
| didrocks | kgunn: just to reash, I'm not thrilled to drop 50% of our testing, and just having one machine with "a workaround" to get Mir starting | 05:43 |
| didrocks | rehash | 05:43 |
| didrocks | RAOF: hey, you confirm that the ati issue isn't due to lxc, but a real issue, right? | 05:44 |
| RAOF | didrocks: Yeah, looked like it. | 05:45 |
| didrocks | RAOF: if you need access to the machine, we can provide you that | 05:45 |
| * didrocks is seeing that we diminish more and more on Mir quality side "just" to ship in universe | 05:46 | |
| tvoss_ | didrocks, how many machines can we provision in the lab to start mir? | 06:49 |
| didrocks | tvoss_: 2 right now | 06:50 |
| tvoss_ | didrocks, why not more? it is my understanding that we have 2 ati, 2 intel and 2 nvidia machines | 06:50 |
| didrocks | tvoss_: we have that since yesterday | 06:50 |
| tvoss_ | didrocks, what gpu is running in the two machines? | 06:50 |
| didrocks | tvoss_: we just need to provision the nvidia | 06:50 |
| didrocks | one intel, one ati | 06:50 |
| didrocks | tvoss_: the 3 others are for raring | 06:51 |
| tvoss_ | didrocks, why do we need them for raring? | 06:51 |
| didrocks | tvoss_: because we support our users? | 06:51 |
| didrocks | so we do have SRUs everyday | 06:51 |
| tvoss_ | didrocks, sure, but I thought we could just reprovision them with a different Ubuntu version? | 06:51 |
| didrocks | tvoss_: no, we need kernel == container | 06:51 |
| didrocks | tvoss_: the machines are the same anyway, between the ati, intel and nvidia FYI | 06:52 |
| tvoss_ | didrocks, okay, I was told some time back that we have he/le ati, he/le nvidia, he/le intel | 06:52 |
| didrocks | maybe you are not mentionning the same machines then | 06:52 |
| didrocks | because the 3 others arrived this week | 06:52 |
| didrocks | and we only have 3 until then | 06:53 |
| tvoss_ | didrocks, that might well be | 06:53 |
| tvoss_ | didrocks, so which machine is causing issues? the ati one? | 06:53 |
| didrocks | yep | 06:53 |
| tvoss_ | didrocks, intel and nvidia come up cleanly? | 06:53 |
| didrocks | tvoss_: well, nvidia is on raring (one of the 3 we had) | 06:53 |
| didrocks | we need to wire up the other one | 06:53 |
| didrocks | on intel, it was failing as well | 06:53 |
| didrocks | and we needed my workaround | 06:53 |
| didrocks | the sleep :/ | 06:53 |
| didrocks | I got a "we never see it" | 06:54 |
| didrocks | then, when I gave the description, starting to see devs telling they saw it | 06:54 |
| didrocks | and "just" reboot :/ | 06:54 |
| didrocks | we need to change that behavior | 06:54 |
| tvoss_ | didrocks, as far as I know we do not see those issues in the cert lab | 06:54 |
| didrocks | tvoss_: so, we are inventing the issues? | 06:55 |
| didrocks | "not seen here" -> then, when opening "oh btw, I saw it some times" | 06:55 |
| didrocks | regular rules | 06:55 |
| tvoss_ | didrocks, of course not, I'm just trying to track down the issue | 06:55 |
| tvoss_ | didrocks, can I get access to the ati machine? | 06:55 |
| didrocks | tvoss_: see the bug report, RAOF already dived to it | 06:56 |
| didrocks | tvoss_: yeah, once daily are finished, I can give you access | 06:56 |
| tvoss_ | didrocks, ack, can you paste the bugreport again? | 06:56 |
| tvoss_ | didrocks, my backlog is a bit fucked up after numerous reboots | 06:56 |
| didrocks | tvoss_: bug #1203070 | 06:56 |
| ubot5 | bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] https://launchpad.net/bugs/1203070 | 06:56 |
| didrocks | Chris told: "it's failed to create the hw cursor buffer, and I don't believe that there are any more relevant logs | 06:57 |
| didrocks | available." | 06:57 |
| tvoss_ | mlankhorst, ping | 07:00 |
| mlankhorst | pong! | 07:04 |
| tvoss_ | mlankhorst, hey there :) we are trying to solve an issue with Mir failing to create a hardware cursor buffer on ati. | 07:08 |
| tvoss_ | mlankhorst, I wonder if you are aware of any known ati issue in that area? | 07:08 |
| mlankhorst | erm cursor usually has special requirements for buffer | 07:09 |
| tvoss_ | mlankhorst, okay, the call succeeds in general, we only have an issue on one specific card. Is there any way to get something like a last error from gbm? | 07:30 |
| mlankhorst | use the debugger(TM) | 07:31 |
| tvoss_ | mlankhorst, woot, thanks for the enlightenment ;) | 07:32 |
| mlankhorst | it's what it's for :P | 07:32 |
| duflu | alf__: How do you guarantee that only one compositor buffer is consumed per 16ms in the multimonitor stuff? Is it still partial releases? | 08:05 |
| duflu | ... or yet to be figured out? | 08:07 |
| alf__ | duflu: there is no guarantee for that atm | 08:09 |
| duflu | alf__: OK, I thought I might be too early. When you have an idea, please let me know | 08:10 |
| alf__ | duflu: hmm, sorry, there is a partial guarantee | 08:10 |
| duflu | alf__: Saved resources? | 08:11 |
| duflu | alf__: I would suggest enforcing that compositor_acquire only happens for real on one monitor (which must also have the highest refresh rate of all monitors) | 08:13 |
| duflu | Probably #0. And recycle till that monitor refreshes again | 08:13 |
| alf__ | duflu: about partial release... essentially the first release of a buffer marks its end as a preferred buffer for next acquisitions. Since under normal operation this happens once per ~16ms, the consumed once per 16ms is enforced. | 08:15 |
| alf__ | duflu: (more or less) | 08:15 |
| duflu | alf__: I know but that won't be true under bypass, so I'm hunting for a more robust guarantee | 08:15 |
| duflu | Under bypass, two compositors are held and one consumed, per 16ms | 08:16 |
| alf__ | duflu: Couldn't we just have a differently constructed BufferStream for bypass, that doesn't enforce the MultiAcquisition policies? | 08:19 |
| duflu | alf__: Yes. However I suspect that will cause the client to get buffers at Nmonitors*60Hz | 08:21 |
| duflu | Which is fine for me with one monitor right now. Not fine for working with multimonitor | 08:21 |
| RAOF | Dear POSIX: signals are hateful, and | 08:23 |
| RAOF | I hate you. | 08:23 |
| hikiko | hi | 08:24 |
| hikiko | question | 08:24 |
| duflu | alf__... So before it becomes a problem I would like to see some more explicit distinction between buffer recycling and guaranteed buffer advancement | 08:25 |
| alf__ | duflu: I haven't really thought about this yet, but perhaps using a combination of a different back buffer strategy in BufferStream plus a different CompositingStrategy (note, renamed to DisplayBufferCompositor in proposed MP), which we need anyway, perhaps we could reach the needed behavior. Hopefully we won't need to have a single behavior that works for both normal and bypass, if that means making compromises for both. | 08:25 |
| hikiko | alf__, I tried to use the mir buffers as you said but I am not sure if you can fill the ipc package using those buffers | 08:25 |
| alf__ | hikiko: what method are you referring to? | 08:28 |
| hikiko | fill_ipc_package in platform alf__ | 08:28 |
| alf__ | hikiko: well, the plan is to relay this request to the native platform to do this for you | 08:29 |
| RAOF | Who thought that having read() able to return EINTR at any point and *partially* consume the buffer was a good idea? >:( | 08:32 |
| duflu | RAOF: Before threads were invented/common... | 08:32 |
| duflu | Though arguably, retrying I/O is less error prone than expecting programmers to do threads reliably | 08:33 |
| RAOF | And who didn't want to make libc go to the effort to *not* consume the buffer in that case? | 08:33 |
| RAOF | Yeah, but you can't retry IO. You need to keep track of how much was actually read, and then try to read the rest. | 08:33 |
| RAOF | Because *that's* totally not going to be done badly, and couldn't be sensibly implemented in the goddamned system library. | 08:34 |
| hikiko | I don't create a native and a nested platform at the same time alf__ either native or nested | 08:34 |
| RAOF | Not that this is *necessarily* the cause of output delay, just that I hate noticing things that are going to explode when a SIGIO comes in at an inopportune time. | 08:38 |
| alf__ | hikiko: the nested platform should create and use an instance of a specially configured native platform, see second paragraph of mir-on-mir mir-devel email reply | 08:38 |
| hikiko | ok | 08:39 |
| hikiko | I forgot to re-add this :p | 08:40 |
| hikiko | sorry :) | 08:40 |
| deathcrawler | Current Ubuntu Phone images uses Mir directly? | 08:40 |
| mlankhorst | RAOF: sigh | 08:44 |
| mlankhorst | I'm getting reports about mir now.. | 08:44 |
| mlankhorst | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1201028 | 08:44 |
| ubot5 | Launchpad bug 1201028 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in raise()" [Undecided,New] | 08:44 |
| RAOF | mlankhorst: I don't know what you're talking about officer. Mir couldn't cause *any* problems at all. See, we've corraled him in a PPA where he's kept safe from the masses! | 08:45 |
| mlankhorst | the bugs get filed against xorg-server though, what should I do with them? | 08:46 |
| mlankhorst | I just want them not be against xorg-server for now, i don't care if I close it as invalid or reassign to mir :P | 08:47 |
| duflu | That's odd. There should be no automatic reports when users (like that one) are using a PPA | 08:47 |
| RAOF | mlankhorst: Feel to reassign to the xmir project. duflu set that one up :) | 08:48 |
| mlankhorst | link? | 08:49 |
| * duflu assigned it | 08:49 | |
| duflu | mlankhorst: Launchpad project "xmir" | 08:49 |
| mlankhorst | https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.searchtext=mir&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= | 08:49 |
| mlankhorst | but I'll reassign all then | 08:51 |
| duflu | Oh, I was reassigning. But OK | 08:54 |
| alf__ | deathcrawler: not yet (it still uses surfaceflinger) but we are getting close to switching | 09:02 |
| === jono is now known as Guest19501 | ||
| tvoss_ | RAOF, disabling sigio event reporting in X is great, works fine here ;) | 09:20 |
| deathcrawler | alf__: Thanks | 09:47 |
| duflu | Oh dear. My diff is now over 4kloc to trunk. This is a worry | 10:42 |
| RAOF | tvoss_: Oh, disabling sigio events avoids the bug? | 10:57 |
| tvoss_ | RAOF, nope | 10:57 |
| tvoss_ | didrocks, alf__ https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 | 12:17 |
| alf__ | tvoss_: looking | 12:18 |
| alf__ | tvoss_: what does the waitpid (pid, NULL, 0) call do after PTRACE_ATTACH? | 12:27 |
| tvoss_ | alf__, it waits for the child process to be stopped as a result to the parent attaching. that should help us avoid a lot of races | 12:28 |
| ogra_ | LOL | 12:33 |
| ogra_ | http://www.indiegogo.com/projects/support-ubuntu-edge-enthusiast | 12:33 |
| ogra_ | awesome | 12:33 |
| ogra_ | oops, i'm not in -touch, sorry | 12:34 |
| tvoss_ | ogra_, still great :) | 12:34 |
| alf__ | tvoss_: is this because of WUNTRACED also return if a child has stopped (but not traced via ptrace(2)). Status for | 12:36 |
| alf__ | traced children which have stopped is provided even if this option is not speci‐ | 12:36 |
| alf__ | fied. | 12:36 |
| tvoss_ | alf__, yes, partly and PTRACE_ATTACH really is what we want to do here | 12:37 |
| alf__ | tvoss_: I guess my question is what guarantees that we have that waitpid(..., 0) is notified about the stopped child (normally waitpid() only gets termination events). | 12:40 |
| tvoss_ | alf__, that's the usual flow of ptrace_attach and then waitpid | 12:41 |
| alf__ | tvoss_: ok, I am not familiar with it, and the manpages are not very clear, but if it works then great :) | 12:42 |
| tvoss_ | alf__, tests pass and I haven't seen any flakyness locally | 12:42 |
| mlankhorst | oh darn, I had the mir ppa enabled still.. | 13:54 |
| mlankhorst | might have been why my nv50 was still not working after fixing all the card bugs :> | 13:57 |
| kgunn | mlankhorst: are you free to help with ati debug wrt this "unable to provision hw cursor" ?...we have a QA machine on which this is consistently failing 100%, didrocks can help provide access | 14:10 |
| kgunn | its blocking mir entering universe | 14:10 |
| kgunn | robotfuel: ^ let's see if mlankhorst can help | 14:11 |
| mlankhorst | kgunn: sure ;P | 14:15 |
| mlankhorst | what kind of hw btw | 14:15 |
| hikiko | question: do we have an env variable for the platform already? I'd like to see if my native platform is gbm or android at runtime without ifdef and maybe getenv is an option.. | 14:16 |
| kgunn | mlankhorst: https://bugs.launchpad.net/mir/+bug/1203070 | 14:17 |
| ubot5 | Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] | 14:17 |
| kgunn | "cedar" | 14:17 |
| kgunn | tvoss_: ^ | 14:19 |
| tvoss_ | kgunn, yup | 14:19 |
| mlankhorst | mmm lets see | 14:28 |
| mlankhorst | kgunn: that's only starting with unity-system-compositor from ppa:mir-team/unity-system-compositor right? | 14:30 |
| kgunn | mlankhorst: well, this may be a didrocks build, via his daily ppa (not necessarily exactly system-compositor-testing) | 14:32 |
| mlankhorst | mm lets try anyway.. | 14:32 |
| didrocks | kgunn: mlankhorst: to ensure to run the same version, use those from ppa:ubuntu-unity/daily-build-next | 14:32 |
| mlankhorst | ok, upgrading | 14:34 |
| tvoss_ | mzanetti, ping | 14:35 |
| mzanetti | tvoss_: pong | 14:35 |
| tvoss_ | mzanetti, soemthing weird going on here: https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1415/console | 14:35 |
| mzanetti | tvoss_: hmm... seems to be the same as last time | 14:36 |
| mzanetti | tvoss_: I wonder why this is build on ps-android-sandybridge. That seems wrong | 14:36 |
| mzanetti | tvoss_: as that's the machine where the devices for testing are attached | 14:36 |
| mzanetti | tvoss_: yeah. this definitely seems wrong to me. who sets up Mir jobs usually? | 14:40 |
| kgunn | hikiko: should be easy to add...i would think you could check if gralloc is present | 14:41 |
| tvoss_ | mzanetti, same happens for clang: https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1300/console | 14:42 |
| tvoss_ | mzanetti, not sure, thomi perhaps? | 14:43 |
| tvoss_ | alf__, ^ can you help here? | 14:43 |
| mzanetti | tvoss_: hmm... not sure why the one on kinnara fails. that should work. | 14:43 |
| mzanetti | tvoss_: I contacted fginther. he's in a phone call right now. when he's free again we'll try to resolve it asap | 14:44 |
| hikiko | yes I've added kgunn I just wonder if we already used one because I couldn't find any | 14:44 |
| alf__ | hikiko: why do you need to get the native platform type? | 14:44 |
| hikiko | because my nested platform has a pointer to the native platform in order to call native functions when necessary | 14:44 |
| hikiko | and I have to initialize that pointer to a new GBM or a new Android platform | 14:45 |
| hikiko | (the pointer is mg::Platform) | 14:45 |
| tvoss_ | hikiko, I thought the idea is that the nested platform does not need to know those details? | 14:45 |
| hikiko | it won't know | 14:46 |
| hikiko | then it will use the mg::Platform functions | 14:46 |
| hikiko | but at some point I have to initialize the mg::Platform | 14:47 |
| tvoss_ | hikiko, isn't it like auto platform = mg::NestedPlatform()? | 14:47 |
| alf__ | hikiko: you can do it that the same way we get the platform currently, by exposing a symbol in the native platform library (e.g. create_native_platform_nested(...)) | 14:47 |
| hikiko | I call create_platform_nested() :s | 14:48 |
| hikiko | but even the current create_platform | 14:48 |
| hikiko | returns a GBMPlatform in GBM case | 14:48 |
| hikiko | and an Android in case of android | 14:48 |
| hikiko | return std::make_shared<mgg::GBMPlatform>(report, vt); | 14:49 |
| hikiko | you specify that your pointer is mgg::GBMPlatform | 14:49 |
| mlankhorst | kgunn: hm tons of fun spam in dmesg...... | 14:50 |
| alf__ | hikiko: Isn't that what you need? The native platform knows what to do when you call create_native_platform_*(...). It creates an appropriate mg::Platform pointer and sends it back to you. | 14:50 |
| mlankhorst | kgunn: http://paste.debian.net/18047/ | 14:50 |
| mlankhorst | though no idea why.... | 14:50 |
| hikiko | yes but in create_platform* you specify what type of platform this is | 14:51 |
| hikiko | you can't have a mg::Platform pointer without initialize it with new GBM or new Android | 14:51 |
| kgunn | mlankhorst: do we need to contact radeon guys? | 14:51 |
| mlankhorst | but I guess that's what causes your issue here | 14:51 |
| hikiko | you either have to do ifdef "GBM"... | 14:51 |
| mlankhorst | kgunn: I think so.. | 14:51 |
| hikiko | or get the platform at runtime | 14:51 |
| hikiko | using getenv for example | 14:51 |
| kgunn | mlankhorst: do you have a contact ? (i'm supposing you already have :) | 14:52 |
| mlankhorst | kgunn: that was with drm-next + drm-fixes of today :P | 14:52 |
| hikiko | create_platform returns a different pointer in gbm and in android case | 14:52 |
| mlankhorst | I guess #radeon would work, brb buying some food | 14:52 |
| kgunn | ta | 14:52 |
| alf__ | hikiko: that's what create_native_platform_nested() will do also, no difference in the mechanism, just in the way the native platform is set up internally | 14:53 |
| mlankhorst | that was a merge of drm-next + drm-fixes, dno how representive that is :P | 14:53 |
| mlankhorst | hm i should probably try with a cleaner kernel later just in case | 14:53 |
| hikiko | alf__, I am talking about the create_platform_nested implementation | 14:53 |
| hikiko | mmm | 14:53 |
| hikiko | I mean that | 14:54 |
| hikiko | even if create_native_platform_mnested | 14:54 |
| hikiko | lives in GBMPlatform | 14:54 |
| hikiko | it has to return a GBMPlatform pointer | 14:54 |
| hikiko | ah :) sec | 14:54 |
| hikiko | lol ok :) mg::Platform lala = create_native... yeah... got it... :P | 14:56 |
| hikiko | <-tired :p ok, ignore :) | 14:56 |
| hikiko | thanx! | 14:57 |
| hikiko | I wrote the func and forgot to use it 2 times today :p | 14:57 |
| tvoss_ | greyback, ping | 15:05 |
| greyback | tvoss_: pong | 15:05 |
| mlankhorst | kgunn: ugh, was lacking pm firmware | 15:27 |
| kgunn | mlankhorst: pm == power management ?? (e.g. pmic ) | 15:28 |
| mlankhorst | yeah | 15:28 |
| kgunn | mlankhorst: oh...yeah...so hw mouse would be like one of the first hw accelerators i suppose | 15:28 |
| kgunn | in terms of sw trying to use it | 15:28 |
| mlankhorst | indeed | 15:29 |
| mlankhorst | so I guess you should check dmesg, just in case | 15:29 |
| kgunn | mlankhorst: so, where does that lie in the field of responsibility ?....is that a ubuntu saucy foundational problem ?...or? | 15:30 |
| mlankhorst | kgunn: heck check dmesg on that machine, then you know for sure | 15:30 |
| kgunn | mlankhorst: mmm, but X worked ? | 15:30 |
| kgunn | gotta run | 15:31 |
| mlankhorst | x can fallback to unaccelerated | 15:31 |
| kgunn | brb | 15:31 |
| kgunn | mlankhorst: ok...back, so "we" mir team need to add in fallback for sw cursor for xmir/radeon ? | 15:52 |
| kgunn | bschaefer is this something you could look pre-australian time ? ^ | 16:00 |
| kgunn | didrocks can give bschaefer access to machine if needed | 16:00 |
| bschaefer | kgunn, whats going on? The sw cursor thing? | 16:01 |
| kgunn | bschaefer: yeah | 16:01 |
| kgunn | https://bugs.launchpad.net/mir/+bug/1203070 | 16:01 |
| ubot5 | Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] | 16:01 |
| kgunn | basically we know the problem....we need to create a solution & test it | 16:01 |
| bschaefer | kgunn, possibly, i've a few other things ive to work on :) | 16:03 |
| didrocks | kgunn: sure, tell me once you need the access so that I can prepare | 16:03 |
| kgunn | bschaefer: no prob...if you're helping robotfuel keep doing that | 16:03 |
| kgunn | no pointing in switching just for the sake of it | 16:03 |
| bschaefer | kgunn, no, i do unity-maintenance under bregma and i've some new ibus changes I need to get landed | 16:03 |
| kgunn | greyback: curious...you said unity8 now (w/ some caveats/bugs) runs on mir....do the instructions on the wiki need to change ? | 16:03 |
| kgunn | or does it all just magically stay relevant ? | 16:04 |
| bschaefer | kgunn, if I can finish that up quickly I could possibly take a look :) | 16:04 |
| greyback | kgunn: which instructions? Let me check through them | 16:04 |
| kgunn | bschaefer: ah...ibus...yeah...kinda critical :) | 16:04 |
| kgunn | greyback: https://wiki.ubuntu.com/Touch/Testing/Mir | 16:04 |
| bschaefer | kgunn, yeah, as some would like the new version landed, but that SW fallback cursor is also critcal! | 16:05 |
| greyback | kgunn: hmm, so that URL to s-jenkins is an internal url only, so no community people will be able to use it. | 16:05 |
| * bschaefer goes to work fast | 16:06 | |
| greyback | kgunn: other bits could be updated, yes. I'll add it to my list | 16:06 |
| kgunn | greyback: doh...good point | 16:06 |
| kgunn | np...in due time | 16:06 |
| greyback | kgunn: ack | 16:06 |
| kgunn | greyback: crap...can you shoot me the link to your sketchpad of "todo's" closed it before saving link | 16:08 |
| greyback | kgunn: sure: http://studio.sketchpad.cc/UFFAX8fxc2 | 16:09 |
| kgunn | greyback: one more interrupt, does "Use actual surfaces instead of screenshots for window management" actually address my "cut corners" blueprint ? | 16:10 |
| greyback | kgunn: I don't think so. That proposal is for shell to animate the actual application surface, not a screenshot of the application (as we're doing right now) | 16:12 |
| greyback | kgunn: nothing to do with single-surfac shell | 16:12 |
| kgunn | greyback: got it...texture source for the single surf...not actual compositing... | 16:14 |
| kgunn | didrocks: can you paste the dmesg output from the ati-trouble machine into the bug ? https://bugs.launchpad.net/mir/+bug/1203070 | 16:29 |
| ubot5 | Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] | 16:29 |
| tvoss_ | mlankhorst, ping | 16:31 |
| didrocks | kgunn: I just pasted the relevant time log: https://bugs.launchpad.net/mir/+bug/1203070/comments/5 | 16:38 |
| ubot5 | Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] | 16:38 |
| didrocks | (the lightdm segfault) | 16:38 |
| kgunn | didrocks: ??....lankhorst indicated the pm firmware not being installed as the reason for hw mouse failing....this is somewhere after that | 16:40 |
| mlankhorst | kgunn: pong, might be related, maybe not | 16:41 |
| didrocks | kgunn: I don't see any logs for it, does he know what we should install? (even on the image by default) | 16:41 |
| mlankhorst | can i start unity-system-compoistor alone | 16:41 |
| didrocks | mlankhorst: it seems lightdm is setting up an environment for it | 16:41 |
| didrocks | so stopping/start lightdm | 16:41 |
| mlankhorst | without lightdmm... | 16:42 |
| didrocks | would be a question for kgunn and robert_ancell I guess :) | 16:42 |
| kgunn | mlankhorst: sure.. (in xmir config i assume you mean) | 16:42 |
| kgunn | which should just kick of mir | 16:43 |
| kgunn | tvoss_: ^ sanity | 16:43 |
| kgunn | but obvioulsy...no mir clients (as xmir has failed by that point) | 16:43 |
| tvoss_ | kgunn, ENOCONTEXT | 16:44 |
| kgunn | tvoss_: could one, after a failure to boot in xmir, kick off the u-s-c process manually | 16:46 |
| tvoss_ | kgunn, hmmm, no, you need lightdm and the env for that ... | 16:46 |
| kgunn | tvoss_: is the need for lightdm because we cannot have a "clientless" mir ? | 16:48 |
| * didrocks wasn't on crack then :) | 16:48 | |
| tvoss_ | kgunn, of course not, it's because the usc needs t obe passed some file descriptors | 16:48 |
| tvoss_ | kgunn, and a vt to operate upon | 16:48 |
| kgunn | tvoss_: ack | 16:49 |
| * kgunn was insane... | 16:49 | |
| mlankhorst | gone | 16:52 |
| bschaefer | kgunn, ping | 18:15 |
| kgunn | bschaefer: yo | 18:21 |
| bschaefer | kgunn, hey, so ive some time now, but I don't have an ATI card :( | 18:21 |
| bschaefer | i've a large desktop I can install ubuntu on but it'll take a bit of time | 18:21 |
| kgunn | bschaefer: yeah....it'd be best to get access to didrocks machine | 18:22 |
| kgunn | but he's not on | 18:22 |
| kgunn | at least for the moment | 18:22 |
| bschaefer | dang and now hes gone... | 18:22 |
| bschaefer | kgunn, well I should have mentioned this acouple hours ago :) | 18:22 |
| kgunn | he might show back up | 18:22 |
| bschaefer | yeah, Ill try poking some QA people in the meantime | 18:23 |
| kgunn | cool | 18:23 |
| kgunn | tvoss_: robotfuel: do you know if there is someone else who might be able to provide us access besides didrocks to the ati machine failing to boot ?? | 18:24 |
| tvoss_ | kgunn, not sure, sil2100 might be able to help | 18:25 |
| robotfuel | I don't have access to the ati machine yet, jibel might? | 18:25 |
| robotfuel | kgunn: ^ | 18:25 |
| kgunn | jibel: could you help us ? | 18:29 |
| bschaefer | kgunn, I think I found one | 18:30 |
| kgunn | sweet! | 18:31 |
| kgunn | bschaefer: i'm gonna break for lunch... | 18:31 |
| bschaefer | kgunn, cool, enjoy your lunch! | 18:31 |
| tvoss_ | xjunior, hey there :) | 18:50 |
| tvoss_ | xjunior, still busy debugging | 18:50 |
| xjunior | tvoss_: nice man :) good luck with that!! | 18:51 |
| xjunior | I believe it's a hard piece of code to debug | 18:51 |
| bschaefer | kgunn, yup, got access to a ati machine, thanks for the suggestion :) | 18:51 |
| tvoss_ | xjunior, it is, raof is looking into it, too | 18:51 |
| xjunior | fortunately it's not Xorg :P | 18:51 |
| xjunior | I still can't get into Xorg, btw. I believe it's a intel driver issue. It's crashing and I remember it was updated a few days ago | 18:52 |
| tvoss_ | xjunior, did you pin the ppa? | 18:52 |
| xjunior | yeap | 18:53 |
| bschaefer | xjunior, something like this: https://bugs.launchpad.net/xmir/+bug/1203776 | 18:54 |
| ubot5 | Launchpad bug 1203776 in xserver-xorg-video-intel (Ubuntu) "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,Confirmed] | 18:54 |
| tvoss_ | xjunior, just to make sure: you have got the system-compositor-testing ppa? | 18:54 |
| * bschaefer was getting an intel crash on normal X as well this morning | 18:54 | |
| racarr | I am trying to process the scene graph discussion email | 19:05 |
| xjunior | tvoss_: yea yeah, absolutely | 19:05 |
| xjunior | I guess that's what's happening to me :) | 19:05 |
| racarr | and I think what Alan is describing, and what I've started to see we need through some of the pain in resolving races like in session-transactions | 19:06 |
| racarr | is not actually a scene graph in...any particular sense | 19:06 |
| racarr | one of it's responsibilities (it's interface to the compositor) coincides with some of the responsibility of a scene graph | 19:07 |
| xjunior | That's exactly the situation I have here, tvoss_. I +1'd that bug | 19:07 |
| tvoss_ | xjunior, thx | 19:07 |
| racarr | but it contains assosciations like session->surface, etc, which aren't actually 'scene' assosciations | 19:08 |
| racarr | I guess I feel like the problem we are trying to solve, is that we have dataa and state distributed over the system so we want to integrate it in to a single multi index store | 19:08 |
| racarr | and not | 19:09 |
| racarr | we need a "scene graph" | 19:09 |
| racarr | *trails off in to mumbling* | 19:10 |
| racarr | I am just thinking outloud :) | 19:10 |
| bschaefer | racarr, so your trying to come up with a data structure that can store all of the session/surfaces while having random access while having some sort of graph structure? | 19:14 |
| * bschaefer could have read that wrong | 19:14 | |
| * bschaefer looks up scene graph... | 19:16 | |
| bschaefer | which looks just like a B-Tree | 19:16 |
| bschaefer | but a bit crazier... | 19:18 |
| racarr | bschaefer: Hmm, thats probably part of the data structure. but I think finding a data structure once we know exactly what we need wont be so bad | 19:19 |
| racarr | I guess to me the thing is, state is distributed all over the system | 19:20 |
| racarr | i.e. the input state is held in some data structure that basically builds an input view of the surface stack | 19:20 |
| bschaefer | right, reading scene graph wiki was kind of funny: The definition of a scene graph is fuzzy | 19:20 |
| racarr | the shell bit with the session assosciation, and shell state lives in the shell, and acts as sort of another view/controller to the surface stack | 19:21 |
| bschaefer | isn't input in a different thread as well? | 19:21 |
| racarr | likewise, the compositor gets a view of the surface stack, and treats it like a scene graph | 19:21 |
| racarr | Right | 19:21 |
| racarr | so with all the state in different bits | 19:21 |
| racarr | synchronization gets | 19:21 |
| racarr | increasingly difficult | 19:21 |
| bschaefer | geez, thats going to be hard to get that all sync... | 19:21 |
| bschaefer | yeah | 19:21 |
| racarr | and, another thing is pretty much all state | 19:21 |
| racarr | changing in mir | 19:21 |
| racarr | needs to support some pattern like | 19:22 |
| racarr | notify the shell of this and potentially allow it to interfere, etc. | 19:22 |
| racarr | and without one authoratative source of...what is what when | 19:22 |
| racarr | this becomes kind of difficult and we've ended up with this weird pattern where the shell will do things like subclass one of our factory objects | 19:22 |
| bschaefer | you'll get lost...and out of order :( | 19:22 |
| racarr | and interfere and then call up to the base class | 19:22 |
| racarr | yeah | 19:23 |
| racarr | so that's what I am thinking about :p | 19:24 |
| bschaefer | that is an interesting problem to solve... | 19:24 |
| racarr | and we have always called this a scene graph, because at a very high level | 19:24 |
| racarr | a bunch of components manipulate it, then the compositor visits it to render the scene | 19:25 |
| racarr | well, at one very high level XD | 19:25 |
| bschaefer | yeah, that sounds like a fun problem that almost seems like it needs to be broken down a bit haha | 19:25 |
| racarr | but I think, "scene graph" doesn't actually capture the problem we are trying to solve | 19:25 |
| racarr | yeah | 19:25 |
| tvoss_ | racarr, what you are describing is the mvc, isn't it? | 19:26 |
| bschaefer | well, i don't a single data structure can capture that...scene graph is pretty high level thats just a bunch of other graphs/trees | 19:26 |
| bschaefer | s/dont/dont think | 19:27 |
| racarr | tvoss_: Well...it's some kind of MVC right! But it has a very particular structure | 19:27 |
| racarr | and has to provide a few seperate views | 19:27 |
| racarr | and I think part of what it needs to do is | 19:27 |
| tvoss_ | racarr, right, but mvc can account for that ;) | 19:27 |
| tvoss_ | racarr, gerry is merely pointing out that we can leverage an existing implementatoin quite easily. and I do strongly agree with that | 19:28 |
| racarr | support some system of | 19:28 |
| tvoss_ | most likely, the glue layer I'm mentioning in the mail will allow for querying the views (compositor, input, focus) that you have in mind | 19:28 |
| racarr | transactional/atomic operations | 19:28 |
| racarr | mm | 19:29 |
| racarr | but I guess I am saying that is the real problem at hand | 19:29 |
| racarr | and if we knew these interfaces | 19:30 |
| racarr | the data structure is entirely trivial | 19:30 |
| racarr | maybe Qt through OpenSceneGraph can help us on the rendering end | 19:31 |
| racarr | but that's closer to a view on this structure in the compositor not the structure itself I think | 19:31 |
| racarr | right I mean this is our central data store, not our "rendering pass optimizer" | 19:32 |
| racarr | I honestly still dont understand what it would mean though, using the qt scene graph | 19:35 |
| racarr | does it mean ms::Surface implements QSceneGraphItem? | 19:35 |
| racarr | Are we talking about just reusing their data structure? or using the renderer too? | 19:38 |
| racarr | I don't think it understands that each display element has its own opengl context that its children are drawn in | 19:38 |
| racarr | so I don't understand how that can be integrated with the compositor exactly | 19:39 |
| racarr | / at all. | 19:40 |
| racarr | Sorry :) I don't mean to be negative | 19:40 |
| racarr | but I literally don't know what the first step towards doing this would be | 19:40 |
| kgunn | racarr: what is the first "it's" in "one of it's responsibilities (it's interface to the compositor) coincides with some of the responsibility of a scene graph" | 19:47 |
| kgunn | i/f to compositor ? | 19:47 |
| bschaefer | kgunn, hey, been rebooting this machine for a while now and xmir starts up each time :( | 19:49 |
| bschaefer | using : 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450] | 19:49 |
| * bschaefer keeps rebooting | 19:49 | |
| kgunn | bschaefer: hmmm....didrock's was a Cedar series...which i think is Radeon HD 5000 series of gpu | 19:51 |
| bschaefer | kgunn, right, i should go check my desktop really quick...as if its a cedar series it might be worth getting xmir installed on it | 19:52 |
| kgunn | bschaefer: also.. | 19:52 |
| kgunn | just thinking | 19:52 |
| kgunn | it wasn't so much the fact it was cedar series.... | 19:52 |
| kgunn | the current theory of suscpicion was that | 19:52 |
| bschaefer | the power management? | 19:53 |
| kgunn | didrock's machine didn't have pm firmware installed | 19:53 |
| kgunn | right | 19:53 |
| bschaefer | yeah, hmm I wonder if I can uninstall that... | 19:53 |
| kgunn | so when the gfx driver tried to use hw cursor it couldn't | 19:53 |
| kgunn | ...and then got pissed | 19:53 |
| bschaefer | but you would think things would fail softly... | 19:53 |
| bschaefer | instead of bringing everything down | 19:53 |
| kgunn | (that's U.S. pissed not U.K. pissed) | 19:53 |
| * bschaefer is from U.S | 19:53 | |
| * bschaefer just learned there was a difference | 19:53 | |
| bschaefer | kgunn, would you happen to know how to remove pm firmware? | 19:54 |
| kgunn | oh...thot you were in canada...and you never know which they favor with speech :) z==zee vs zed | 19:54 |
| kgunn | bschaefer: no ide | 19:54 |
| kgunn | idea | 19:54 |
| bschaefer | kgunn, haha yeah, from Seattle :) | 19:54 |
| bschaefer | close | 19:54 |
| bschaefer | kgunn, alright, well ill look into if thats even possible to remove, and if removing it should yield a working desktop or not | 19:55 |
| kgunn | bschaefer: kernel folk might know.... | 19:56 |
| bschaefer | kgunn, would you happen to know a channel for that? When/if i get stuck at lease... | 19:56 |
| racarr | kgunn: This data structure that we are debating in the email thread | 19:57 |
| racarr | if I understood your question | 19:57 |
| racarr | that point was just supposed to say that while it mimicks a scene graph in one scenario | 19:58 |
| kgunn | bschaefer: took a guess...lots of people in #ubuntu-kernel | 19:58 |
| racarr | I dont think that's the right way to come at it | 19:58 |
| bschaefer | kgunn, great guess :), thanks! | 19:58 |
| kgunn | racarr: ack | 19:58 |
| kgunn | bschaefer: high five! | 19:58 |
| racarr | I mean in the most literal sense | 19:58 |
| * bschaefer high fives back | 19:58 | |
| racarr | it could be called a graph of the scene | 19:59 |
| racarr | but it could also be called a list haha | 19:59 |
| racarr | so I am trying to find the right direction to zoom in on it from | 20:00 |
| kgunn | bschaefer: hmm, could it disabling the "APM" option referred to here be the trick http://how-to.wikia.com/wiki/How_to_configure_the_Linux_kernel/Power_management_options_(ACPI,_APM) | 20:01 |
| * bschaefer takes a look | 20:02 | |
| bschaefer | possibly, I was thinking I could move the firmware/driver out of its dir in the kernel somewhere | 20:02 |
| kgunn | bschaefer: maybe...something easier first... | 20:03 |
| kgunn | duh | 20:03 |
| kgunn | why not change the xorg conf to just rely on sw cursor | 20:03 |
| bschaefer | hmm so right now its relying on the hw cursor? | 20:03 |
| * bschaefer looks at the xorg conf | 20:04 | |
| kgunn | bschaefer: so i guess any xorg driver actually reads the xorg conf file.... | 20:10 |
| kgunn | http://linux.die.net/man/4/radeon | 20:10 |
| kgunn | ? | 20:11 |
| * kgunn realizes how little he knows | 20:11 | |
| bschaefer | kgunn, as do I :), im looking at turning some things off in the BIOS at first possibly that'll cause the firmware to not load? | 20:12 |
| bschaefer | kgunn, also the machine im on doesn't even have an xorg conf file | 20:12 |
| bschaefer | but I did fine a bunch of binary in the kernel that looked like it was dealing with power...but I have a feeling moving those will cause other problem s:) | 20:13 |
| bschaefer | kgunn, how did we come to the conclusion the we were missing pm firmware? | 20:13 |
| kgunn | mlankhorst saw dmesg's go by saying so | 20:14 |
| kgunn | bschaefer, but i think you should be able to simply add a xorg conf file with over-riding values for options | 20:14 |
| bschaefer | right, i need to look at those man pages :) | 20:15 |
| bschaefer | lots of things to read :) | 20:15 |
| kgunn | i only think this because of sna wiki (https://wiki.ubuntu.com/X/Testing/IntelSNA) where it talks about downloading their pre-formed version for sna | 20:15 |
| bschaefer | yeah you can add an xorg conf file... im just wondering why there wasnt one... | 20:19 |
| bschaefer | im also trying to wrap my head around why not having a pm firmware loaded would cause the hw cursor to not work | 20:20 |
| kgunn | on the pm part...hw cursor is actually a seperate piece of silicon, that requires to be "powered" up at some point, so something probably inside the hw mouse driver | 20:24 |
| kgunn | queried pm, it failed, so he failed..."sorry i ain't got no power" | 20:24 |
| bschaefer | that does make more sense, im waiting on this machine to do something | 20:25 |
| bschaefer | kgunn, sorry, seem to have broken to machine, hopefully I can get it up soon :) | 20:38 |
| kgunn | bschaefer: thanks for the effort | 20:38 |
| bschaefer | the machine* | 20:38 |
| kgunn | and the update | 20:38 |
| kgunn | :D | 20:38 |
| bschaefer | np, I guess you can't just disable all PM and expect it to turn on :) | 20:38 |
| bschaefer | also forcing a SW wont help much atm, as im trying to reproduce the problem atm :) | 20:44 |
| bschaefer | alright, have the machine back... | 21:11 |
| xjunior | tvoss_: hey man, did have success | 21:12 |
| tvoss_ | xjunior, how? | 21:12 |
| xjunior | any news on debugging the slowness on XMir | 21:13 |
| tvoss_ | xjunior, ah, that was a question? | 21:14 |
| xjunior | yeah :) sorry | 21:14 |
| xjunior | I ate some words apparently | 21:15 |
| tvoss_ | xjunior, no worries :) know the symptoms | 21:15 |
| tvoss_ | so I have an instrumented build of X now, will give that a spin tomorrow. Its 11pm here :) | 21:15 |
| xjunior | oh, gotcha :) Europe? | 21:18 |
| tvoss_ | xjunior, yup, Germany | 21:18 |
| xjunior | nice :) have friends there | 21:20 |
| kgunn | robert_ancell: so looks like the ati bug is the last hurdle (at least for universe) | 21:20 |
| xjunior | Alright, good luck tomorrow. Hope you solve it. | 21:20 |
| kgunn | robert_ancell: so some debug mlankhorst did that didrocks machine didn't have pm firmware installed... | 21:20 |
| mterry | robert_ancell, you asked about u8-greeter and running as mir server? | 21:21 |
| kgunn | so when hw cursor tried to init...it failed....and xmir didn't fall back to sw cursor | 21:21 |
| mterry | robert_ancell, I was thinking we wouldn't need to run as mir server anymore | 21:21 |
| kgunn | whereas standalone x does (or that is the assumption) | 21:21 |
| kgunn | robert_ancell: so bschaefer is in the midst of trying to "simulate" that problem...since didrocks is sleeping :) and we can't get to the machine | 21:22 |
| bschaefer | yeah, and so far xmir is working, sooo trying to remove pm firmware...but just got the broken machine back... | 21:23 |
| robert_ancell | mterry, I'm just getting LightDM to support Mir sessions/greeter with VT switching since we don't have nested Mir support yet. Just wondering if I can run the u8 greeter for now like that or support has been dropped | 21:23 |
| kgunn | robert_ancell: so i'm hoping this is either a bug or missing feature we have to fall back to sw cursor | 21:23 |
| robert_ancell | kgunn, who let didrocks go to sleep? ;) | 21:24 |
| kgunn | i know... right ? | 21:24 |
| robert_ancell | kgunn, yeah, wonder if it's just never been noticed because everything does the fallback | 21:24 |
| robert_ancell | seems like it should be fixed in the driver depending on how widespread it is | 21:24 |
| kgunn | robert_ancell: yeah...its one of those bugs that might have been lurking...also, just in case...didrock card was a Cedar (5000 series) | 21:25 |
| kgunn | just in case....as in bschaefer is toying around on a 7000 series | 21:26 |
| bschaefer | it would be strange that a specific ATI card was doing this vs PM ... but what do i know haha | 21:26 |
| kgunn | robert_ancell: if you, duflu or RAOF have a 5000 series it might be worth it just to enable swcursor in xorg.conf and test it | 21:27 |
| bschaefer | they are under different classes though... | 21:27 |
| robert_ancell | kgunn, I just have the one intel/nvidia card | 21:27 |
| kgunn | it would at least help in confirm/deny | 21:27 |
| mterry | robert_ancell, my branch is still using an internal mir-server | 21:27 |
| bschaefer | im on a Caicos PRO | 21:27 |
| kgunn | that this whole issue is related to swcursor | 21:27 |
| mterry | robert_ancell, i.e. I haven't made it a pure client yet | 21:27 |
| robert_ancell | mterry, cool, can you keep it like that for testing purposes until we have the whole stack ready? | 21:28 |
| robert_ancell | or support both? | 21:28 |
| kgunn | mterry: now has 3 optional configs he needs to support :)) | 21:28 |
| mterry | :) | 21:29 |
| mterry | robert_ancell, uh, I can keep my current split as is, yeah. Let me know when you don't care about mir-server mode anymore | 21:30 |
| robert_ancell | mterry, will do :) | 21:30 |
| kgunn | robert_ancell: also...would you mind dispositioning the MIR feedback ? i think your best to speak to it | 21:37 |
| kgunn | robert_ancell: one note...for all the "need to assign a bug owner" | 21:37 |
| * robert_ancell looks up dispositioning | 21:38 | |
| kgunn | olli chose mir-team for the moment :) | 21:38 |
| robert_ancell | kgunn, that works for now | 21:38 |
| kgunn | yeah...he promised to seek another victim...oops i mean owner | 21:38 |
| robert_ancell | wiktionary says "Present participle of disposition.". Now I have to remember what a present participle is :) | 21:39 |
| kdub | EventSink hitch-hikes through a lot of constructors | 21:39 |
| kgunn | :) | 21:40 |
| kgunn | robert_ancell: whenever RAOF or duflu come on, just check if they've got a cedar/5000 series ati card to try (w sw cursor).....since that bugs our #1 right now | 21:40 |
| robert_ancell | kgunn, ok | 21:41 |
| robert_ancell | mterry, oh, how did you remove the u-s-c task from the mir MIR? | 21:47 |
| mterry | robert_ancell, there's a little red minus symbol next to the tasks | 21:55 |
| robert_ancell | mterry, huh, I totally missed that | 21:55 |
| mterry | robert_ancell, way nicer than marking invalid in terms of bug spam | 21:57 |
| robert_ancell | yes | 21:57 |
| robert_ancell | mterry, in the MIRs you refer to needing a dev team subscribed to bug reports. Is that the "bug supervisor" in https://bugs.launchpad.net/mir? | 22:08 |
| mterry | robert_ancell, yeah, but for the ubuntu package side, not the upstream one | 22:14 |
| mterry | so ubuntu/+source/mir | 22:15 |
| robert_ancell | mterry, k | 22:15 |
| mterry | I guess that's mir-team | 22:15 |
| robert_ancell | mterry, so, Unity doesn't seem to have a subscriber https://bugs.launchpad.net/ubuntu/+source/unity | 22:16 |
| mterry | robert_ancell, that would be good to add too | 22:22 |
| mterry | robert_ancell, we didn't use to *require* it, only strongly suggest it | 22:23 |
| mterry | robert_ancell, but no one did it, so we are bumping up our language | 22:23 |
| robert_ancell | mterry, yeah, I'm trying to find *any* project that has a team subscribed to bug email | 22:23 |
| racarr | kdub: It's not strong coupling, all the classes are just really good friends and having a party. | 22:24 |
| racarr | :p | 22:24 |
| mterry | robert_ancell, most of the gnome desktop ones have a team subscribed | 22:25 |
| robert_ancell | the dialog for this is really bad. The list of teams is not sorted alphabetically | 22:25 |
| robert_ancell | and you can't seem to tell who is subscribed by looking at the project page | 22:28 |
| kdub | racarr, haha | 22:42 |
| robert_ancell | RAOF, did you see the traceback about cedar/5000 series ATI cards | 22:47 |
| RAOF | robert_ancell: I did, yes. | 22:47 |
| robert_ancell | RAOF, got any? | 22:47 |
| RAOF | I do not. | 22:47 |
| RAOF | I've got a 4535 or somesuch, and a 7870 that I don't have a desktop box to put into. | 22:48 |
| bschaefer | RAOF, i've been trying to reproduce it as well, on a 7450 | 22:48 |
| bschaefer | but xmir is working perfectly | 22:49 |
| bschaefer | RAOF, it was mentioned that this could be due to the power management firmware missing, but it doesn't seem to be easy to just remove that to test if thats the problem... | 22:50 |
| RAOF | bschaefer: I don't know about that - on 3.11 kernels you need more firmware than we've got in linux-firmware to *load* radeon.ko, but (a) we're running a 3.10 kernel, and (b) Mir would fail in a different way if that were the case. | 22:52 |
| bschaefer | yeah... hmm I wonder if its the radeon family (as the 5000 is in the evergreen series) drivers then... | 22:54 |
| bschaefer | RAOF, shouldn't mir attempt to play nice when it can't load the HW cursor? | 22:54 |
| RAOF | Maybe? It currently doesn't, though. | 22:54 |
| bschaefer | well you would assume if this happens: std::exception::what: failed to create gbm buffer | 22:55 |
| bschaefer | no other gbm buffers are going to work... | 22:55 |
| RAOF | You know what? I should look in the xf86-video-ati source and see whether they have any specific hacks for that card & the hw cursor. | 22:56 |
| RAOF | Unfortunately, not. The hw cursor bo is super-specific - failing to allocate it doesn't mean that you'll fail to allocate anything else. | 22:56 |
| bschaefer | o hmm thats interesting | 22:57 |
| bschaefer | well im sure you've seen the list family for the ATI cards but: http://xorg.freedesktop.org/wiki/RadeonFeature/ | 22:57 |
| bschaefer | as the card im using is under Nothern Islands...idk if that even matters though vs the driver is self for each card | 22:58 |
| RAOF | Isn't a 7450 SI? Stupid damned marketing department. | 23:14 |
| bschaefer | it should be, looking at the number but the machine im on gives me: | 23:16 |
| bschaefer | 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450] | 23:16 |
| bschaefer | which Caicos is a NI card...possibly the PRO is throwing it off... | 23:16 |
| bschaefer | but looking here as well: http://wiki.gentoo.org/wiki/Radeon#Feature_support | 23:17 |
| bschaefer | and it has the 7450 under NI | 23:17 |
| RAOF | Yeah, it the radeon page is probably right. | 23:18 |
| bschaefer | hmm my desktop that i've not used in a while had an evergreen card | 23:18 |
| RAOF | I just hate that the card marketing generation is not the same as the card chip generation. | 23:18 |
| bschaefer | a redwood one | 23:18 |
| * bschaefer starts downloading13.10 | 23:19 | |
| RAOF | I've got an evergreen (although I can't quite remember the specific model) too, but that worked fine last time I tried it. | 23:19 |
| * RAOF will be slow for the next hour or so, as he's minding Zoë. | 23:19 | |
| bschaefer | well it'll take a bit for me to get my desktop up with xmir.. 1-2 hours... | 23:20 |
| bschaefer | it'll be strange if its just specific to CEDAR | 23:20 |
| bschaefer | but then again this could be normal, as I haven't done video card stuff much before :) | 23:21 |
| bschaefer | hopefully duflu will come on a reproduce the problem | 23:22 |
| bschaefer | and* | 23:22 |
| RAOF | Hey, is there any way to get a buffer ID that crosses the IPC boundary? I want to check that the buffer I most recently submitted from XMir is *really* the buffer that Mir's displaying. | 23:44 |
| olli_ | bregma, can you pls ping the relevant armhf issues to slangasek? | 23:48 |
| olli_ | or robert_ancell ^ | 23:48 |
| kgunn | RAOF: ok....any guesses on why robotfuel might see openarena values higher on Xmir vs X ? | 23:52 |
| kgunn | kgunn: the results are still strange with the monitor attached x is 44.47 frames per second average and xmir is 136.97 | 23:52 |
| kgunn | is it because there's no governing ? | 23:53 |
| kgunn | e.g. no more vsync on the bottom of x (moved to the bottom of mir) | 23:53 |
| kgunn | robotfuel might take a trained eye....but do you see any tearing ? | 23:53 |
| RAOF | vsync would be my immediate guess | 23:54 |
| robert_ancell | kdub, around? | 23:54 |
| kdub | yep | 23:54 |
| RAOF | XMir clients are *not* throttled to vsync | 23:54 |
| robert_ancell | kdub, I've just forwarded you an email regarding armhf tests and android. Perhaps you can help understand what lp:mir expects and what is happening | 23:55 |
| kdub | sure | 23:56 |
| kgunn | robotfuel: does it also provide time to complete ?....and is that different on x vs xmir ? (ignoring the fps for moment) | 23:56 |
| kgunn | RAOF: right...so clients can go nuts and swap buffers as they like...which means, the truly displayed frames is much less than that | 23:56 |
| kgunn | or "allegedly" is much less than that :) | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!