| duflu | robert_ancell: Sorry to trouble you but I'm not sure anyone else knows how and is also blessed to do so: Can we update the Xmir patch for xenial? | 01:22 |
|---|---|---|
| duflu | RAOF: Did linking get faster recently? Did we switch to gold or did gcc just get fixed? | 01:24 |
| RAOF | gcc may have been fixed? | 01:25 |
| RAOF | We're on 5.3 now. | 01:25 |
| robert_ancell | duflu, do you need it sponsored? | 01:25 |
| duflu | Yeah 5.3 caused the slowdown actually | 01:25 |
| duflu | robert_ancell: Maybe... I don't remember that process | 01:25 |
| robert_ancell | duflu, or do you want me to generate a patch from the branch and upload that? | 01:26 |
| * robert_ancell tries to remember about xmir | 01:26 | |
| duflu | robert_ancell: Yes please | 01:26 |
| duflu | Fortunately xorg hasn't changed otherwise since November | 01:27 |
| robert_ancell | duflu, is bregma aware of these changes? | 01:29 |
| duflu | robert_ancell: Yes, it was work requested by him and kgunn | 01:30 |
| robert_ancell | cool | 01:30 |
| duflu | Otherwise I would not have touched it | 01:30 |
| robert_ancell | :) | 01:30 |
| duflu | robert_ancell: The two "Fix Committed": https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs?field.tag=xmir | 01:30 |
| robert_ancell | duflu, do you fix configure.ac to check for a more recent version of Mir? | 01:36 |
| robert_ancell | one of your commits suggests that is the case | 01:36 |
| duflu | robert_ancell: Where is that comment? | 01:36 |
| robert_ancell | duflu, https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=3f1e0ab7e5a8af5578cd10492c1f93e9bf97e252 | 01:36 |
| robert_ancell | it's a runtime dependency I guess, but probably worth checking on build | 01:37 |
| duflu | robert_ancell: No, it's a runtime requirement. Also probably safe to assume any updated Ubuntu Touch system has Mir new enough | 01:37 |
| duflu | Especially if it also has /future/ Xmir | 01:37 |
| robert_ancell | duflu, yeah, but anyone building X would probably want to fail if they have an old version | 01:38 |
| duflu | robert_ancell: It's not a build-time check. Xmir links to libmirclient.so.9 which may be from "any" Mir version | 01:38 |
| robert_ancell | duflu, yes, but configure is not necessaraily just for checking API compatibility | 01:39 |
| duflu | robert_ancell: It would have to be a runtime check (on Android only) that the Mir client library version is new enough. But that's actually less severe than the QtMir fix, which we can't detect from Xmir | 01:40 |
| robert_ancell | duflu, my point is by putting in configure.ac you stop someone with Mir 0.15 installed from building, because they are almost certainly going to hit the issue when they run the X they built | 01:41 |
| * duflu checks distro | 01:41 | |
| duflu | robert_ancell: Ubuntu 15.10 and later already ships with a new enough Mir. And the QtMir bug can't be detected (we don't even know where it got fixed) | 01:42 |
| duflu | So I'm happy to skip any detection attempts | 01:42 |
| robert_ancell | duflu, but this is a patch to xorg, which is not necessarily built on Ubuntu | 01:42 |
| robert_ancell | ... | 01:42 |
| * robert_ancell gives up | 01:42 | |
| duflu | robert_ancell: I see your point, but it would be a hack of probably no real-world value and would still not protect the user entirely if they are using an old Unity8 | 01:43 |
| RAOF | configure.ac is a nice place to document such a dependency. | 01:44 |
| duflu | It's not a dependency. We could switch it to a compatibility mode at run time. But it's impossible to reliably detect if that is required | 01:44 |
| duflu | I will personally worry about our phone images having the right bits. But non-Ubuntu users I'm happy to say: You need a Mir v0.16 or later for it to work properly. | 01:46 |
| RAOF | (Which is what a mir-client >= 0.16 in configure.ac documents ☺) | 01:59 |
| duflu | RAOF: It can and should build with older Mir... libmirclient9 is the requirement. When did that happen? | 02:01 |
| RAOF | But it won't work at runtime with mir-client < 0.16? | 02:01 |
| RAOF | Which is why you document that in the configure.ac check! | 02:01 |
| duflu | RAOF: It could if we detected it and switched to slow mode. But we can't also detect the broken QtMir | 02:02 |
| RAOF | But we don't, so it doesn't. | 02:02 |
| RAOF | Basically: it's harmless to bump that version requirement, and it's courteous to anyone trying to get it to work. | 02:02 |
| duflu | RAOF: It's not a "bump". We don't check the Mir version at runtime yet do we? That's a code change | 02:03 |
| duflu | Also not a reliable or useful one, probably | 02:03 |
| RAOF | We have a check in configure.ac, yes? Because we link with libmirclient9. | 02:03 |
| RAOF | *That* check is a simple bump. | 02:04 |
| duflu | RAOF: That's a build time check. We still want it to be buildable with old Mir. Building on old Mir is not broken | 02:04 |
| RAOF | It's useless to build against old Mir, though. | 02:05 |
| RAOF | I mean, you can build it, but you'll run into this bug and it won't work. | 02:05 |
| RAOF | So in order to use it you'll need to have a newer build of Mir. | 02:05 |
| RAOF | So there's no benefit gained in letting people build something they won't be able to run. | 02:05 |
| RAOF | But this isn't really interesting enough to argue about, either :) | 02:06 |
| duflu | RAOF: It's a silly feature to check and then throttle. If someone is advanced enough to build their own Xmir and they're not using Ubuntu, we should just remind them we'll only support recent versions | 02:07 |
| RAOF | Indeed! | 02:07 |
| RAOF | Which is why we should bump the configure.ac check! | 02:08 |
| duflu | RAOF: Also, this only applies to Android. And never desktop | 02:08 |
| RAOF | I'm not arguing for runtime detection! | 02:08 |
| duflu | Desktop users can use old Mir fine | 02:08 |
| duflu | Only touch users can't | 02:08 |
| duflu | Although the QtMir bug does affect desktop... we have no knowledge of exactly what version that got fixed in. Just "it seems to be fixed this year" | 02:10 |
| duflu | Hmm, now I look at it again, the only relevant Mir bug was only on Android and only relevant to non-nested servers. That's what got fixed in 0.16.0 | 02:20 |
| robert_ancell | duflu, is anyone looking at updating xmir for the X 1.18 API (i.e. you) | 02:21 |
| duflu | robert_ancell: No I wasn't yet. Still focusing on xenial (1.17) | 02:22 |
| duflu | Sounds like branches will happen | 02:22 |
| robert_ancell | tjaalton, was asking, but I haven't had time to have a look | 02:22 |
| duflu | robert_ancell: Best not to mess with what we've got (which seems like the right branch for xenial) right now | 02:23 |
| duflu | robert_ancell: Oh I see new Xmir in xenial proposed already. You rock. | 02:23 |
| robert_ancell | duflu, it was for testing purposes and to be ready when fglrx updates to the new API we can shift over. | 02:24 |
| robert_ancell | I guess 1.18 will land into 16.10 | 02:24 |
| robert_ancell | duflu, please test xmir from -proposed :) | 02:24 |
| duflu | robert_ancell: OK, ta | 02:24 |
| duflu | robert_ancell: I won't have an answer till at least your Wednesday though | 02:25 |
| robert_ancell | duflu, for xmir? | 02:25 |
| duflu | robert_ancell: Yeah I'm still ploughing through morning tasks and have two time consuming meetings today | 02:26 |
| duflu | But should be able to do all the manual testing required before tomorrow | 02:26 |
| * duflu wonders if his words are knocking robert_ancell over | 02:27 | |
| robert_ancell | hmm, any reason why I can't VT switch away from mir_demo_server anymore? | 02:27 |
| robert_ancell | I had to reboot, was stuck on VT1 | 02:27 |
| duflu | robert_ancell: There is a known bug. Lemme find it | 02:28 |
| duflu | robert_ancell: Non-root? | 02:29 |
| robert_ancell | duflu, as root | 02:29 |
| duflu | Oh, I found https://bugs.launchpad.net/mir/+bug/1286252 | 02:29 |
| ubot5` | Launchpad bug 1286252 in Mir "mir_demo_server* successfully start as non-root (without input support), meaning it can't be quit/switched away from" [Medium,Confirmed] | 02:29 |
| robert_ancell | yeah, I've fallen for the non-root base before | 02:29 |
| duflu | robert_ancell: Or generally it might mean you have no input platform :) | 02:29 |
| robert_ancell | duflu, which package name | 02:30 |
| duflu | robert_ancell: mir-platform-input-evdev5 | 02:30 |
| === chihchun is now known as chihchun_afk | ||
| tjaalton | duflu: 1.18 is in ppa:canonical-x/x-staging | 05:33 |
| tjaalton | i've ported xmir to it | 05:33 |
| tjaalton | sent a CFT to ubuntu-devel some time ago | 05:34 |
| tjaalton | plan was to move it to main before FF, but nvidia hybrids regress with the blob, unity-greeter crashes | 05:36 |
| tjaalton | so we're looking into that first | 05:37 |
| anpok_ | hm i thought 1286252 has been fixed already, by accident | 06:13 |
| anpok_ | oh ok only partially | 06:16 |
| anpok_ | there is still a way to get stuck | 06:16 |
| duflu | tjaalton: Thanks. So long as you have the Xmir changes from the past few days too (https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/) | 06:20 |
| tjaalton | duflu: yeah I've now merged it in the branch, will upload to ppa later | 06:24 |
| duflu | tjaalton: Cool, thanks. Ignore the email then | 06:24 |
| tjaalton | this is what was needed to port it btw http://sprunge.us/JfHW | 06:25 |
| duflu | tjaalton: No risk on the GL stuff because Touch uses software rendering for now. Only the keyboard changes I guess | 06:27 |
| tjaalton | I should probably test that :) | 06:29 |
| duflu | tjaalton: If you test it on desktop it will default to DRI2 (not what the phone uses), so add: -sw | 06:30 |
| duflu | tjaalton: Do you have permission to create a git branch for your changes? https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/ | 06:41 |
| duflu | That's ~xmir-team I guess | 06:41 |
| duflu | tjaalton: Today's package just vanished from proposed and only the old release is visible. Is that right? https://launchpad.net/ubuntu/+source/xorg-server | 06:46 |
| duflu | Maybe it's just a transitional period. I vaguely recall that happens | 06:47 |
| tjaalton | duflu: i might be able to create a branch, after joining the team at least | 06:49 |
| duflu | Ah I see it was "Deleted 16 minutes ago by Ubuntu Archive Robot - moved to release" | 06:49 |
| duflu | tjaalton: That's OK. Just we'll need to remember to do it and incorporate your changes before any new major Xmir work | 06:49 |
| tjaalton | yeah | 06:50 |
| duflu | And make that new branch the default one | 06:50 |
| duflu | I forget how | 06:50 |
| tjaalton | ok | 06:51 |
| zzarr | okey RAOF, thanks, I hope for the first option ("jumping" to internal, and back to external when the cable is pluged in again) | 07:01 |
| RAOF | zzarr: Just bear in mind, essentially no application currently written will support that. | 07:01 |
| === chihchun_afk is now known as chihchun | ||
| zzarr | RAOF, I know, but if the Vulkan framework for a sample will be then that would be splendid :-) | 07:02 |
| zzarr | I don't know if though | 07:03 |
| duflu | Ooh progress. The new xmir is released in xenial before I've finished testing it :) | 07:03 |
| zzarr | duflu, is that good or bad? | 07:04 |
| duflu | Not sure yet | 07:04 |
| duflu | Can't hurt. If anything is wrong we'll fix it quickly | 07:04 |
| zzarr | well it happened in any way | 07:05 |
| zzarr | awesome my internet is faster then I pay for I pay for 100/100 and get 120/115 :-) | 07:10 |
| zzarr | my grammar is poor though (realized that when I read my line) | 07:12 |
| zzarr | in any way I'm happy to see that so many are enthusiastic about Ubuntu :-) (I'm one of the enthustiast) | 07:15 |
| zzarr | does anyone know the status of Miracast (Aethercast)? | 07:51 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader is now known as dandrader|afk | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| alan_g | greyback: I don't really know my way around the unity8 code, and this is something you might know: is there anything that relies on MIR setting $MIR_SERVER? ("anything" would be forking a client process that relies on that environment variable to find the server - which isn't something I expect/can find.) | 14:56 |
| greyback | alan_g: MIR_SERVER env var? No, I've never even seen that env var before, let alone seeing code depending on it | 14:58 |
| alan_g | greyback: the Mir client API can use it to find the server socket. (if the client code doesn't specify a socket) | 15:00 |
| alan_g | But I *think* setting it in the server process is a legacy mess that isn't useful and is confusing. | 15:01 |
| greyback | alan_g: ok. I've only seen MIR_SOCKET being used to specify that, and upstart is responsible for that | 15:01 |
| alan_g | The legacy thinking was that Mir servers would set it and launch clients. But it hasn't turned out that way - U8 doesn't launch clients directly does it? | 15:02 |
| greyback | alan_g: nope | 15:03 |
| alan_g | Excellent! | 15:03 |
| * alan_g is going to delete the mess | 15:03 | |
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOD | ||
| === chihchun is now known as chihchun_afk | ||
| === dandrader|afk is now known as dandrader | ||
| === mapreri_ is now known as mapreri | ||
| === tedg_ is now known as tedg | ||
| === Trevinho_ is now known as Trevinho | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!