View difference between Paste ID: KjRm3be1 and t9x1tjC9

-    23:50 <RAOF> Heh. It's our turn to pull a systemd!
+23:50 <RAOF> Heh. It's our turn to pull a systemd!
-    23:50 <runeks> RAOF: did you know about this?
+23:50 <runeks> RAOF: did you know about this?
-    23:50 <RAOF> Yes; hence my lack of work on the wayland system compositor branches.
+23:50 <RAOF> Yes; hence my lack of work on the wayland system compositor branches.
-    23:53 <Darxus> RAOF: I kind of wondered if that was the case.
+23:53 <Darxus> RAOF: I kind of wondered if that was the case.
-    23:55 <krh> RAOF: the technical reasons on the mir page just don't add up
+23:55 <krh> RAOF: the technical reasons on the mir page just don't add up
-    23:55 <runeks> It's going to be interesting, that's for sure. I just hope we end up with a good new display server, and not two fairly good DSs
+23:55 <runeks> It's going to be interesting, that's for sure. I just hope we end up with a good new display server, and not two fairly good DSs
-    23:57  * RAOF checks the Mir page again
+23:57  * RAOF checks the Mir page again
-    23:58 <runeks> krh: What about this, does it have merit?
+23:58 <runeks> krh: What about this, does it have merit?
-    23:58 <runeks> "[...] it [Wayland] exposes privileged sections like the shell integration that we planned to handle differently, both for security reasons and as we wanted to decouple the way the shell works on top of the display server from the application-facing protocol."
+23:58 <runeks> "[...] it [Wayland] exposes privileged sections like the shell integration that we planned to handle differently, both for security reasons and as we wanted to decouple the way the shell works on top of the display server from the application-facing protocol."
-    23:58 <krh> runeks: everything about input
+23:58 <krh> runeks: everything about input
-    23:59 <runeks> From this blog post: http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/
+23:59 <runeks> From this blog post: http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/
-    -!- Day changed to Tuesday, March 05, 2013
+-!- Day changed to Tuesday, March 05, 2013
-    00:00 <krh> there's nothing priviledge about wl_shell
+00:00 <krh> there's nothing priviledge about wl_shell
-    00:00 <krh> I think the author mistakes it for the interface required to implement a shell
+00:00 <krh> I think the author mistakes it for the interface required to implement a shell
-    00:01 <krh> that interface is desktop_shell and is only available to the desktop-shell.c client that the compositor forks
+00:01 <krh> that interface is desktop_shell and is only available to the desktop-shell.c client that the compositor forks
-    00:01 <RAOF> I think the more compelling argument is the argument-from-design - we want to build something that exactly matches our specifications. If we use libwayland and then change all the protocol, is that still wayland?
+00:01 <RAOF> I think the more compelling argument is the argument-from-design - we want to build something that exactly matches our specifications. If we use libwayland and then change all the protocol, is that still wayland?
-    00:01 <airlied> RAOF: if you do it upstream, yes
+00:01 <airlied> RAOF: if you do it upstream, yes
-    00:02 <airlied> I think the most compelling argument is argument-from-control-of-project
+00:02 <airlied> I think the most compelling argument is argument-from-control-of-project
-    00:02 <krh> RAOF: or just do that, but don't go out and tell the whole world how wayland is broken and has all X's input problems
+00:02 <krh> RAOF: or just do that, but don't go out and tell the whole world how wayland is broken and has all X's input problems
-    00:02 <RAOF> airlied: I think that people in charge are uncertain that it would be accepted upstream.
+00:02 <RAOF> airlied: I think that people in charge are uncertain that it would be accepted upstream.
-    00:02 <krh> that's what pisses me off
+00:02 <krh> that's what pisses me off
-    00:02 <krh> you can do whatever you want and you don't need my permission
+00:02 <krh> you can do whatever you want and you don't need my permission
-    00:02 <krh> but don't piss on wayland in the process
+00:02 <krh> but don't piss on wayland in the process
-    00:02 <airlied> RAOF: you work upstream, you don't have to be accepted
+00:02 <airlied> RAOF: you work upstream, you don't have to be accepted
-    00:03 <airlied> yes if you dump 6 months of in-house development on upstream, they might not accept it, so hey don't do that
+00:03 <airlied> yes if you dump 6 months of in-house development on upstream, they might not accept it, so hey don't do that
-    00:03 <RAOF> airlied: You always have to be accepted, unless you want to fork?
+00:03 <RAOF> airlied: You always have to be accepted, unless you want to fork?
-    00:03 <crazedpsyc> ugh, this is so annoying. "We don't understand wayland, so we need to create our own system from scratch"
+00:03 <crazedpsyc> ugh, this is so annoying. "We don't understand wayland, so we need to create our own system from scratch"
-    00:04 <RAOF> krh: I'm unfamiliar with wayland's input handling, except that last time I looked it had approximately no input handling. But given daniels has been working on it for some time now I expect that's changed.
+00:04 <RAOF> krh: I'm unfamiliar with wayland's input handling, except that last time I looked it had approximately no input handling. But given daniels has been working on it for some time now I expect that's changed.
-    00:05 <airlied> RAOF: fail, you assign devs to work on the upstream project, to enact your design
+00:05 <airlied> RAOF: fail, you assign devs to work on the upstream project, to enact your design
-    00:05 <RAOF> krh: I don't think we *meant* to piss all over wayland.
+00:05 <RAOF> krh: I don't think we *meant* to piss all over wayland.
-    00:05 <krh> RAOF: yes, so don't go and tell the world it's broken
+00:05 <krh> RAOF: yes, so don't go and tell the world it's broken
-    00:05 <krh> if you don't know what it is
+00:05 <krh> if you don't know what it is
-    00:05 <airlied> they become part of the upstream project, and are no different
+00:05 <airlied> they become part of the upstream project, and are no different
-    00:06 <krh> RAOF: I understand you have other reasons for not using wayland and that's what it is, but put that on your web page instead of say "wayland has all of X's input security problems"
+00:06 <krh> RAOF: I understand you have other reasons for not using wayland and that's what it is, but put that on your web page instead of say "wayland has all of X's input security problems"
-    00:06 <RAOF> krh: I don't think we *did* say that? It's a mistake if so - wayland certainly doesn't.
+00:06 <RAOF> krh: I don't think we *did* say that? It's a mistake if so - wayland certainly doesn't.
-    00:06 <krh> I'll have fun explaining how that's not the case to everybody for the next few months
+00:06 <krh> I'll have fun explaining how that's not the case to everybody for the next few months
-    00:07 <airlied> krh: definitely need a single place of explaination to point others a
+00:07 <airlied> krh: definitely need a single place of explaination to point others a
-    00:07 -!- olesalscheider [~olesalsch@2001:4dd0:ff00:835c:6ef0:49ff:fe02:25e3] has quit [Quit: Konversation terminated!]
+00:07 -!- olesalscheider [~olesalsch@2001:4dd0:ff00:835c:6ef0:49ff:fe02:25e3] has quit [Quit: Konversation terminated!]
-    00:07 <krh> RAOF: I honestly don't think there are any techical reasons you couldn't use wayland and you could do your own extension for the secret sauce
+00:07 <krh> RAOF: I honestly don't think there are any techical reasons you couldn't use wayland and you could do your own extension for the secret sauce
-    00:08 <krh> RAOF: but I know Iit has to be under C control and be GPL CLA so that fine
+00:08 <krh> RAOF: but I know Iit has to be under C control and be GPL CLA so that fine
-    00:08 <RAOF> krh: Likewise; but is that actually *useful* if we replace all the interfaces?
+00:08 <RAOF> krh: Likewise; but is that actually *useful* if we replace all the interfaces?
-    00:08 <krh> but those reasons look bad on the web page, I know
+00:08 <krh> but those reasons look bad on the web page, I know
-    00:08 -!- uartie [uartie@nat/intel/x-bcdajueitxzaktln] has joined #wayland
+00:08 -!- uartie [uartie@nat/intel/x-bcdajueitxzaktln] has joined #wayland
-    00:08 <RAOF> airlied: That assumes everyone upstream shares the same goals?
+00:08 <RAOF> airlied: That assumes everyone upstream shares the same goals?
-    00:08 <krh> RAOF: I don't think you need to replace them
+00:08 <krh> RAOF: I don't think you need to replace them
-    00:08 <airlied> RAOF: okay if your goals are GPL and company controlled, then probably not
+00:08 <airlied> RAOF: okay if your goals are GPL and company controlled, then probably not
-    00:09 <krh> none of the reasons listed on the page are valid
+00:09 <krh> none of the reasons listed on the page are valid
-    00:09 -!- msclrhd [~msclrhd@85.211.124.135] has joined #wayland
+00:09 -!- msclrhd [~msclrhd@85.211.124.135] has joined #wayland
-    00:09 <krh> none of them calls for a change in any of the core interfaces
+00:09 <krh> none of them calls for a change in any of the core interfaces
-    00:11 <RAOF> I don't think we want much of wl_shell_surface; we want different buffer allocation semantics. Probably a couple more things.
+00:11 <RAOF> I don't think we want much of wl_shell_surface; we want different buffer allocation semantics. Probably a couple more things.
-    00:12 -!- plombo [~plombo@129.15.131.187] has joined #wayland
+00:12 -!- plombo [~plombo@129.15.131.187] has joined #wayland
-    00:12 <krh> RAOF: yes! that 's the point you're missing wl_shell and wl_shell_surface is like EWMH, it's an optional extension to wayland, it's like EWMH for X
+00:12 <krh> RAOF: yes! that 's the point you're missing wl_shell and wl_shell_surface is like EWMH, it's an optional extension to wayland, it's like EWMH for X
-    00:12 <krh> it's like throwing X away because EMWH isn't a fit for what you want to build
+00:12 <krh> it's like throwing X away because EMWH isn't a fit for what you want to build
-    00:13 <krh> there's event a tablet-shell example/mockup in weston to illustrate how you can build a new shell type
+00:13 <krh> there's event a tablet-shell example/mockup in weston to illustrate how you can build a new shell type
-    00:13 <krh> *even
+00:13 <krh> *even
-    00:13 <RAOF> But if you don't have the wl_shell, wl_shell_surface, or buffer semantics, is what way is it actually wayland?
+00:13 <RAOF> But if you don't have the wl_shell, wl_shell_surface, or buffer semantics, is what way is it actually wayland?
-    00:13 <krh> RAOF: different buffer allocation semantics?
+00:13 <krh> RAOF: different buffer allocation semantics?
-    00:14 <RAOF> Server-allocated buffers
+00:14 <RAOF> Server-allocated buffers
-    00:14 -!- tangentstorm [~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net] has left #wayland["WeeChat 0.3.2"]
+00:14 -!- tangentstorm [~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net] has left #wayland["WeeChat 0.3.2"]
-    00:14 <krh> RAOF: yes, wl_shell and wl_shell_surface aren't core wayland
+00:14 <krh> RAOF: yes, wl_shell and wl_shell_surface aren't core wayland
-    00:14 <krh> and server allocated vs client allocated isn't a wayland protocol thing
+00:14 <krh> and server allocated vs client allocated isn't a wayland protocol thing
-    00:14 <krh> or even a weston thing
+00:14 <krh> or even a weston thing
-    00:15 <krh> it's in the wl_drm interface, which is EGL driver specific
+00:15 <krh> it's in the wl_drm interface, which is EGL driver specific
-    00:15 <RAOF> If you're replacing all the shell-y bits, and the buffer allocation, you'd need both a wayland-mir and wayland-weston backend for your toolkit, right?
+00:15 <RAOF> If you're replacing all the shell-y bits, and the buffer allocation, you'd need both a wayland-mir and wayland-weston backend for your toolkit, right?
-    00:15 <Prf_Jakob> RAOF: why do you guys want server-allocated buffers?
+00:15 <Prf_Jakob> RAOF: why do you guys want server-allocated buffers?
-    00:15 <RAOF> Prf_Jakob: Mostly arm damage, there.
+00:15 <RAOF> Prf_Jakob: Mostly arm damage, there.
-    00:15 <Prf_Jakob> RAOF: so thats whats its really about then? Closed source drivers?
+00:15 <Prf_Jakob> RAOF: so thats whats its really about then? Closed source drivers?
-    00:16 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has joined #wayland
+00:16 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has joined #wayland
-    00:16 <RAOF> No - arm hardware (apparently) has insane constraints that make server allocation more attractive.
+00:16 <RAOF> No - arm hardware (apparently) has insane constraints that make server allocation more attractive.
-    00:16 <krh> but that's not something wayland can't support
+00:16 <krh> but that's not something wayland can't support
-    00:16  * magn3ts probably missed all of the interesting Mir talk :(
+00:16  * magn3ts probably missed all of the interesting Mir talk :(
-    00:16 <RAOF> eg - you have at most 6 buffers that are framebuffer-compatible.
+00:16 <RAOF> eg - you have at most 6 buffers that are framebuffer-compatible.
-    00:16 <krh> we have those GPUs at intel too
+00:16 <krh> we have those GPUs at intel too
-    00:17 <krh> weston runs on those
+00:17 <krh> weston runs on those
-    00:18 <krh> RAOF: I realize that this all isn't really documented, but it's not like wayland oly works with client side allocated buffers
+00:18 <krh> RAOF: I realize that this all isn't really documented, but it's not like wayland oly works with client side allocated buffers
-    00:18 -!- mayhew [~justin@hlfxns0163w-047054165110.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #wayland
+00:18 -!- mayhew [~justin@hlfxns0163w-047054165110.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #wayland
-    00:18 -!- gallo [gallo@2a02:1610:1:1003:20c:29ff:fe3e:4633] has joined #wayland
+00:18 -!- gallo [gallo@2a02:1610:1:1003:20c:29ff:fe3e:4633] has joined #wayland
-    00:18 <RAOF> krh: I know we could have added a wl_server_side or somesuch interface, yea.
+00:18 <RAOF> krh: I know we could have added a wl_server_side or somesuch interface, yea.
-    00:19 <krh> RAOF: no, you write a wl_drm interface that your driver uses
+00:19 <krh> RAOF: no, you write a wl_drm interface that your driver uses
-    00:19 <Darxus> It seems weird that this conversation didn't happen before the mir announcement / decision.
+00:19 <Darxus> It seems weird that this conversation didn't happen before the mir announcement / decision.
-    00:19 <krh> wl_drm replacement
+00:19 <krh> wl_drm replacement
-    00:20 <RAOF> That's what I meant; I presumed calling it wl_drm would be a horrible name collision, though.
+00:20 <RAOF> That's what I meant; I presumed calling it wl_drm would be a horrible name collision, though.
-    00:20 <krh> RAOF: if your driver want to do server side allocation, your driver will use a wl_$driver interface to do that
+00:20 <krh> RAOF: if your driver want to do server side allocation, your driver will use a wl_$driver interface to do that
-    00:20 -!- cdidd [~cdidd@128-72-120-234.broadband.corbina.ru] has joined #wayland
+00:20 -!- cdidd [~cdidd@128-72-120-234.broadband.corbina.ru] has joined #wayland
-    00:20 <krh> yeah, but you don't call it that
+00:20 <krh> yeah, but you don't call it that
-    00:21 <krh> on the server side your driver installs a driver specific extension
+00:21 <krh> on the server side your driver installs a driver specific extension
-    00:21 <krh> on the client side your egl client looks for that extension
+00:21 <krh> on the client side your egl client looks for that extension
-    00:21 <Prf_Jakob> RAOF: fair enough, you probably want to implement eviction anyways otherwise you might end up with clients DDoS:ing your server easily.
+00:21 <Prf_Jakob> RAOF: fair enough, you probably want to implement eviction anyways otherwise you might end up with clients DDoS:ing your server easily.
-    00:21 <krh> the driver on the client side uses that extension to allocate buffers, share them with the server, exchange sync primitive, anything your driver needs to communicate between client and server
+00:21 <krh> the driver on the client side uses that extension to allocate buffers, share them with the server, exchange sync primitive, anything your driver needs to communicate between client and server
-    00:22 -!- ioo [~ioo@81-237-244-214-no52.tbcn.telia.com] has joined #wayland
+00:22 -!- ioo [~ioo@81-237-244-214-no52.tbcn.telia.com] has joined #wayland
-    00:22 <krh> it's how nvidia implements their binary X driver - they have a server side part that installs an nvidia extension that the client side drivers looks for
+00:22 <krh> it's how nvidia implements their binary X driver - they have a server side part that installs an nvidia extension that the client side drivers looks for
-    00:22 <RAOF> But, again, if we're exposing a protocol different enough that toolkits need different backends for westonish and mirish, and we're not forking weston, what does it buy *anyone* for us to use libwayland?
+00:22 <RAOF> But, again, if we're exposing a protocol different enough that toolkits need different backends for westonish and mirish, and we're not forking weston, what does it buy *anyone* for us to use libwayland?
-    00:22 <krh> you can call it anything you want, as long as client and server side agrees on the name
+00:22 <krh> you can call it anything you want, as long as client and server side agrees on the name
-    00:22 <Prf_Jakob> RAOF: all the toolkits see is EGL.
+00:22 <Prf_Jakob> RAOF: all the toolkits see is EGL.
-    00:23 <krh> RAOF: that's like saying, if we don't use EWMH is there any benefit to X?
+00:23 <krh> RAOF: that's like saying, if we don't use EWMH is there any benefit to X?
-    00:23 <RAOF> Prf_Jakob: No, they also have to see some shell interface.
+00:23 <RAOF> Prf_Jakob: No, they also have to see some shell interface.
-    00:23 <krh> if we standardize on on an EGL platform (eg what you create EGLDisplay and EGLSurface for) there's only one thing for gpu vendors to implement and support
+00:23 <krh> if we standardize on on an EGL platform (eg what you create EGLDisplay and EGLSurface for) there's only one thing for gpu vendors to implement and support
-    00:23 <Prf_Jakob> RAOF: its handled magically by the EGL driver loader (or DRI egl/wayland driver or in your case the ARM driver loader).
+00:23 <Prf_Jakob> RAOF: its handled magically by the EGL driver loader (or DRI egl/wayland driver or in your case the ARM driver loader).
-    00:23 -!- mgottschlag [~quassel@reactos/tester/phoenix64] has joined #wayland
+00:23 -!- mgottschlag [~quassel@reactos/tester/phoenix64] has joined #wayland
-    00:24 <krh> on top of that you can write your own shell and port toolkits
+00:24 <krh> on top of that you can write your own shell and port toolkits
-    00:24 <RAOF> Prf_Jakob: The toolkits will need to do *something* more than just draw to a buffer :)
+00:24 <RAOF> Prf_Jakob: The toolkits will need to do *something* more than just draw to a buffer :)
-    00:24 <Prf_Jakob> RAOF: the more in this case is calling EGL calls.
+00:24 <Prf_Jakob> RAOF: the more in this case is calling EGL calls.
-    00:24 <krh> RAOF: also, the shell-type integration points in something like qt or gtk+ are few and tiny
+00:24 <krh> RAOF: also, the shell-type integration points in something like qt or gtk+ are few and tiny
-    00:25 <RAOF> Prf_Jakob: They'll need to be able to do things like pop up a menu next to something. There's no EGL call for that, and EGL is entirely the wrong place to solve that.
+00:25 <RAOF> Prf_Jakob: They'll need to be able to do things like pop up a menu next to something. There's no EGL call for that, and EGL is entirely the wrong place to solve that.
-    00:25 <RAOF> Prf_Jakob: eg: eglCreateDialogWindow() doesn't really have a nice ring to it :)
+00:25 <RAOF> Prf_Jakob: eg: eglCreateDialogWindow() doesn't really have a nice ring to it :)
-    00:25 <Prf_Jakob> RAOF: sure right and thats all handled by Wayland proto.
+00:25 <Prf_Jakob> RAOF: sure right and thats all handled by Wayland proto.
-    00:26 <RAOF> Prf_Jakob: But not if we're throwing away the existing shell-y bits of the wayland protocol.
+00:26 <RAOF> Prf_Jakob: But not if we're throwing away the existing shell-y bits of the wayland protocol.
-    00:26 <Prf_Jakob> krh: correct me if I'm wrong, the shell-y bits of wayland proto never touches the DRM bits?
+00:26 <Prf_Jakob> krh: correct me if I'm wrong, the shell-y bits of wayland proto never touches the DRM bits?
-    00:27 <krh> Prf_Jakob: yes, it's completely separate
+00:27 <krh> Prf_Jakob: yes, it's completely separate
-    00:27 <Prf_Jakob> RAOF: ^
+00:27 <Prf_Jakob> RAOF: ^
-    00:27 <krh> Prf_Jakob: and we could just have one EGL platform
+00:27 <krh> Prf_Jakob: and we could just have one EGL platform
-    00:27 -!- Hwkiller [~Hwkiller@cpe-174-098-166-167.triad.res.rr.com] has quit [Quit: WeeChat 0.4.0]
+00:27 -!- Hwkiller [~Hwkiller@cpe-174-098-166-167.triad.res.rr.com] has quit [Quit: WeeChat 0.4.0]
-    00:27 <Prf_Jakob> yeah
+00:27 <Prf_Jakob> yeah
-    00:27 <RAOF> Prf_Jakob: They don't, right. But we *additionally* want to throw away the existing shell-y bits.
+00:27 <RAOF> Prf_Jakob: They don't, right. But we *additionally* want to throw away the existing shell-y bits.
-    00:27 <krh> RAOF: yes, but that's not a good reason to reinvent buffer allocation, sharing, frame sync, input model etc
+00:27 <krh> RAOF: yes, but that's not a good reason to reinvent buffer allocation, sharing, frame sync, input model etc
-    00:28 <soreau> I didn't notice any post on the mailing list to even ask about any of these concerns. It seems efforts would have been better spent raising questions that might help improve wayland rather than write a whole page about how 'your design' is going to be somehow better than wayland. What about the clients? Now clients have to support each and every display server protocol out there?
+00:28 <soreau> I didn't notice any post on the mailing list to even ask about any of these concerns. It seems efforts would have been better spent raising questions that might help improve wayland rather than write a whole page about how 'your design' is going to be somehow better than wayland. What about the clients? Now clients have to support each and every display server protocol out there?
-    00:28 <Prf_Jakob> RAOF: you only want to use server-allocation on drivers that really need it.
+00:28 <Prf_Jakob> RAOF: you only want to use server-allocation on drivers that really need it.
-    00:28 <krh> and definitely not a good reason to introduce a new window system that slightly different, but fundamentally the same as the wayland egl window system
+00:28 <krh> and definitely not a good reason to introduce a new window system that slightly different, but fundamentally the same as the wayland egl window system
-    00:28 <glisse> if you look at mir example it's scary
+00:28 <glisse> if you look at mir example it's scary
-    00:28 <RAOF> Prf_Jakob: We want to use it everywhere.
+00:28 <RAOF> Prf_Jakob: We want to use it everywhere.
-    00:28 <glisse> doesn't seems to have the notion of atomic commit
+00:28 <glisse> doesn't seems to have the notion of atomic commit
-    00:28 <krh> it's practically impossible to convince hw vendors to support new window systems
+00:28 <krh> it's practically impossible to convince hw vendors to support new window systems
-    00:29 <glisse> or frame synchronisation
+00:29 <glisse> or frame synchronisation
-    00:29 <krh> RAOF: you don't
+00:29 <krh> RAOF: you don't
-    00:29 <glisse> there is a bunch of usleep in them with bogus value to supposedly do 60fps
+00:29 <glisse> there is a bunch of usleep in them with bogus value to supposedly do 60fps
-    00:29 <Prf_Jakob> RAOF: why? I haven't we spent the last 10ish years trying to remove roundtrips to the server?
+00:29 <Prf_Jakob> RAOF: why? I haven't we spent the last 10ish years trying to remove roundtrips to the server?
-    00:29 -!- aavci [~aavci@78.165.21.35] has quit [Quit: Konversation terminated!]
+00:29 -!- aavci [~aavci@78.165.21.35] has quit [Quit: Konversation terminated!]
-    00:29 <RAOF> Now, this is the point where I complain that we don't have the rationale for server-allocated-buffers documented in a wiki page.
+00:29 <RAOF> Now, this is the point where I complain that we don't have the rationale for server-allocated-buffers documented in a wiki page.
-    00:30 <krh> RAOF: event X with DRI3 is removing server side allocated buffer where ever possible
+00:30 <krh> RAOF: event X with DRI3 is removing server side allocated buffer where ever possible
-    00:30 <RAOF> Yes, I know.
+00:30 <RAOF> Yes, I know.
-    00:31 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
+00:31 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
-    00:31 <RAOF> glisse: Frame synchronisation is implicit in the buffer submission - you won't get a new buffer back until there's one free. Which, since everything's double-buffered at the moment, means after the vsync'd compositor has used your last frame.
+00:31 <RAOF> glisse: Frame synchronisation is implicit in the buffer submission - you won't get a new buffer back until there's one free. Which, since everything's double-buffered at the moment, means after the vsync'd compositor has used your last frame.
-    00:31 <soreau> I don't understand why canonical doesn't assign devs to upstream FOSS projects like other companies do. Everyone else spends time making a community effort while canonical spends time trying to take credit for everyone else's work, after they put some glitter on it and installed a few bugs
+00:31 <soreau> I don't understand why canonical doesn't assign devs to upstream FOSS projects like other companies do. Everyone else spends time making a community effort while canonical spends time trying to take credit for everyone else's work, after they put some glitter on it and installed a few bugs
-    00:32 <dvdhrm> glisse, also a lot of roundtrips which really seem unnecessary like waiting until a buffer got released only to drop it.
+00:32 <dvdhrm> glisse, also a lot of roundtrips which really seem unnecessary like waiting until a buffer got released only to drop it.
-    00:33 <RAOF> I don't particularly like that API style, and a couple of us are in the process of getting a better one :)
+00:33 <RAOF> I don't particularly like that API style, and a couple of us are in the process of getting a better one :)
-    00:34  * RAOF wonders about that usleep in demo_client_accelerated.c; eglSwapBuffers *should* be blocking there
+00:34  * RAOF wonders about that usleep in demo_client_accelerated.c; eglSwapBuffers *should* be blocking there
-    00:35 <daniels> RAOF: fwiw, i've got a wayland backend for arm hardware which does server-side allocation right now.  didn't require one single change to any of the clients, or even compositors.  it's all internal to the egl stack.
+00:35 <daniels> RAOF: fwiw, i've got a wayland backend for arm hardware which does server-side allocation right now.  didn't require one single change to any of the clients, or even compositors.  it's all internal to the egl stack.
-    00:35 <soreau> lol
+00:35 <soreau> lol
-    00:35 <Darxus> RAOF: I really appreciate you coming in here and talking about this at all, I imagine it must be a tough position to be in.
+00:35 <Darxus> RAOF: I really appreciate you coming in here and talking about this at all, I imagine it must be a tough position to be in.
-    00:36 <RAOF> Darxus: It would have been nicer to show off a working prototype of a wayland compositor, yeah :)
+00:36 <RAOF> Darxus: It would have been nicer to show off a working prototype of a wayland compositor, yeah :)
-    00:36 -!- cpst1 [~Adium@d24-141-253-131.home.cgocable.net] has joined #wayland
+00:36 -!- cpst1 [~Adium@d24-141-253-131.home.cgocable.net] has joined #wayland
-    00:37 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
+00:37 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
-    00:37 <soreau> <RAOF> I don't particularly like that API style, and a couple of us are in the process of getting a better one :)
+00:37 <soreau> <RAOF> I don't particularly like that API style, and a couple of us are in the process of getting a better one :)
-    00:37 <Prf_Jakob> RAOF: it would be really nice if you could use daniels work so people don't have to add support for yet another windowing system.
+00:37 <Prf_Jakob> RAOF: it would be really nice if you could use daniels work so people don't have to add support for yet another windowing system.
-    00:38 <soreau> RAOF: To what comment does that refer?
+00:38 <soreau> RAOF: To what comment does that refer?
-    00:38 <RAOF> soreau: To the toolkit API, as evident in the examples/ folder.
+00:38 <RAOF> soreau: To the toolkit API, as evident in the examples/ folder.
-    00:38 <soreau> oh
+00:38 <soreau> oh
-    00:39 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
+00:39 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
-    00:40 <daniels> Prf_Jakob: if you're referring to the server-side buffers thing, it's not something i can make public.
+00:40 <daniels> Prf_Jakob: if you're referring to the server-side buffers thing, it's not something i can make public.
-    00:41 <Prf_Jakob> daniels: aww
+00:41 <Prf_Jakob> daniels: aww
-    00:41 <soreau> RAOF: So how are clients expected to work?
+00:41 <soreau> RAOF: So how are clients expected to work?
-    00:41 -!- vpovirk [~urk@75-146-153-89-minnesota.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
+00:41 -!- vpovirk [~urk@75-146-153-89-minnesota.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
-    00:41 <soreau> RAOF: Now any graphical linux client would have to support wayland in addition to this Mir platform?
+00:41 <soreau> RAOF: Now any graphical linux client would have to support wayland in addition to this Mir platform?
-    00:41 <daniels> Prf_Jakob: it's easy to describe tho: duplicate wl_drm's create_{planar_,}buffer request as request_buffer, then have a buffer_created event which passes back the wl_buffer and the gem name
+00:41 <daniels> Prf_Jakob: it's easy to describe tho: duplicate wl_drm's create_{planar_,}buffer request as request_buffer, then have a buffer_created event which passes back the wl_buffer and the gem name
-    00:41 <daniels> Prf_Jakob: job done.
+00:41 <daniels> Prf_Jakob: job done.
-    00:42 <Prf_Jakob> RAOF: Å
+00:42 <Prf_Jakob> RAOF: Å
-    00:42 <daniels> Prf_Jakob: if you want to get really fancy, add a new interface which sends a you_are_now_fullscreen_and_should_get_your_buffers_from_the_server event
+00:42 <daniels> Prf_Jakob: if you want to get really fancy, add a new interface which sends a you_are_now_fullscreen_and_should_get_your_buffers_from_the_server event
-    00:42 <Prf_Jakob> ^*
+00:42 <Prf_Jakob> ^*
-    00:42 <daniels> Prf_Jakob: so clients can do regular client-side allocation when possible, and server-side allocation when they need to to get buffers you can display directly
+00:42 <daniels> Prf_Jakob: so clients can do regular client-side allocation when possible, and server-side allocation when they need to to get buffers you can display directly
-    00:42 <daniels> that's it really
+00:42 <daniels> that's it really
-    00:42 <Prf_Jakob> that be nice
+00:42 <Prf_Jakob> that be nice
-    00:42 <krh> that's how it should work
+00:42 <krh> that's how it should work
-    00:43 <daniels> your compositor's going to need to be aware of the extra get_your_buffers_serverside_please interface so it can send the events, but they'll be handled inside your client egl still
+00:43 <daniels> your compositor's going to need to be aware of the extra get_your_buffers_serverside_please interface so it can send the events, but they'll be handled inside your client egl still
-    00:43 <krh> it's how it was designed
+00:43 <krh> it's how it was designed
-    00:43 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
+00:43 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
-    00:44 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
+00:44 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
-    00:45 <RAOF> soreau: Clients are expected to use toolkits, and (I'm pretty sure) we've committed to porting & maintaining GTK and Qt.
+00:45 <RAOF> soreau: Clients are expected to use toolkits, and (I'm pretty sure) we've committed to porting & maintaining GTK and Qt.
-    00:45 <wm4> so what does that mean, assuming neither Mir nor Wayland dies, will drivers have to support both?
+00:45 <wm4> so what does that mean, assuming neither Mir nor Wayland dies, will drivers have to support both?
-    00:45 <soreau> RAOF: So you will have gtk and qt repos that are not master but housed in launchpad/bzr?
+00:45 <soreau> RAOF: So you will have gtk and qt repos that are not master but housed in launchpad/bzr?
-    00:46 -!- cdidd [~cdidd@128-72-120-234.broadband.corbina.ru] has quit [Remote host closed the connection]
+00:46 -!- cdidd [~cdidd@128-72-120-234.broadband.corbina.ru] has quit [Remote host closed the connection]
-    00:46 <RAOF> Prf_Jakob: Yes, it would be nice; at least we're going to be porting the toolkits.
+00:46 <RAOF> Prf_Jakob: Yes, it would be nice; at least we're going to be porting the toolkits.
-    00:46 <msclrhd> Gtk 2, 3 or both?
+00:46 <msclrhd> Gtk 2, 3 or both?
-    00:46 <RAOF> soreau: No. We expect to be able to provite Mir support in gtk and Qt master.
+00:46 <RAOF> soreau: No. We expect to be able to provite Mir support in gtk and Qt master.
-    00:46 <daniels> wm4: yeah, it'll be great.
+00:46 <daniels> wm4: yeah, it'll be great.
-    00:46 <Prf_Jakob> RAOF: any clients like games that talk directly to the platform?
+00:46 <Prf_Jakob> RAOF: any clients like games that talk directly to the platform?
-    00:46 <Prf_Jakob> and*
+00:46 <Prf_Jakob> and*
-    00:47 <RAOF> I *think* we might be porting SDL?
+00:47 <RAOF> I *think* we might be porting SDL?
-    00:47 -!- mgottschlag [~quassel@reactos/tester/phoenix64] has quit [Ping timeout: 255 seconds]
+00:47 -!- mgottschlag [~quassel@reactos/tester/phoenix64] has quit [Ping timeout: 255 seconds]
-    00:47 <Prf_Jakob> I said directly :-/
+00:47 <Prf_Jakob> I said directly :-/
-    00:47 <soreau> RAOF: That sounds pretty horrible
+00:47 <soreau> RAOF: That sounds pretty horrible
-    00:48 <RAOF> But, yeah. In an ideal world there wouldn't be extra Mir & Wayland backends required.
+00:48 <RAOF> But, yeah. In an ideal world there wouldn't be extra Mir & Wayland backends required.
-    00:48 <RAOF> soreau: Horrible in what way?
+00:48 <RAOF> soreau: Horrible in what way?
-    00:48 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
+00:48 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
-    00:48 <Prf_Jakob> so just use EGL and wayland, the shell-y bits wont be in the toolkits anyways.
+00:48 <Prf_Jakob> so just use EGL and wayland, the shell-y bits wont be in the toolkits anyways.
-    00:49 <soreau> RAOF: Because now I want to make my own wayland. Now I add all support in the clients. Rinse and repeat 100 times and now your clients are bloated and a complete mess, a nightmare
+00:49 <soreau> RAOF: Because now I want to make my own wayland. Now I add all support in the clients. Rinse and repeat 100 times and now your clients are bloated and a complete mess, a nightmare
-    00:49 -!- cdidd [~cdidd@95-27-225-136.broadband.corbina.ru] has joined #wayland
+00:49 -!- cdidd [~cdidd@95-27-225-136.broadband.corbina.ru] has joined #wayland
-    00:49 <soreau> RAOF: It's hard enough to try and deal with X and wayland support simultaneously much less start setting bad examples like this for others
+00:49 <soreau> RAOF: It's hard enough to try and deal with X and wayland support simultaneously much less start setting bad examples like this for others
-    00:49 <soreau> RAOF: That's why it's horrible.
+00:49 <soreau> RAOF: That's why it's horrible.
-    00:50 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
+00:50 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
-    00:50 <RAOF> soreau: Um, that's how wayland is *supposed* to work? You're *supposed* to be able to throw away the wl_shell and wl_shell_surface, and doing that will require toolkit changes.\
+00:50 <RAOF> soreau: Um, that's how wayland is *supposed* to work? You're *supposed* to be able to throw away the wl_shell and wl_shell_surface, and doing that will require toolkit changes.\
-    00:50 -!- bluetech_ [~bluetech@109.64.29.128] has quit [Ping timeout: 255 seconds]
+00:50 -!- bluetech_ [~bluetech@109.64.29.128] has quit [Ping timeout: 255 seconds]
-    00:50 <RAOF> Although fewer toolkit changes than if you were, say, also changing out the input stack ☺
+00:50 <RAOF> Although fewer toolkit changes than if you were, say, also changing out the input stack ☺
-    00:51 <soreau> RAOF: So now each client might support this or that compositor and there's no standardized anything?
+00:51 <soreau> RAOF: So now each client might support this or that compositor and there's no standardized anything?
-    00:51 <RAOF> soreau: Welcome!
+00:51 <RAOF> soreau: Welcome!
-    00:52 <RAOF> soreau: Yes; but that's my understanding of where wayland was going to end up anyway. Each of the shells (GNOME Shell, KDE, etc) were likely to have their custom extensions, and apps wouldn't work (completely) on the other one.
+00:52 <RAOF> soreau: Yes; but that's my understanding of where wayland was going to end up anyway. Each of the shells (GNOME Shell, KDE, etc) were likely to have their custom extensions, and apps wouldn't work (completely) on the other one.
-    00:52 <soreau> RAOF: So I'm steam and I want to port my client to wayland. '.. or was it Mir.. or was it, wait lemme check phoronix..'. Now what API do I choose for the official proprietary steam client that doesn't use X?
+00:52 <soreau> RAOF: So I'm steam and I want to port my client to wayland. '.. or was it Mir.. or was it, wait lemme check phoronix..'. Now what API do I choose for the official proprietary steam client that doesn't use X?
-    00:53 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has joined #wayland
+00:53 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has joined #wayland
-    00:53 <RAOF> Well, if you're Valve, you probably use X for another couple of years.
+00:53 <RAOF> Well, if you're Valve, you probably use X for another couple of years.
-    00:53 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Client Quit]
+00:53 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Client Quit]
-    00:53 <RAOF> Then you see what's out there.
+00:53 <RAOF> Then you see what's out there.
-    00:53 <Prf_Jakob> RAOF: fair enough, but adding a completely new windowing system isn't going to help, talking to the Wayland developers and changing that would be.
+00:53 <Prf_Jakob> RAOF: fair enough, but adding a completely new windowing system isn't going to help, talking to the Wayland developers and changing that would be.
-    00:53 <soreau> RAOF: So may the best man win
+00:53 <soreau> RAOF: So may the best man win
-    00:54 <MeanEYE> Different for the sake of being different. Sounds like the same story it was with Upstart.
+00:54 <MeanEYE> Different for the sake of being different. Sounds like the same story it was with Upstart.
-    00:54 <RAOF> MeanEYE: Except, of course, for the fact that upstart predated systemd by many years.
+00:54 <RAOF> MeanEYE: Except, of course, for the fact that upstart predated systemd by many years.
-    00:54 <MeanEYE> Except that.
+00:54 <MeanEYE> Except that.
-    00:55 <RAOF> Prf_Jakob: Yeah, in an ideal world…
+00:55 <RAOF> Prf_Jakob: Yeah, in an ideal world…
-    00:55 <soreau> RAOF: Doesn't make any sense. We have to build an attractive stable platform, not start pushing more technicalities into an already saturated, complicated medley of client code. This will cause more confusion and deter proprietary interests from linux altogether
+00:55 <soreau> RAOF: Doesn't make any sense. We have to build an attractive stable platform, not start pushing more technicalities into an already saturated, complicated medley of client code. This will cause more confusion and deter proprietary interests from linux altogether
-    00:56 <soreau> Maybe Canonical is just a division of Microsoft hired to try and take down Linux
+00:56 <soreau> Maybe Canonical is just a division of Microsoft hired to try and take down Linux
-    00:56 <RAOF> Our secret is out!!!!!111111
+00:56 <RAOF> Our secret is out!!!!!111111
-    00:56 -!- jbkonno [jbkonno@nat/intel/x-ltgtsvgtesvtqrou] has quit [Quit: Lost terminal]
+00:56 -!- jbkonno [jbkonno@nat/intel/x-ltgtsvgtesvtqrou] has quit [Quit: Lost terminal]
-    00:56 <RAOF> That said, I've grown less convinced over time doing a wayland-based Unity compositor would have helped us or wayland significantly.
+00:56 <RAOF> That said, I've grown less convinced over time doing a wayland-based Unity compositor would have helped us or wayland significantly.
-    00:57 <Prf_Jakob> RAOF: would it even be possible to try and have a meeting between the developers to try and work things out?
+00:57 <Prf_Jakob> RAOF: would it even be possible to try and have a meeting between the developers to try and work things out?
-    00:57 <soreau> Unity is not helping *anyone*
+00:57 <soreau> Unity is not helping *anyone*
-    00:57 <soreau> so that point is moot
+00:57 <soreau> so that point is moot
-    00:58 <RAOF> Prf_Jakob: I understand that someone - possibly Thomas Voß? - is organising such a meeting.
+00:58 <RAOF> Prf_Jakob: I understand that someone - possibly Thomas Voß? - is organising such a meeting.
-    00:58 <Prf_Jakob> RAOF: that would be awesome, because not having YAWS would be awesome.
+00:58 <Prf_Jakob> RAOF: that would be awesome, because not having YAWS would be awesome.
-    00:59 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has quit [Remote host closed the connection]
+00:59 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has quit [Remote host closed the connection]
-    00:59 <MeanEYE> RAOF: So if you are doing your own thing. What about applications that still require X?
+00:59 <MeanEYE> RAOF: So if you are doing your own thing. What about applications that still require X?
-    00:59 <RAOF> Prf_Jakob: I wouldn't expect such a meeting to change our course, though, so don't get your hopes up :/
+00:59 <RAOF> Prf_Jakob: I wouldn't expect such a meeting to change our course, though, so don't get your hopes up :/
-    00:59 <RAOF> MeanEYE: They get X. Why wouldn't they?
+00:59 <RAOF> MeanEYE: They get X. Why wouldn't they?
-    01:00 <MeanEYE> RAOF: I meant if Ubuntu implements Mir... how would you start something that requires X?
+01:00 <MeanEYE> RAOF: I meant if Ubuntu implements Mir... how would you start something that requires X?
-    01:00 <Prf_Jakob> RAOF: also a wikipage describing your reasons for server-side-allocation, and not the Mir page with miss-understandings about Wayland.
+01:00 <Prf_Jakob> RAOF: also a wikipage describing your reasons for server-side-allocation, and not the Mir page with miss-understandings about Wayland.
-    01:00 <RAOF> MeanEYE: Exactly the same way as you do now - you start it. This is in no way different to how it'd work under wayland.
+01:00 <RAOF> MeanEYE: Exactly the same way as you do now - you start it. This is in no way different to how it'd work under wayland.
-    01:00 <soreau> MeanEYE:  <krh> classy <krh> they even renamed xwayland to xmir
+01:00 <soreau> MeanEYE:  <krh> classy <krh> they even renamed xwayland to xmir
-    01:01 -!- lasers [~lasers@unaffiliated/lasers] has joined #wayland
+01:01 -!- lasers [~lasers@unaffiliated/lasers] has joined #wayland
-    01:01 <RAOF> I'm not sure what *else* I would have called it!
+01:01 <RAOF> I'm not sure what *else* I would have called it!
-    01:01 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has joined #wayland
+01:01 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has joined #wayland
-    01:01 <RAOF> It's the standard nomenclature as far as I can tell - xquartz, xwayland, xmir
+01:01 <RAOF> It's the standard nomenclature as far as I can tell - xquartz, xwayland, xmir
-    01:01 <MeanEYE> o_0
+01:01 <MeanEYE> o_0
-    01:01 <soreau> how about NOT renaming it in the first place?
+01:01 <soreau> how about NOT renaming it in the first place?
-    01:01 <soreau> and NOT forking the whole project?
+01:01 <soreau> and NOT forking the whole project?
-    01:01 <RAOF> It's not a rename of xwayland?
+01:01 <RAOF> It's not a rename of xwayland?
-    01:01 <MeanEYE> So you are doing the same thign Wayland is doing, but you want one thing change, you could have otherwised changed or at least talked to developers here.
+01:01 <MeanEYE> So you are doing the same thign Wayland is doing, but you want one thing change, you could have otherwised changed or at least talked to developers here.
-    01:02 <RAOF> Because - and I know this may shock you - it talks to a Mir server rather than a wayland server?
+01:02 <RAOF> Because - and I know this may shock you - it talks to a Mir server rather than a wayland server?
-    01:02 <MeanEYE> o_0
+01:02 <MeanEYE> o_0
-    01:02 <soreau> MeanEYE: Right, they didn't mention any of these concerns until after announcing this
+01:02 <soreau> MeanEYE: Right, they didn't mention any of these concerns until after announcing this
-    01:02 <RAOF> (It also has a crazy thread-to-eventloop proxy, because of threading)
+01:02 <RAOF> (It also has a crazy thread-to-eventloop proxy, because of threading)
-    01:02 <MeanEYE> o_0
+01:02 <MeanEYE> o_0
-    01:03 <daniels> RAOF: even if you bin the shell interfaces, you still at least share core surface management, input, etc
+01:03 <daniels> RAOF: even if you bin the shell interfaces, you still at least share core surface management, input, etc
-    01:03 <soreau> RAOF: I'm not shocked, I'm appalled
+01:03 <soreau> RAOF: I'm not shocked, I'm appalled
-    01:03 <soreau> I'm offended
+01:03 <soreau> I'm offended
-    01:03 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has quit [Quit: Konversation terminated!]
+01:03 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has quit [Quit: Konversation terminated!]
-    01:03 -!- JesseBarker [~jesse@linaro/JesseBarker] has quit [Quit: Ex-Chat]
+01:03 -!- JesseBarker [~jesse@linaro/JesseBarker] has quit [Quit: Ex-Chat]
-    01:04 <RAOF> soreau: I'm sorry that you're offended.
+01:04 <RAOF> soreau: I'm sorry that you're offended.
-    01:05 <RAOF> daniels: Yeah; we seem to like the android input stack. This is something that I'm not totally familiar with.
+01:05 <RAOF> daniels: Yeah; we seem to like the android input stack. This is something that I'm not totally familiar with.
-    01:05  * RAOF wishes we still had Chase
+01:05  * RAOF wishes we still had Chase
-    01:06 <daniels> RAOF: curious - you mean core input (key/pointer/touch), or input methods?
+01:06 <daniels> RAOF: curious - you mean core input (key/pointer/touch), or input methods?
-    01:07 <RAOF> Core input, and possibly input methods - I'm unsure about the latter.
+01:07 <RAOF> Core input, and possibly input methods - I'm unsure about the latter.
-    01:08 -!- gmaxwell [~greg@wikimedia/KatWalsh/x-0001] has joined #wayland
+01:08 -!- gmaxwell [~greg@wikimedia/KatWalsh/x-0001] has joined #wayland
-    01:08 -!- metajack [~Adium@c-68-35-124-4.hsd1.nm.comcast.net] has joined #wayland
+01:08 -!- metajack [~Adium@c-68-35-124-4.hsd1.nm.comcast.net] has joined #wayland
-    01:09 <daniels> interesting
+01:09 <daniels> interesting
 01:10 <soreau> RAOF: I'm not saying it's your fault or your decision (at least I hope). I'm just frustrated with canonical's constant antics causing ruckus in the linux community
 01:10 <oneman> so say we all
 01:10 <daniels> RAOF: IT'S LITERALLY YOUR FAULT YOU ARE SUCH A DICK.
 01:10 <oneman> ;)
 01:11  * RAOF dies
 01:11 <daniels> RAOF: soz
 01:11 <RAOF> :)
 01:11 <soreau> The problem is that they don't know what they want. What they want is the same thing as everyone else - a fluent and fast user interface that justworks. They want to idealize with unity but that is just an idea with a crappy proof-of-concept
 01:11 <Zoxc> So wayland vs. Mir will be the new flamewar?
 01:11 <RAOF> Incidentally, working on private stuff sucks.
 01:12 <MeanEYE> Nope.
 01:12 <RAOF> Zoxc: Yeah. upstart-vs-systemd has died down too much. We need something new and fresh!
 01:12 <MeanEYE> According to Aaron Seigo, KDE developer, they won't accept it.
 01:12 <RAOF> They're welcome to use X.
 01:13 -!- rillian [~giles@mf4-xiph.osuosl.org] has joined #wayland
 01:13 <MeanEYE> Yup. Alienating all of the Linux community will do good for Ubuntu.
 01:13 <RAOF> MeanEYE: It's actually worked pretty well so far :)
 01:13 <MeanEYE> It's like dealing with the whole fiasco MS created with IE in the early days.
 01:13 <MeanEYE> Time will tell.
 01:14 <min2> -
 01:14 <soreau> I don't understand why they still open source their code. Canonical is feeling more and more like nvidia to the FOSS community
 01:14 <MeanEYE> Jugling between TV, mobile, desktop, tablet... and now this.
 01:14 -!- alexfpms [~Alex@unaffiliated/alexfpms] has quit [Ping timeout: 248 seconds]
 01:15 <Prf_Jakob> soreau: now that isn't helping at all
 01:15 <RAOF> soreau: Because we (still) believe open source is empowering and fundamentally the most efficient development method?
 01:16 <soreau> Prf_Jakob: And forking wayland is?
 01:16 <Prf_Jakob> soreau: two wrongs doesn't make a right.
 01:16 <RAOF> We're not forking wayland; that's part of what krh is annoyed with?
 01:17 <Prf_Jakob> RAOF: he said he was annoyed with you having a wiki page full of missunderstandings of how wayland work.
 01:17 <RAOF> That too.
 01:18 <Prf_Jakob> RAOF: and I would guess that you are doing pretty much exactly what wayland does but a tiny bit differently.
 01:18 <soreau> It is
 01:18 <Siekacz> Little things that matter
 01:18 <soreau> It stands on the groundwork that was laid over several years for wayland
 01:18 <Prf_Jakob> RAOF: and that you guys gave ZERO feedback on Wayland.
 01:18 <MeanEYE> Am not worried. If Mir is optimized as good as Unity is. :) It'
 01:18 <MeanEYE> It's an easy choice for me.
 01:19 <Prf_Jakob> RAOF: Which could have avoided this whole mess to begin with.
 01:19 -!- hardening [~hardening@2001:5c0:1502:900:5873:a175:9b40:c975] has quit [Quit: Quitte]
 01:19 <soreau> MeanEYE: I think they optimized it to fail-fast
 01:19 <soreau> crashes pretty quick
 01:19 <MeanEYE> Don't know. Don't use it. I don't think window manager should eat 100+ MB of RAM.
 01:20 <soreau> MeanEYE: I switched to xubuntu the year they released it, never looked back
 01:20 <Prf_Jakob> soreau: if you actually want them to use your project I would recommend not insulting them.
 01:20 <MeanEYE> Am on i3wm. Quite a breeze. 6MB of RAM usage. :)
 01:21 <RAOF> Time will, indeed, tell. The plan is to make Mir the most awesome display server platform to develop Unity in. If this happens to produce a display server that others find makes an awesome platform to develop GNOME shell, or KDE, or whatever, then that's an added bonus.
 01:21 <soreau> ubuntu has debian at it's core and that is a solid system. The user interface used to be solid too until the desktop environment revolution
 01:21 <Siekacz> soreau: and quite unusable for non-geek stuff
 01:22 <MeanEYE> Am not insulting, am merely stating my observation.
 01:22 <Prf_Jakob> soreau: I find unity perfectly capable for my usecases btw.
 01:22 <soreau> Prf_Jakob: I couldn't care less what project they use, just don't start a page, describing the problems with wayland when it's still in its infancy
 01:22 <RAOF> Prf_Jakob: I won't dispute the lack of communication with the wayland guys. I think we're going to end up doing stuff quite differently to wayland, though - at least as far as input.
 01:22 <RAOF> soreau: Infancy? It's been around, what, 5 years?
 01:23 <runeks> But Mir *could* become compatible with Wayland, as far as I understand, right?
 01:23 <soreau> RAOF: ok, a child can only be considered an infant for what, 9 months?
 01:23 <soreau> You get my point.
 01:23 <runeks> "However, Wayland support could be added either by providing a Wayland-specific frontend implementation for our display server or by providing a client-side implementation of libwayland that ultimately talks to Mir."
 01:24 <RAOF> runeks: Yes; I'm not sure if we'll do that work, and it doesn't help the driver situation.
 01:24 <RAOF> I hope we can do something for the driver situation, frankly.
 01:24 <runeks> RAOF: What is the driver situation, exactly?
 01:24 <MeanEYE> Wow, what a counterproductive action.
 01:25 <MeanEYE> Want to help with driver situation, makes it more complicated for companies writing drivers.
 01:25 <KiBi> They just have to publish open source drivers. Easy.
 01:25 <Prf_Jakob> RAOF: Again the input cituation could have been improved if you guys actually talked to the Wayland developers.
 01:26 <soreau> MeanEYE: They're saving all rational logical decisions to be made in their original display server code
 01:26 <soreau> KiBi: heh
 01:26 <RAOF> KiBi: That does neatly solve the situation :)
 01:26 <MeanEYE> Am gonna go watch something. This conversation makes my brain hurt. Too few logical decisions for my liking. ^^
 01:26 <soreau> RAOF: How many people are supposed to be working on this code?
 01:27 <wm4> didn't the Mir wiki page say they've been in "contact" with vendors of closed source drivers
 01:27 <RAOF> It does indeed.
 01:27 <wm4> "However, we are in contact with GPU vendors and are working closely together with them to support Mir and to distill a reusable and unified EGL-centric driver model that further eases display server development in general and keeps cross-platform use-cases in mind."
 01:27 <RAOF> soreau: Some
 01:27 <wm4> so what does that mean
 01:28 -!- sirdancealo2 [~sirdancea@98.82.broadband5.iol.cz] has quit [Ping timeout: 252 seconds]
 01:28 <soreau> RAOF: That sounds like maybe a few+
 01:28 <wm4> and that paragraph is clearly talking about desktop hardware: "Right now, Mir does not run on desktop hardware that requires closed source drivers. ..."
 01:28  * RAOF has no idea if # of developers in company-confidential, and doesn't know off the top of his head.
 01:29 <RAOF> wm4: I'm not sure what's unclear about that? We're talking with GPU vendors to try and get a driver model that can be used generally - that would presumably include wayland implementations.
 01:30 <min2> Hello I've just finished reading it... woah
 01:30 <soreau> This decision is worse than Bush's decision to double the .us national debt
 01:30 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has joined #wayland
 01:32 <Siekacz> RAOF: weren't you fed up with waiting on waiting for wayland to get mature?
 01:32 <min2> so what, wrote bullshit about wayland (again). sigh. not that anyone reads it except the peanut gallery
 01:33 <RAOF> Siekacz: It's not going to get mature without someone using it in anger. We *could* have been that someone.
 01:33 <RAOF> Indeed, were starting to become that someone.
 01:33 <Jasper> This is fun.
 01:33 <soreau> This is the only good thing that can come of this
 01:34 <min2> hell, and mir sounds like a cool marketing project i might as well contribute a few patches
 01:34 <soreau> min2: patches not welcome
 01:34 <gallo> Mir might be the very ingredience to make it "mature". After all, competition is healthy.
 01:34 <Siekacz> RAOF: as far as I remeber there was an attempt to use wayland as system compositor, why did it fail?
 01:34 <RAOF> soreau: That's unfair
 01:35 <Jasper> RAOF, I have one technical question: how are you going to implement input methods?
 01:35 <Jasper> Is it going to be like XKB where you have input methods directly in the path of the input stack?
 01:35 <RAOF> Siekacz: Yeah; I started doing the work to make the system compositor. It failed - or, rather, didn't get finished - because I got pulled off to work on Mir.
 01:35 <Zoxc> RAOF: So you need vendors with an open source EGL shim or a new lower level interface which is used to implement EGL?
 01:36 <Jasper> RAOF, I don't see anything in the page about this, and it's been an open problem in Wayland for a little bit. I don't know the current status of IM support in Wayland.
 01:36 <min2> but yes this patch is fun finally something happens after an year
 01:36 -!- sylware [~sylware@88.188.175.165] has quit [Remote host closed the connection]
 01:36 <min2> this chat
 01:36 <Prf_Jakob> Zoxc: I would assume they would do a layered EGL implementation, what android does, and then do all the sharing via dma_buf.
 01:37 <RAOF> Jasper: I'm not sure we've hammered out our input method story - I think it's actually up to the shell to decide how to do that. But from discussion the idea is to expose the full event stream to an input method and have it do whatever it needs.
 01:37 <Jasper> RAOF, well, that becomes complicated when you want the IM to use a toolkit.
 01:38 <Jasper> RAOF, then, in order to prevent re-entrancy, the pragmatic solution is that the IM is a separate process, and now you have to have an IPC mechanism.
 01:38 -!- otaylor [~otaylor@c-76-127-164-212.hsd1.ct.comcast.net] has joined #wayland
 01:39 <Jasper> But you still have the goal that two same-privilege processes can send each other fake events
 01:39 -!- dog [~quassel@134.134.137.71] has joined #wayland
 01:39 <RAOF> Jasper: Oh, certainly. I expect that input methods are going to need to be out of process, so will need an IPC mechanism.
 01:39 <soreau> heh, #mir is Musical Information Retrieval
 01:39 <Jasper> RAOF, OK, so now you have an external process that can send any other client keyboard events.
 01:40 -!- jmsaunde [~jmsaunde@staples.cmclub.uwaterloo.ca] has joined #wayland
 01:40 -!- ssalbiz [~ssalbiz@artificial-flavours.csclub.uwaterloo.ca] has joined #wayland
 01:40 <magn3ts> Will Mir require toolkits to build in support for it or will it be compatible with Wayland?
 01:40 <RAOF> Jasper: Not necessarily - you can require the IM to register itself as an IM and get privileged access.
 01:40 <Jasper> And what prevents some application from doing that?
 01:40 <min2> soreau: mir is many things, a russian space shuttle and peace in russian
 01:41 <RAOF> Jasper: Because its manifest doesn't have the requisite permission request?
 01:41 <Jasper> RAOF, do you have application sandboxing?
 01:41 <soreau> min2: great too, that mir is completely unique and easily searchable
 01:41 <RAOF> Jasper: I presume we'll end up with something like android - you can install keyboards, and you get a big ‘this thing can snoop on everything’ warning.
 01:41 <min2> soreau: ok. please will you test my focusstealing patch ??? please
 01:41 <Jasper> RAOF, OK.
 01:42 <min2> soreau: it applies i promise
 01:42 <Jasper> RAOF, that means that Mir has some permission model greater than Wayland.
 01:42 <soreau> min2: I told you, I don't know how focus stealing works since I don't use it. Thus I wouldn't know what to do with it
 01:42 <Jasper> And it assumes something about manifests and so on.
 01:42 <soreau> min2: I wouldn't be able to give any suggestion
 01:42 <soreau> or opinion
 01:42 <RAOF> Jasper: I think it'll end up that *Unity* has some permission model greater than Wayland. I don't think we, in the Mir project, are going to get into that.
 01:42 <Siekacz> мир also means "the world"
 01:43 <Jasper> RAOF, OK.
 01:43 <RAOF> Jasper: The Unity shell definitely gets access to the raw input stream, and I think that's the level that we're going to be doing IMs at.
 01:43 <Jasper> RAOF, so input methods are not Mir's problem, they're Unity's problem.
 01:43 <Jasper> RAOF, oh, you're not going to implement the "system compositor" idea?
 01:43 <min2> soreau: but you simply just type in editor, simply just run ./clients/focusstealer
 01:43 <Jasper> Where you have some system compositor that reads from evdev and punts it to the current session, which is convenient for fast user switching, etc.
 01:44 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #wayland
 01:44 <RAOF> Jasper: Oh, yes. We will have a system compositor. But the system compositor (roughly) doesn't need to do anything but punt evdev down to the session.
 01:44 <Jasper> Right.
 01:44 <min2> soreau: maybe read this http://www.chaosreigns.com/wiki/Wayland_genericpage5#.5Bshell.5D_focus_stealing
 01:44 <Jasper> RAOF, anyway, just want to let you know I'm disappointed in the decision, but I wish you the best of luck going forward, and hope we can share ideas and strategies, and luckily, code.
 01:45 <soreau> min2: Sorry, I don't have time right now. I have to go soon too
 01:45 <min2> soreau: ok never mind
 01:45 <RAOF> Jasper: So I don't think that the system compositor needs to care about IMs at all. You've obviously thought about it more than me, though ☺
 01:45 <Jasper> RAOF, yeah, landing IM support was a big thing for GNOME 3.6 and GNOME 3.8.
 01:46 <soreau> min2: maybe a little later
 01:46 <RAOF> Jasper: Whatever happened to the branch of gnome-shell using wayland?
 01:46 -!- polysix [~hoax@mew.chickenkiller.com] has quit [Ping timeout: 252 seconds]
 01:46 <Jasper> RAOF, it's always been an Intel thing
 01:46 -!- sirdancealot [~sirdancea@98.82.broadband5.iol.cz] has joined #wayland
 01:46 <Jasper> RAOF, it's something we want to do but don't really have the time.
 01:47 -!- iksaif_ [~iksaif@iksaif.net] has quit [Ping timeout: 252 seconds]
 01:48 <Jasper> RAOF, I think halfline might have been working on a Wayland backend for plymouth, too.
 01:49 <Jasper> RAOF, by the way, do you have a link to your Wayland system compositor?
 01:49 <RAOF> I think we might have a Mir backend for plymouth lying around somewhere, but I've never seen it.
 01:50 <RAOF> Jasper: https://github.com/RAOF/weston/tree/system-compositor + xserver + xf86-video-ati + xf86-video-nouveau (I think)
 01:50 <Jasper> RAOF, thanks!
 01:50 <Jasper> RAOF, if we can pick that up for some Fedora release in the future and run X under it, that would be really neat.
 01:51 <RAOF> Check out clients/simple-display-manager.c for that; there's also a lightdm branch somewhere that worked.
 01:52 <soreau> RAOF: infancy in terms of a usable desktop. All the ground work (protocol, driver implementation) was laid over the past 5 years but it's just now getting to a point where it's semi-usable
 01:52 -!- klusark [~klusark@S0106d4ca6d3286ef.vc.shawcable.net] has joined #wayland
 01:52 -!- mayhew [~justin@hlfxns0163w-047054165110.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Quit: leaving]
 01:52 -!- chatsiri_ [~chatsiri_@node-4ch.pool-118-173.dynamic.totbb.net] has joined #wayland
 01:53 <Jasper> soreau, can we try and keep the discussion technical?
 01:53 <soreau> Jasper: If that's the case, can we keep it wayland-only?
 01:53 <Jasper> soreau, sure; that's what I've been trying to do.
 01:53 <soreau> I could have called OT a long time ago
 01:54 <soreau> but considering the circumstances..
 01:54 -!- polysix [hoax@mew.chickenkiller.com] has joined #wayland
 01:55 <daniels> Jasper, RAOF: aiui the mutter wayland port is being revived