23:50 Heh. It's our turn to pull a systemd! 23:50 RAOF: did you know about this? 23:50 Yes; hence my lack of work on the wayland system compositor branches. 23:53 RAOF: I kind of wondered if that was the case. 23:55 RAOF: the technical reasons on the mir page just don't add up 23:55 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 krh: What about this, does it have merit? 23:58 "[...] 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: everything about input 23:59 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 there's nothing priviledge about wl_shell 00:00 I think the author mistakes it for the interface required to implement a shell 00:01 that interface is desktop_shell and is only available to the desktop-shell.c client that the compositor forks 00:01 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: if you do it upstream, yes 00:02 I think the most compelling argument is argument-from-control-of-project 00:02 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 airlied: I think that people in charge are uncertain that it would be accepted upstream. 00:02 that's what pisses me off 00:02 you can do whatever you want and you don't need my permission 00:02 but don't piss on wayland in the process 00:02 RAOF: you work upstream, you don't have to be accepted 00:03 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: You always have to be accepted, unless you want to fork? 00:03 ugh, this is so annoying. "We don't understand wayland, so we need to create our own system from scratch" 00:04 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 RAOF: fail, you assign devs to work on the upstream project, to enact your design 00:05 krh: I don't think we *meant* to piss all over wayland. 00:05 RAOF: yes, so don't go and tell the world it's broken 00:05 if you don't know what it is 00:05 they become part of the upstream project, and are no different 00:06 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: I don't think we *did* say that? It's a mistake if so - wayland certainly doesn't. 00:06 I'll have fun explaining how that's not the case to everybody for the next few months 00:07 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 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 RAOF: but I know Iit has to be under C control and be GPL CLA so that fine 00:08 krh: Likewise; but is that actually *useful* if we replace all the interfaces? 00:08 but those reasons look bad on the web page, I know 00:08 -!- uartie [uartie@nat/intel/x-bcdajueitxzaktln] has joined #wayland 00:08 airlied: That assumes everyone upstream shares the same goals? 00:08 RAOF: I don't think you need to replace them 00:08 RAOF: okay if your goals are GPL and company controlled, then probably not 00:09 none of the reasons listed on the page are valid 00:09 -!- msclrhd [~msclrhd@85.211.124.135] has joined #wayland 00:09 none of them calls for a change in any of the core interfaces 00:11 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 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 it's like throwing X away because EMWH isn't a fit for what you want to build 00:13 there's event a tablet-shell example/mockup in weston to illustrate how you can build a new shell type 00:13 *even 00:13 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: different buffer allocation semantics? 00:14 Server-allocated buffers 00:14 -!- tangentstorm [~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net] has left #wayland["WeeChat 0.3.2"] 00:14 RAOF: yes, wl_shell and wl_shell_surface aren't core wayland 00:14 and server allocated vs client allocated isn't a wayland protocol thing 00:14 or even a weston thing 00:15 it's in the wl_drm interface, which is EGL driver specific 00:15 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: why do you guys want server-allocated buffers? 00:15 Prf_Jakob: Mostly arm damage, there. 00:15 RAOF: so thats whats its really about then? Closed source drivers? 00:16 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has joined #wayland 00:16 No - arm hardware (apparently) has insane constraints that make server allocation more attractive. 00:16 but that's not something wayland can't support 00:16 * magn3ts probably missed all of the interesting Mir talk :( 00:16 eg - you have at most 6 buffers that are framebuffer-compatible. 00:16 we have those GPUs at intel too 00:17 weston runs on those 00:18 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 krh: I know we could have added a wl_server_side or somesuch interface, yea. 00:19 RAOF: no, you write a wl_drm interface that your driver uses 00:19 It seems weird that this conversation didn't happen before the mir announcement / decision. 00:19 wl_drm replacement 00:20 That's what I meant; I presumed calling it wl_drm would be a horrible name collision, though. 00:20 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 yeah, but you don't call it that 00:21 on the server side your driver installs a driver specific extension 00:21 on the client side your egl client looks for that extension 00:21 RAOF: fair enough, you probably want to implement eviction anyways otherwise you might end up with clients DDoS:ing your server easily. 00:21 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 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 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 you can call it anything you want, as long as client and server side agrees on the name 00:22 RAOF: all the toolkits see is EGL. 00:23 RAOF: that's like saying, if we don't use EWMH is there any benefit to X? 00:23 Prf_Jakob: No, they also have to see some shell interface. 00:23 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 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 on top of that you can write your own shell and port toolkits 00:24 Prf_Jakob: The toolkits will need to do *something* more than just draw to a buffer :) 00:24 RAOF: the more in this case is calling EGL calls. 00:24 RAOF: also, the shell-type integration points in something like qt or gtk+ are few and tiny 00:25 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 Prf_Jakob: eg: eglCreateDialogWindow() doesn't really have a nice ring to it :) 00:25 RAOF: sure right and thats all handled by Wayland proto. 00:26 Prf_Jakob: But not if we're throwing away the existing shell-y bits of the wayland protocol. 00:26 krh: correct me if I'm wrong, the shell-y bits of wayland proto never touches the DRM bits? 00:27 Prf_Jakob: yes, it's completely separate 00:27 RAOF: ^ 00:27 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 yeah 00:27 Prf_Jakob: They don't, right. But we *additionally* want to throw away the existing shell-y bits. 00:27 RAOF: yes, but that's not a good reason to reinvent buffer allocation, sharing, frame sync, input model etc 00:28 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 RAOF: you only want to use server-allocation on drivers that really need it. 00:28 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 if you look at mir example it's scary 00:28 Prf_Jakob: We want to use it everywhere. 00:28 doesn't seems to have the notion of atomic commit 00:28 it's practically impossible to convince hw vendors to support new window systems 00:29 or frame synchronisation 00:29 RAOF: you don't 00:29 there is a bunch of usleep in them with bogus value to supposedly do 60fps 00:29 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 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 RAOF: event X with DRI3 is removing server side allocated buffer where ever possible 00:30 Yes, I know. 00:31 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland 00:31 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 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 glisse, also a lot of roundtrips which really seem unnecessary like waiting until a buffer got released only to drop it. 00:33 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 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 lol 00:35 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 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 I don't particularly like that API style, and a couple of us are in the process of getting a better one :) 00:37 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 RAOF: To what comment does that refer? 00:38 soreau: To the toolkit API, as evident in the examples/ folder. 00:38 oh 00:39 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland 00:40 Prf_Jakob: if you're referring to the server-side buffers thing, it's not something i can make public. 00:41 daniels: aww 00:41 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 RAOF: Now any graphical linux client would have to support wayland in addition to this Mir platform? 00:41 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 Prf_Jakob: job done. 00:42 RAOF: Å 00:42 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 ^* 00:42 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 that's it really 00:42 that be nice 00:42 that's how it should work 00:43 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 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 soreau: Clients are expected to use toolkits, and (I'm pretty sure) we've committed to porting & maintaining GTK and Qt. 00:45 so what does that mean, assuming neither Mir nor Wayland dies, will drivers have to support both? 00:45 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 Prf_Jakob: Yes, it would be nice; at least we're going to be porting the toolkits. 00:46 Gtk 2, 3 or both? 00:46 soreau: No. We expect to be able to provite Mir support in gtk and Qt master. 00:46 wm4: yeah, it'll be great. 00:46 RAOF: any clients like games that talk directly to the platform? 00:46 and* 00:47 I *think* we might be porting SDL? 00:47 -!- mgottschlag [~quassel@reactos/tester/phoenix64] has quit [Ping timeout: 255 seconds] 00:47 I said directly :-/ 00:47 RAOF: That sounds pretty horrible 00:48 But, yeah. In an ideal world there wouldn't be extra Mir & Wayland backends required. 00:48 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 so just use EGL and wayland, the shell-y bits wont be in the toolkits anyways. 00:49 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 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 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 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 Although fewer toolkit changes than if you were, say, also changing out the input stack ☺ 00:51 RAOF: So now each client might support this or that compositor and there's no standardized anything? 00:51 soreau: Welcome! 00:52 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: 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 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 Then you see what's out there. 00:53 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 RAOF: So may the best man win 00:54 Different for the sake of being different. Sounds like the same story it was with Upstart. 00:54 MeanEYE: Except, of course, for the fact that upstart predated systemd by many years. 00:54 Except that. 00:55 Prf_Jakob: Yeah, in an ideal world… 00:55 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 Maybe Canonical is just a division of Microsoft hired to try and take down Linux 00:56 Our secret is out!!!!!111111 00:56 -!- jbkonno [jbkonno@nat/intel/x-ltgtsvgtesvtqrou] has quit [Quit: Lost terminal] 00:56 That said, I've grown less convinced over time doing a wayland-based Unity compositor would have helped us or wayland significantly. 00:57 RAOF: would it even be possible to try and have a meeting between the developers to try and work things out? 00:57 Unity is not helping *anyone* 00:57 so that point is moot 00:58 Prf_Jakob: I understand that someone - possibly Thomas Voß? - is organising such a meeting. 00:58 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 RAOF: So if you are doing your own thing. What about applications that still require X? 00:59 Prf_Jakob: I wouldn't expect such a meeting to change our course, though, so don't get your hopes up :/ 00:59 MeanEYE: They get X. Why wouldn't they? 01:00 RAOF: I meant if Ubuntu implements Mir... how would you start something that requires X? 01:00 RAOF: also a wikipage describing your reasons for server-side-allocation, and not the Mir page with miss-understandings about Wayland. 01:00 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 MeanEYE: classy they even renamed xwayland to xmir 01:01 -!- lasers [~lasers@unaffiliated/lasers] has joined #wayland 01:01 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 It's the standard nomenclature as far as I can tell - xquartz, xwayland, xmir 01:01 o_0 01:01 how about NOT renaming it in the first place? 01:01 and NOT forking the whole project? 01:01 It's not a rename of xwayland? 01:01 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 Because - and I know this may shock you - it talks to a Mir server rather than a wayland server? 01:02 o_0 01:02 MeanEYE: Right, they didn't mention any of these concerns until after announcing this 01:02 (It also has a crazy thread-to-eventloop proxy, because of threading) 01:02 o_0 01:03 RAOF: even if you bin the shell interfaces, you still at least share core surface management, input, etc 01:03 RAOF: I'm not shocked, I'm appalled 01:03 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 soreau: I'm sorry that you're offended. 01:05 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 RAOF: curious - you mean core input (key/pointer/touch), or input methods? 01:07 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 interesting 01:10 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 so say we all 01:10 RAOF: IT'S LITERALLY YOUR FAULT YOU ARE SUCH A DICK. 01:10 ;) 01:11 * RAOF dies 01:11 RAOF: soz 01:11 :) 01:11 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 So wayland vs. Mir will be the new flamewar? 01:11 Incidentally, working on private stuff sucks. 01:12 Nope. 01:12 Zoxc: Yeah. upstart-vs-systemd has died down too much. We need something new and fresh! 01:12 According to Aaron Seigo, KDE developer, they won't accept it. 01:12 They're welcome to use X. 01:13 -!- rillian [~giles@mf4-xiph.osuosl.org] has joined #wayland 01:13 Yup. Alienating all of the Linux community will do good for Ubuntu. 01:13 MeanEYE: It's actually worked pretty well so far :) 01:13 It's like dealing with the whole fiasco MS created with IE in the early days. 01:13 Time will tell. 01:14 - 01:14 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 Jugling between TV, mobile, desktop, tablet... and now this. 01:14 -!- alexfpms [~Alex@unaffiliated/alexfpms] has quit [Ping timeout: 248 seconds] 01:15 soreau: now that isn't helping at all 01:15 soreau: Because we (still) believe open source is empowering and fundamentally the most efficient development method? 01:16 Prf_Jakob: And forking wayland is? 01:16 soreau: two wrongs doesn't make a right. 01:16 We're not forking wayland; that's part of what krh is annoyed with? 01:17 RAOF: he said he was annoyed with you having a wiki page full of missunderstandings of how wayland work. 01:17 That too. 01:18 RAOF: and I would guess that you are doing pretty much exactly what wayland does but a tiny bit differently. 01:18 It is 01:18 Little things that matter 01:18 It stands on the groundwork that was laid over several years for wayland 01:18 RAOF: and that you guys gave ZERO feedback on Wayland. 01:18 Am not worried. If Mir is optimized as good as Unity is. :) It' 01:18 It's an easy choice for me. 01:19 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 MeanEYE: I think they optimized it to fail-fast 01:19 crashes pretty quick 01:19 Don't know. Don't use it. I don't think window manager should eat 100+ MB of RAM. 01:20 MeanEYE: I switched to xubuntu the year they released it, never looked back 01:20 soreau: if you actually want them to use your project I would recommend not insulting them. 01:20 Am on i3wm. Quite a breeze. 6MB of RAM usage. :) 01:21 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 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 soreau: and quite unusable for non-geek stuff 01:22 Am not insulting, am merely stating my observation. 01:22 soreau: I find unity perfectly capable for my usecases btw. 01:22 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 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 soreau: Infancy? It's been around, what, 5 years? 01:23 But Mir *could* become compatible with Wayland, as far as I understand, right? 01:23 RAOF: ok, a child can only be considered an infant for what, 9 months? 01:23 You get my point. 01:23 "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 runeks: Yes; I'm not sure if we'll do that work, and it doesn't help the driver situation. 01:24 I hope we can do something for the driver situation, frankly. 01:24 RAOF: What is the driver situation, exactly? 01:24 Wow, what a counterproductive action. 01:25 Want to help with driver situation, makes it more complicated for companies writing drivers. 01:25 They just have to publish open source drivers. Easy. 01:25 RAOF: Again the input cituation could have been improved if you guys actually talked to the Wayland developers. 01:26 MeanEYE: They're saving all rational logical decisions to be made in their original display server code 01:26 KiBi: heh 01:26 KiBi: That does neatly solve the situation :) 01:26 Am gonna go watch something. This conversation makes my brain hurt. Too few logical decisions for my liking. ^^ 01:26 RAOF: How many people are supposed to be working on this code? 01:27 didn't the Mir wiki page say they've been in "contact" with vendors of closed source drivers 01:27 It does indeed. 01:27 "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 soreau: Some 01:27 so what does that mean 01:28 -!- sirdancealo2 [~sirdancea@98.82.broadband5.iol.cz] has quit [Ping timeout: 252 seconds] 01:28 RAOF: That sounds like maybe a few+ 01:28 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 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 Hello I've just finished reading it... woah 01:30 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 RAOF: weren't you fed up with waiting on waiting for wayland to get mature? 01:32 so what, wrote bullshit about wayland (again). sigh. not that anyone reads it except the peanut gallery 01:33 Siekacz: It's not going to get mature without someone using it in anger. We *could* have been that someone. 01:33 Indeed, were starting to become that someone. 01:33 This is fun. 01:33 This is the only good thing that can come of this 01:34 hell, and mir sounds like a cool marketing project i might as well contribute a few patches 01:34 min2: patches not welcome 01:34 Mir might be the very ingredience to make it "mature". After all, competition is healthy. 01:34 RAOF: as far as I remeber there was an attempt to use wayland as system compositor, why did it fail? 01:34 soreau: That's unfair 01:35 RAOF, I have one technical question: how are you going to implement input methods? 01:35 Is it going to be like XKB where you have input methods directly in the path of the input stack? 01:35 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 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 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 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 this chat 01:36 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 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 RAOF, well, that becomes complicated when you want the IM to use a toolkit. 01:38 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 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 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 heh, #mir is Musical Information Retrieval 01:39 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 Will Mir require toolkits to build in support for it or will it be compatible with Wayland? 01:40 Jasper: Not necessarily - you can require the IM to register itself as an IM and get privileged access. 01:40 And what prevents some application from doing that? 01:40 soreau: mir is many things, a russian space shuttle and peace in russian 01:41 Jasper: Because its manifest doesn't have the requisite permission request? 01:41 RAOF, do you have application sandboxing? 01:41 min2: great too, that mir is completely unique and easily searchable 01:41 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 soreau: ok. please will you test my focusstealing patch ??? please 01:41 RAOF, OK. 01:42 soreau: it applies i promise 01:42 RAOF, that means that Mir has some permission model greater than Wayland. 01:42 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 And it assumes something about manifests and so on. 01:42 min2: I wouldn't be able to give any suggestion 01:42 or opinion 01:42 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 мир also means "the world" 01:43 RAOF, OK. 01:43 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 RAOF, so input methods are not Mir's problem, they're Unity's problem. 01:43 RAOF, oh, you're not going to implement the "system compositor" idea? 01:43 soreau: but you simply just type in editor, simply just run ./clients/focusstealer 01:43 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 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 Right. 01:44 soreau: maybe read this http://www.chaosreigns.com/wiki/Wayland_genericpage5#.5Bshell.5D_focus_stealing 01:44 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 min2: Sorry, I don't have time right now. I have to go soon too 01:45 soreau: ok never mind 01:45 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 RAOF, yeah, landing IM support was a big thing for GNOME 3.6 and GNOME 3.8. 01:46 min2: maybe a little later 01:46 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 RAOF, it's always been an Intel thing 01:46 -!- sirdancealot [~sirdancea@98.82.broadband5.iol.cz] has joined #wayland 01:46 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 RAOF, I think halfline might have been working on a Wayland backend for plymouth, too. 01:49 RAOF, by the way, do you have a link to your Wayland system compositor? 01:49 I think we might have a Mir backend for plymouth lying around somewhere, but I've never seen it. 01:50 Jasper: https://github.com/RAOF/weston/tree/system-compositor + xserver + xf86-video-ati + xf86-video-nouveau (I think) 01:50 RAOF, thanks! 01:50 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 Check out clients/simple-display-manager.c for that; there's also a lightdm branch somewhere that worked. 01:52 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 soreau, can we try and keep the discussion technical? 01:53 Jasper: If that's the case, can we keep it wayland-only? 01:53 soreau, sure; that's what I've been trying to do. 01:53 I could have called OT a long time ago 01:54 but considering the circumstances.. 01:54 -!- polysix [hoax@mew.chickenkiller.com] has joined #wayland 01:55 Jasper, RAOF: aiui the mutter wayland port is being revived