racarrRAOF: Im here!00:24
RAOFracarr: Oh! Because you've got ops!00:25
* RAOF was scanning the user list, and you weren't where I expected :)00:26
racarrhttps://code.launchpad.net/~robertcarr/mir/prepare-session-manager-for-input-focus/+merge/152806 for the bored reviewers :)00:40
RichardMIchaelsI am not really opposed to Mir, but I think canonical ought to do what it can to share the same application and driver base as Wayland, including by providing a MIr backend that can display a Mir session to an X server.01:29
RAOFWe do indeed plan to do that (an X backend for Mir)01:29
RichardMIchaelsWhich would gaurantee that any application that could run on Mir could run on an X server, including waylands rootless x server01:29
RAOFNo, that's not what it would guarantee. For that, you'd need a rootless Mir compositor, which doesn't make sense.01:30
RichardMIchaelsthas good to hear01:30
RichardMIchaelsIf you can display an entire rootless Mir session to an X server, it would indirectly allow Mir applications to to be displayed to a hardware X server or a wayland X server.01:32
RichardMIchaelsIf you could also allow Mir applications one by one to be displayed rootless to an X server, that would be great01:32
RichardMIchaelsOne of the issues is that there is a lot of old hardware out there, old video cards with no acceleration. the only driver for them is in the X server. Since qt and gtk support multiple backends, its not a big issue for those apps. The concern is that some people will make Mir only applications in the long run. So, its good to gaurantee that any Mir app can be displayed in someway to an X server.01:35
RichardMIchaelsYou would probably need a software OpenGL render that would render the things coming from a Mir app into an X protocol stream01:35
RichardMIchaelsMesa is capable of that01:36
RichardMIchaelsanother thing you could do is allow the user to create a rootless Mir session and then allow them to run a mirvncserver to allow it to be accessed by VNC. I would be happy with that01:42
RichardMIchaelsThis would give you remote desktop capabilities and also allow Mir to be used on a computer with a hardware connected X server01:43
RichardMIchaelsthat hits two birds with one stone01:45
RichardMIchaelsby rootless Mir session, I actually mean headless.01:47
RichardMIchaelsa headless Mir session01:47
racarrMy suspiscion is that for running Mir on old cards with no acceleration a framebuffer based graphics platform in mir would be most appropriate01:47
RichardMIchaelsSo, the Mir session runs, but, it does not display to a video card. Instead, its output goes out to VNC clients via a VNC server01:47
racarrAnd applications and mir can use whatever software GL implementation is available that can work on memory mapped buffers01:48
racarrif you have an X driver you can do this.01:48
racarrIt might even be simpler than that if a good abstraction in GBM can be found.01:50
racarrHaven't thought about it deeply though and am just about to take off for a while :)01:50
RichardMIchaelsRight. X drivers use framebuffers, and in some cases a 2D driver API called XAA, if i am correct.01:51
dufluAwesome to see other people are making Mir to be clang compatible. I was going to eventually...01:52
RichardMIchaelsOn the old hardware, you would either need to run an X server and then display a MIR session to it. or you would need to work the X drivers into Mir.01:53
RichardMIchaelsOr into KMS/DRI type Linux APis01:53
RichardMIchaelsclang is a cool compiler.01:54
RichardMIchaelsClang claims to support all of C++ up to the 98 standard. Software needs to be ported to it must use a lot of GCC only features. But Clang even supports many GCC features.01:58
RAOFWe don't use any (afaik) GCC only features. We *extensively* use C++11, though :)01:59
RichardMIchaelsi see02:00
RichardMIchaelsclang is working on full C++11 support if am not mistaken02:02
=== rsalveti_ is now known as rsalveti
MirvI do hope there won't be a mirvncserver or I'm going to have serious trouble on IRC06:32
Mirvalthough I guess irssi can be taught to avoid highlighting particular phrases :)06:33
RAOFMirv: Surely irssi doesn't highlight on substring matches?06:53
MirvRAOF: for me it does, because in Finnish we conjugate all words in so many ways that I need to07:56
CheeryI just looked into example code.07:59
CheeryI think EGL should be abstracted away. but this looks somewhat okay otherwise.08:00
Cheeryone thing though. why do you want server side buffer allocation?08:01
Cheeryhmm.. in other hand, MIR should not abstract away EGL.08:03
Cheery(EGL should be abstracted away, because we do not want such software that refuses to run because the platform is w rong)08:03
Cheery(but then.. we already have this stupid separation between GL_ES2  and GL2, and GL_ES3 vs. GL3, and GL408:04
Ranomier_Lets try today again.08:23
Ranomier_can somebody tell why canonical not just said someting about their plans 6 months ago? I dont talking about opening source code, im only talking about that their where able to just say: "hey we dont like that and that in wayland, we build our own display server".08:35
Ranomier_companys testet code with wayland on ubuntu and that work is for nothing08:36
RAOFWho tested code with Wayland on Ubuntu?08:45
dufluRanomier_: Yes, it's true there have been some public Ubuntu wiki pages floating around talking about how Ubuntu would support Wayland. However those alone were no contract committing Canonical to using Wayland. Canonical has the freedom to build what it likes. And I'm not sure what companies you're talking about testing with "Wayland on Ubuntu"... ?08:56
dufluFurthermore, Wayland is a protocol. So even if Ubuntu "used" Wayland, we would still need to build a display server for the Wayland protocol; Mir.08:58
Ranomier_@1: comm'on it is clear that there so no contract with the comunity. Ubuntu is for people and we are a family and we tell us so importand things. @2: Thats not display server u only have to replace weston.09:01
dufluCheery: I believe the main driver for server side allocation was the Android driver platform. Not sure. tvoss/alf can confirm.09:02
Ranomier_weston is the reference compositor, its just there for testing wayland.09:02
dufluYes, that's my point. Even to "support Wayland", Canonical would still need to build a display server and it may as well be called Mir. So it's really just an argument over protocols.09:03
Ranomier_ok wait, what is weston 1. a display server 2. a compositor ?09:04
tvossduflu, even more so, it's a question of a unified egl client platform, and that does not necessarily mean a protocol but a sane way of people to interface with an existing EGL client platform and the ability to define display server specific behavior09:04
* duflu can see tvoss's hands waiving in the air around a virtual architecture diragram09:05
tvossduflu, :)09:06
tvossduflu, more like saying: The android client-side EGL platform proposes a very similar approach, and it is quite elegant and straight-forward09:06
tvossCheery, for server-side buffer allocation: The decision used to be mostly driven by the android driver model, yes09:07
Cheerytvoss: does it affect client side or compositor?09:08
tvossCheery, how do you mean?09:08
dufluRanomier_: Outside of the X-world, the display server is typically the thing you build and it happens to do "composition". So platforms other than Xorg generally do not have "compositors", but display servers that do composition. This is supported by the statement here --> http://wayland.freedesktop.org/09:08
Cheerytvoss: does it affect the protocol between client or compositor, or render buffer creation of the client, or compositor's access into the buffers or modesetting?09:09
tvossCheery, it does to some degree, yes. If you do not have a client-side buffer allocation scheme, the client only needs to get hold of a surface, and start rendering and eglSwapBuffers advances the underlying buffers in a steady-state manner. Server-side, the surface could be backed by an arbitrary number of buffers09:10
Ranomier_but i cant belive that if ur talked to the community u can together make wayland what u need 6 months ago ... and i cant belive thats more of work.09:11
CheeryRanomier_: I don't know who am I talking with yet, so I ignore the 6-month claim entirely.09:12
CheeryRanomier_: I suggest you do so too.09:12
tvossalf_, please correct me if I'm wrong but access into buffers or modesetting is not affected @Cheery's question09:14
Cheerytvoss: so it'd be practically different on client-side?09:14
dufluThat's an interesting question. Surely the client/server-side buffer argument is an implementation detail. The client API will never make it obvious which is being used.09:15
duflu(It's opaque and abstracted)09:15
Cheeryand the protocol would not shift direction in passing a handle?09:15
tvossCheery, from a toolkit-perspective: no, it would be transparent to an app-developer. and as duflu points out, it is an implementation detail in the end09:15
Ranomier_ok, a complete other thing martin said he won´t support mir in kwin, because it is only one distro.09:16
RAOFHe's welcome to that; if Mir becomes awesome he might find it useful to build a KWin compositor on top of Mir, but that's unlikely.09:16
alf_tvoss: Cheery: that is correct (if I understood the question correctly)09:17
RAOFCheery: For reference, I'm in the process of changing the GBM buffer passing from flinked gem buffers to dma-buf fds. Clients don't see a change.09:17
tvossRAOF, you might want to clarify what is unlikely09:18
RAOFRanomier_: There's already a KWin branch turning it into a Wayland compositor; it's unlikely that they'd want to throw away that work.09:18
dufluKWin fans will still have the option of logging into KWin running on X, running on xmir. I'm sure that would work right now. Do we need to make a video?09:19
RAOFduflu: It'd totally work now; I'm not going to make a video right now, though :)09:19
dufluRAOF: Yeah sorry. I wasn't asking you to09:19
Cheeryif compositor, client, and protocol between them doesn't change, I don't know why it matters to Mir or Wayland.09:19
dufluRAOF: In fact it's the evening. Surely you have family stuff :)09:20
RAOFWell, as long as I lined up all the bits; the dma-buf transition is incomplete, so trunk of everything doesn't quite work together.09:20
Cheerysince it means both of them could  use either client-side allocated or server-side allocated buffers.09:20
Cheerydepending of platform09:20
Cheeryit's something that is flushed under driver API anyway.09:21
RAOFJust to be clear - clients *can* care, if they choose to. If they want (or need, like XMir) access at a lower level than EGL, they get to pay the price of dealing with that.09:22
Cheerylower level than EGL.. doesn't that mean going under the binary blob driver that supplies the EGL?09:24
Cheeryalso I'm letting you know one thing.09:25
CheeryXMir becomes obsolete in 2 years09:26
Cheeryonce things really work09:26
CheeryI couldn't care less about dysfunctional X programs that belong to 1985 and are never used or ported to Mir/Wayland09:26
Cheeryso if something does bit inefficiently there, nobody cares09:27
Ranomier_an associate asking is there source code of mir?09:28
Cheeryyes. I studied it just small while ago09:28
Ranomier_where i can find it?09:28
Cheerythey're having just egl example  program right now.09:29
CheeryI hope they'd get some beta API for nvidia really soon09:29
Cheerythat's what everybody cares about anyway09:30
dufluCheery: Canonical knows very well that a desktop without Nvidia support is not a desktop. And nouveau's not really good enough right now.09:30
Cheerythings fall into place once that hapens09:31
Cheeryafter that we'll get chrome ported to Mir pretty fast, as well as steam.09:32
Cheerythen everybody are using Mir.09:32
Cheerythe tension has been building since 199709:33
CheeryI think it'll also get the steamboxes and all that stuff by valve rolling up09:35
Cheerylinux becomes a practical desktop and we'll see things are going to change and fast09:35
Cheeryit's also time bomb for Mir.09:37
Cheeryonce nvidia gets the API rolled out, Mir will work by the end of this year, or there will be something else that does the thing.09:38
Ranomier_if canonical worked upstream in wayland, where would we be now?09:44
Ranomier_i mean wayland is ready, mir not ...09:44
Ranomier_if i see the version number of mir 0.0.209:45
alf_Ranomier_: probably at the same (or worse) place, since the bulk of the work is in the display server implementation itself, not the protocol09:46
Ranomier_ok the wayland protocol is well defined for ur usecases, but the core not?09:47
Ranomier_i mean many companys say now, lets wait ... we build our products on x until they maked a decision wich where the standart. becouse a co existend of wayland and mir is horror^^09:49
alf_Ranomier_: I depends on the product. In most cases you don't really care whether it's X11 or Wayland or Mir, because you are using a toolkit that shields you from the details.09:51
Ranomier_my company builds iptv with a telephone for hospitals.09:51
Ranomier_we have our own toolkit^^09:52
CheeryRanomier_: I don't see it that way.09:52
CheeryX is retarding system, not an option if there's something alternative.09:53
Ranomier_im not a programmer in my company im only a admin^^09:53
Cheeryalso you have web for things that really always need to work.09:53
Ranomier_But x has many performance problems with vsync.09:54
Cheeryalso it's again.. freedom of choice09:55
Cheerythere will be commercial apps for both Mir and wayland.. and systems ported for both09:55
dufluRanomier_: Vsync problems are mostly driver issues. Except when they're compositor bugs like with Compiz 12 months ago for example09:56
Cheerythere will be compositors made for both protocols.09:56
Ranomier_and linux is again cluttering09:57
CheeryI think next thing they freak after is the audio system09:58
Cheerybut it's not as bad thing as this was.09:58
Cheerylinux audio problems are mostly made by linux devs.10:00
Cheerynot by some company that decided to force everyone into Xorg flavour of linux.10:01
Ranomier_i like systemd of poetering but pulse is fail. an audio system should an part of the kernel and it has to stand alone, no alsa->pulseadio-jack things.10:01
Cheerythat decision was as if someone had excreted into ice cream pool.10:01
Cheery"now you only eat this kind of ice cream bwahahahaaha!!"10:02
Cheery"take that! freedom!"10:02
Cheery"you have freedom to eat ice cream, as long as there's crap in it."10:03
CheeryRanomier_: I think MIDI should be phased out from audio system10:05
Cheeryit's not audio10:05
Cheeryit's more like peripheral input/output10:05
=== mmrazik is now known as mmrazik|lunch
=== popey_ is now known as popey
=== mmrazik|lunch is now known as mmrazik
=== nekohayo` is now known as nekohayo
=== mmrazik is now known as mmrazik|otp
=== mmrazik|otp is now known as mmrazik
=== mmrazik is now known as mmrazik|afk
=== mmrazik|afk is now known as mmrazik
=== yofel_ is now known as yofel
=== mmrazik is now known as mmrazik|afk
=== mhall119 is now known as mhall119|lunch
=== mmrazik|afk is now known as mmrazik
=== mhall119|lunch is now known as mhall119
ezakimakqq: any possibility/plan to make use of the enlightenment evas/other libs?18:49
bryceezakimak, no plans that I'm aware of20:19
ezakimakjust heard that their software renderer is very fast, no idea if their code could be reused in mir though.20:22
robert_ancellracarr, can you set me to be a channel op?20:43
mhall119robert_ancell: you can probably request it in #ubuntu-irc20:45
racarrrobert_ancell: Done20:45
racarrwas lunching20:45
=== robert_ancell changed the topic of #ubuntu-mir to: Mir - http://launchpad.net/mir https://wiki.ubuntu.com/MirSpec
robert_ancellracarr, ta20:46
racarrI introduced a rather difficult merge conflict for myself ;) one of these days I will learn how to use version control20:56
=== kgunn is now known as kgunnAFK
RAOFkdub: Yo!22:04
RAOFkdub: Did you see the rest of my ping yesterday, re: AndroidClientBufferDepository?22:06
kdubRAOF, ah yes... i left it building somewhere in one of these terminals...22:44
kdubRAOF, i'll give it a try, it looked like it would work22:44
RAOFkdub: I hadn't yet done the refactoring; I wanted to ask if what the constraints were first.22:44
RAOFWhy are all blog comment systems terrible?22:46
kdubRAOF, the constraints are that I found that mapping/munmapping buffers repeatedly on android doesn't work22:48
RAOFkdub: Oh, so once you've seen a buffer you *have* to keep it around *forever*?22:48
kdubRAOF, unfortunately thats what I've  found :/ we can munmap it  once we're done with it forever22:49
kdubRAOF, let me find you the header....22:50
kdubfunction 'unregisterBuffer' (munmap) makes it an error to call 'registerBuffer' (mmap) on the buffer once you've let it go22:52
RAOFOk, so if I refactor out ClientBufferDepository I need to ensure that Android keeps all its buffers forever.23:01
kdubyeah, its weird23:05
RAOFActually... couldn't we handle this server-side, in cooperation with the client library?23:10
RAOFkdub: If the server guaranteed that it wouldn't send a buffer more than 3 frames old (ie: if we're triple buffering), then the client library could forget buffers older than 3 frames.23:11
RAOFkdub: The small flaw I can see is the framebuffer - if we only have 6 framebuffers to play with, maybe we can't do that.23:12
kdubRAOF, i like that rule... but i think that 3 limit should be adjustable23:12
RAOFkdub: By whom?23:13
kdubwe can do n-buffer swapping, and the android api's allow the drivers to acquire more than 1 at once23:13
kdubso if the driver starts requesting 2 buffers at once, or if we're doing n-buffering23:13
RAOFWe currently only do double or triple bufferring, and throw an exception if we try and do anything else :)23:14
RAOFI'm not averse to having the server tell the client how many buffers it needs to remember, though.23:14
kdubRAOF, sure, as long as the number is adjustable, its ok by me :)23:15
RAOFI'll initially do it as a construct-time property; if that needs to change at runtime, we can make the change when we need it ;)23:16
racarrI've changed my hmm to nvm23:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!