| racarr | RAOF: Im here! | 00:24 |
|---|---|---|
| RAOF | racarr: Oh! Because you've got ops! | 00:25 |
| * RAOF was scanning the user list, and you weren't where I expected :) | 00:26 | |
| racarr | :) | 00:27 |
| racarr | https://code.launchpad.net/~robertcarr/mir/prepare-session-manager-for-input-focus/+merge/152806 for the bored reviewers :) | 00:40 |
| RichardMIchaels | I 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 |
| RAOF | We do indeed plan to do that (an X backend for Mir) | 01:29 |
| RichardMIchaels | Which would gaurantee that any application that could run on Mir could run on an X server, including waylands rootless x server | 01:29 |
| RAOF | No, that's not what it would guarantee. For that, you'd need a rootless Mir compositor, which doesn't make sense. | 01:30 |
| RichardMIchaels | thas good to hear | 01:30 |
| RichardMIchaels | If 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 |
| RichardMIchaels | If you could also allow Mir applications one by one to be displayed rootless to an X server, that would be great | 01:32 |
| RichardMIchaels | One 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 |
| RichardMIchaels | You would probably need a software OpenGL render that would render the things coming from a Mir app into an X protocol stream | 01:35 |
| RichardMIchaels | Mesa is capable of that | 01:36 |
| RAOF | brb | 01:38 |
| RichardMIchaels | another 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 that | 01:42 |
| RichardMIchaels | This would give you remote desktop capabilities and also allow Mir to be used on a computer with a hardware connected X server | 01:43 |
| RichardMIchaels | that hits two birds with one stone | 01:45 |
| RichardMIchaels | by rootless Mir session, I actually mean headless. | 01:47 |
| RichardMIchaels | a headless Mir session | 01:47 |
| racarr | My suspiscion is that for running Mir on old cards with no acceleration a framebuffer based graphics platform in mir would be most appropriate | 01:47 |
| RichardMIchaels | So, the Mir session runs, but, it does not display to a video card. Instead, its output goes out to VNC clients via a VNC server | 01:47 |
| racarr | And applications and mir can use whatever software GL implementation is available that can work on memory mapped buffers | 01:48 |
| racarr | if you have an X driver you can do this. | 01:48 |
| racarr | It might even be simpler than that if a good abstraction in GBM can be found. | 01:50 |
| racarr | Haven't thought about it deeply though and am just about to take off for a while :) | 01:50 |
| RichardMIchaels | Right. X drivers use framebuffers, and in some cases a 2D driver API called XAA, if i am correct. | 01:51 |
| duflu | Awesome to see other people are making Mir to be clang compatible. I was going to eventually... | 01:52 |
| RichardMIchaels | On 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 |
| RichardMIchaels | Or into KMS/DRI type Linux APis | 01:53 |
| RichardMIchaels | clang is a cool compiler. | 01:54 |
| RichardMIchaels | Clang 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 |
| RAOF | We don't use any (afaik) GCC only features. We *extensively* use C++11, though :) | 01:59 |
| RichardMIchaels | i see | 02:00 |
| RichardMIchaels | clang is working on full C++11 support if am not mistaken | 02:02 |
| === rsalveti_ is now known as rsalveti | ||
| Mirv | I do hope there won't be a mirvncserver or I'm going to have serious trouble on IRC | 06:32 |
| Mirv | although I guess irssi can be taught to avoid highlighting particular phrases :) | 06:33 |
| Cheery | sup? | 06:48 |
| RAOF | Mirv: Surely irssi doesn't highlight on substring matches? | 06:53 |
| Mirv | RAOF: for me it does, because in Finnish we conjugate all words in so many ways that I need to | 07:56 |
| RAOF | Heh | 07:56 |
| Cheery | I just looked into example code. | 07:59 |
| Cheery | I think EGL should be abstracted away. but this looks somewhat okay otherwise. | 08:00 |
| Cheery | one thing though. why do you want server side buffer allocation? | 08:01 |
| Cheery | hmm.. 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 GL4 | 08: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 nothing | 08:36 |
| RAOF | Who tested code with Wayland on Ubuntu? | 08:45 |
| duflu | Ranomier_: 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 |
| duflu | Furthermore, 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 |
| duflu | Cheery: 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 |
| duflu | Yes, 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 |
| tvoss | duflu, 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 behavior | 09:04 |
| * duflu can see tvoss's hands waiving in the air around a virtual architecture diragram | 09:05 | |
| duflu | diagram | 09:06 |
| tvoss | duflu, :) | 09:06 |
| tvoss | duflu, more like saying: The android client-side EGL platform proposes a very similar approach, and it is quite elegant and straight-forward | 09:06 |
| tvoss | Cheery, for server-side buffer allocation: The decision used to be mostly driven by the android driver model, yes | 09:07 |
| Cheery | tvoss: does it affect client side or compositor? | 09:08 |
| tvoss | Cheery, how do you mean? | 09:08 |
| duflu | Ranomier_: 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 |
| Cheery | tvoss: 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 |
| tvoss | Cheery, 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 buffers | 09: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 |
| Cheery | Ranomier_: I don't know who am I talking with yet, so I ignore the 6-month claim entirely. | 09:12 |
| Cheery | Ranomier_: I suggest you do so too. | 09:12 |
| tvoss | alf_, please correct me if I'm wrong but access into buffers or modesetting is not affected @Cheery's question | 09:14 |
| Cheery | tvoss: so it'd be practically different on client-side? | 09:14 |
| duflu | That'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 |
| Cheery | and the protocol would not shift direction in passing a handle? | 09:15 |
| tvoss | Cheery, 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 end | 09:15 |
| Ranomier_ | ok, a complete other thing martin said he won´t support mir in kwin, because it is only one distro. | 09:16 |
| RAOF | He'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 |
| RAOF | Cheery: 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 |
| tvoss | RAOF, you might want to clarify what is unlikely | 09:18 |
| tvoss | :) | 09:18 |
| RAOF | Ranomier_: 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 |
| duflu | KWin 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 |
| duflu | RAOF^ | 09:19 |
| RAOF | duflu: It'd totally work now; I'm not going to make a video right now, though :) | 09:19 |
| duflu | RAOF: Yeah sorry. I wasn't asking you to | 09:19 |
| Cheery | if compositor, client, and protocol between them doesn't change, I don't know why it matters to Mir or Wayland. | 09:19 |
| duflu | RAOF: In fact it's the evening. Surely you have family stuff :) | 09:20 |
| RAOF | Well, 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 |
| Cheery | since it means both of them could use either client-side allocated or server-side allocated buffers. | 09:20 |
| Cheery | depending of platform | 09:20 |
| Cheery | it's something that is flushed under driver API anyway. | 09:21 |
| RAOF | Just 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 |
| Cheery | lower level than EGL.. doesn't that mean going under the binary blob driver that supplies the EGL? | 09:24 |
| Cheery | also I'm letting you know one thing. | 09:25 |
| Cheery | XMir becomes obsolete in 2 years | 09:26 |
| Cheery | once things really work | 09:26 |
| Cheery | I couldn't care less about dysfunctional X programs that belong to 1985 and are never used or ported to Mir/Wayland | 09:26 |
| Cheery | so if something does bit inefficiently there, nobody cares | 09:27 |
| Ranomier_ | an associate asking is there source code of mir? | 09:28 |
| Cheery | yes. I studied it just small while ago | 09:28 |
| Ranomier_ | where i can find it? | 09:28 |
| Cheery | https://wiki.ubuntu.com/MirSpec | 09:28 |
| Cheery | https://launchpad.net/mir | 09:28 |
| Cheery | http://bazaar.launchpad.net/~mir-team/mir/trunk/files | 09:29 |
| Cheery | they're having just egl example program right now. | 09:29 |
| Cheery | I hope they'd get some beta API for nvidia really soon | 09:29 |
| Cheery | that's what everybody cares about anyway | 09:30 |
| duflu | Cheery: 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 |
| Cheery | things fall into place once that hapens | 09:31 |
| Cheery | after that we'll get chrome ported to Mir pretty fast, as well as steam. | 09:32 |
| Cheery | then everybody are using Mir. | 09:32 |
| Cheery | the tension has been building since 1997 | 09:33 |
| Cheery | I think it'll also get the steamboxes and all that stuff by valve rolling up | 09:35 |
| Cheery | linux becomes a practical desktop and we'll see things are going to change and fast | 09:35 |
| Cheery | it's also time bomb for Mir. | 09:37 |
| Cheery | once 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.2 | 09:45 |
| Ranomier_ | ... | 09: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 protocol | 09: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 |
| Ranomier_ | because* | 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 |
| Cheery | Ranomier_: I don't see it that way. | 09:52 |
| Cheery | X 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 |
| Cheery | also you have web for things that really always need to work. | 09:53 |
| Ranomier_ | But x has many performance problems with vsync. | 09:54 |
| Cheery | also it's again.. freedom of choice | 09:55 |
| Cheery | there will be commercial apps for both Mir and wayland.. and systems ported for both | 09:55 |
| duflu | Ranomier_: Vsync problems are mostly driver issues. Except when they're compositor bugs like with Compiz 12 months ago for example | 09:56 |
| Cheery | there will be compositors made for both protocols. | 09:56 |
| Ranomier_ | and linux is again cluttering | 09:57 |
| Cheery | I think next thing they freak after is the audio system | 09:58 |
| Cheery | but it's not as bad thing as this was. | 09:58 |
| Cheery | linux audio problems are mostly made by linux devs. | 10:00 |
| Cheery | not 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 |
| Cheery | that 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 |
| Cheery | Ranomier_: I think MIDI should be phased out from audio system | 10:05 |
| Cheery | it's not audio | 10:05 |
| Cheery | it's more like peripheral input/output | 10: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 | ||
| ezakimak | qq: any possibility/plan to make use of the enlightenment evas/other libs? | 18:49 |
| bryce | ezakimak, no plans that I'm aware of | 20:19 |
| ezakimak | just heard that their software renderer is very fast, no idea if their code could be reused in mir though. | 20:22 |
| robert_ancell | racarr, can you set me to be a channel op? | 20:43 |
| mhall119 | robert_ancell: you can probably request it in #ubuntu-irc | 20:45 |
| racarr | robert_ancell: Done | 20:45 |
| racarr | was lunching | 20:45 |
| === robert_ancell changed the topic of #ubuntu-mir to: Mir - http://launchpad.net/mir https://wiki.ubuntu.com/MirSpec | ||
| robert_ancell | racarr, ta | 20:46 |
| racarr | I introduced a rather difficult merge conflict for myself ;) one of these days I will learn how to use version control | 20:56 |
| === kgunn is now known as kgunnAFK | ||
| RAOF | kdub: Yo! | 22:04 |
| RAOF | kdub: Did you see the rest of my ping yesterday, re: AndroidClientBufferDepository? | 22:06 |
| kdub | RAOF, ah yes... i left it building somewhere in one of these terminals... | 22:44 |
| kdub | RAOF, i'll give it a try, it looked like it would work | 22:44 |
| RAOF | kdub: I hadn't yet done the refactoring; I wanted to ask if what the constraints were first. | 22:44 |
| RAOF | Why are all blog comment systems terrible? | 22:46 |
| kdub | RAOF, the constraints are that I found that mapping/munmapping buffers repeatedly on android doesn't work | 22:48 |
| RAOF | kdub: Oh, so once you've seen a buffer you *have* to keep it around *forever*? | 22:48 |
| kdub | RAOF, unfortunately thats what I've found :/ we can munmap it once we're done with it forever | 22:49 |
| kdub | RAOF, let me find you the header.... | 22:50 |
| kdub | https://github.com/CyanogenMod/android_hardware_libhardware/blob/jellybean/include/hardware/gralloc.h | 22:51 |
| kdub | function 'unregisterBuffer' (munmap) makes it an error to call 'registerBuffer' (mmap) on the buffer once you've let it go | 22:52 |
| RAOF | Meep. | 22:59 |
| RAOF | Ok, so if I refactor out ClientBufferDepository I need to ensure that Android keeps all its buffers forever. | 23:01 |
| kdub | yeah, its weird | 23:05 |
| RAOF | Actually... couldn't we handle this server-side, in cooperation with the client library? | 23:10 |
| RAOF | kdub: 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 |
| RAOF | kdub: 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 |
| kdub | RAOF, i like that rule... but i think that 3 limit should be adjustable | 23:12 |
| RAOF | kdub: By whom? | 23:13 |
| kdub | we can do n-buffer swapping, and the android api's allow the drivers to acquire more than 1 at once | 23:13 |
| kdub | so if the driver starts requesting 2 buffers at once, or if we're doing n-buffering | 23:13 |
| RAOF | We currently only do double or triple bufferring, and throw an exception if we try and do anything else :) | 23:14 |
| RAOF | I'm not averse to having the server tell the client how many buffers it needs to remember, though. | 23:14 |
| kdub | RAOF, sure, as long as the number is adjustable, its ok by me :) | 23:15 |
| RAOF | I'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 |
| kdub | sure | 23:17 |
| racarr | hmm | 23:25 |
| racarr | I've changed my hmm to nvm | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!