duflu | bregma: Are we skipping the hangout? | 02:02 |
---|---|---|
duflu | camako, bschaefer ^ | 02:02 |
bschaefer | umm i think so | 02:02 |
bschaefer | duflu, i think its just me and you around | 02:02 |
duflu | And then more | 02:03 |
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== JanC_ is now known as JanC | ||
mariogrip | alan_g: ping | 16:48 |
alan_g | mariogrip: ? | 16:48 |
mariogrip | alan_g: I saw your post "a-new-hope", and about canonical maybe continuing mir, and at the same time i'm trying to create a wayland platfrom in mir. but i'm then wondering if I should stop that and keep using mir instead of having mir on top of wayland, since what we dont want is to maintain a display server on our own. And do you know if the android | 16:55 |
mariogrip | platform would also be maintained? | 16:55 |
alan_g | mariogrip: at the moment I don't know. | 16:59 |
alan_g | Canonical hasn't had practice at redundancies and information isn't flowing well. | 17:00 |
alan_g | In particular I don't know if any of the proposed IOT projects would use the android stack. | 17:01 |
ogra_ | unlikely (but still possible) | 17:02 |
mariogrip | right, i'm also a bit worried that android would not prioritized | 17:02 |
ogra_ | not only that ... i doubt anyone at canonical will look at hybris in the future | 17:03 |
ogra_ | so even if the Mir bits keep working, hybris integration will be in possible limbo | 17:03 |
alan_g | mariogrip: sorry, I gotta go just now. | 17:04 |
=== alan_g is now known as alan_g|EOD | ||
mariogrip | alan_g: no problem | 17:04 |
mariogrip | ogra_: well, libhybris we can manage since we are not alone on that, but maintaining our own display server is a bit too much | 17:04 |
ogra_ | well, the thing is that you need to maintain the hybris integration of Mir ... neither mir alone or hybris alone | 17:05 |
ogra_ | mir itself ... at least in form of the mir-kiosk snap will surely persist ... but i dont know if there will even be any development | 17:05 |
ogra_ | or if it will just go into "maintenance mode" directly | 17:06 |
mariogrip | right, that's what im worried about that libhybris will change and mir breaks | 17:06 |
ogra_ | it does what it is supposed to do ... (display a single standalone kiosk app) ... so not sure there will be any additional investment | 17:06 |
mariogrip | that's why i'm trying to create this wayland platfrom in mir, that way we dont have to maintain the part that talks with libhybris | 17:07 |
=== chihchun is now known as chihchun_afk | ||
tvoss | mariogrip: libhybris is surprisingly stable. I think you are creating more work for yourself by using wayland as an abstraction layer here | 20:10 |
tvoss | mariogrip: because ultimately, you would have to maintain hybris anyway | 20:10 |
ogra_ | tvoss, well, if the hal stack changes and hybris gets adjustments for that you usually need to adjust Mir as well ... | 20:41 |
tvoss | ogra_: sure, but you would need to patch thewayland adaptation layer, too | 20:42 |
ogra_ | given the amount of maintainers that care for Mir on hybris ... | 20:42 |
ogra_ | tvoss, upstream will fix all wayland issues | 20:42 |
ogra_ | since they use wayland | 20:42 |
tvoss | ogra_: upstream of what? | 20:43 |
ogra_ | but nobody will fix the Mir side | 20:43 |
ogra_ | of hybris | 20:43 |
tvoss | ogra_: sure, but the assumption is that the wayland bits would stay untouched and that the abstraction layer in Mir would need changes either | 20:43 |
tvoss | ogra_: just saying that introducing an abstraction layer at that level will likely just move the problem | 20:44 |
ogra_ | indeed | 20:44 |
ogra_ | but you add another abstraction that probably makes it easier | 20:44 |
ogra_ | i.e. if the upper side of wayland doesnt change you dont need to adjust Mir ... and the lower side of wayland will be managed by upstream anyway | 20:45 |
tvoss | sure, that's a risky bet, though | 20:46 |
ogra_ | (i'd actually be more concerned about the performance impact ... maintenance wise it could be less work after all ) | 20:46 |
ogra_ | ...but yeah, based on assumptions :) | 20:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!