23:50 <RAOF> Heh. It's our turn to pull a systemd!
    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: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 <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: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 <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/
    -!- Day changed to Tuesday, March 05, 2013
    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: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 <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 <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 <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> but don't piss on wayland in the process
    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 <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: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 <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> if you don't know what it is
    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 <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: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 <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 <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 -!- uartie [uartie@nat/intel/x-bcdajueitxzaktln] has joined #wayland
    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 <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 -!- 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: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 <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: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 <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: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 <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> or even a weston thing
    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 <Prf_Jakob> RAOF: why do you guys want server-allocated buffers?
    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: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 <krh> but that's not something wayland can't support
    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 <krh> we have those GPUs at intel too
    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 -!- 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 <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 <Darxus> It seems weird that this conversation didn't happen before the mir announcement / decision.
    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 <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 <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 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 <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 <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 <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: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 <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 -!- 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 <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 <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: 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: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:27 <krh> Prf_Jakob: yes, it's completely separate
    00:27 <Prf_Jakob> RAOF: ^
    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 <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 <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 <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 <glisse> if you look at mir example it's scary
    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 <krh> it's practically impossible to convince hw vendors to support new window systems
    00:29 <glisse> or frame synchronisation
    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 <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 <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 <RAOF> Yes, I know.
    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 <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: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: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 <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 -!- 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 <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: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 <soreau> oh
    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:41 <Prf_Jakob> daniels: aww
    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 <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: job done.
    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 <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> that's it really
    00:42 <Prf_Jakob> that be nice
    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 <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: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 <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: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 <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 <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> and*
    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 <Prf_Jakob> I said directly :-/
    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> 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 <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 -!- 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: That's why it's horrible.
    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 -!- 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: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: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: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 -!- 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 <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: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 <MeanEYE> Except that.
    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: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 -!- 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: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> so that point is moot
    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: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 <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?
    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 <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:01 -!- lasers [~lasers@unaffiliated/lasers] has joined #wayland
    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 <RAOF> It's the standard nomenclature as far as I can tell - xquartz, xwayland, xmir
    01:01 <MeanEYE> o_0
    01:01 <soreau> how about NOT renaming it in the first place?
    01:01 <soreau> and NOT forking the whole project?
    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: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 <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 <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 <soreau> RAOF: I'm not shocked, I'm appalled
    01:03 <soreau> I'm offended
    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: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 wishes we still had Chase
    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: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:09 <daniels> interesting