Heh. It's our turn to pull a systemd!

SUBMITTED BY: Guest

DATE: Nov. 15, 2013, 12:58 a.m.

FORMAT: Text only

SIZE: 40.6 kB

Raw Download

HITS: 804

Report
  1. 23:50 <RAOF> Heh. It's our turn to pull a systemd!
  2. 23:50 <runeks> RAOF: did you know about this?
  3. 23:50 <RAOF> Yes; hence my lack of work on the wayland system compositor branches.
  4. 23:53 <Darxus> RAOF: I kind of wondered if that was the case.
  5. 23:55 <krh> RAOF: the technical reasons on the mir page just don't add up
  6. 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
  7. 23:57 * RAOF checks the Mir page again
  8. 23:58 <runeks> krh: What about this, does it have merit?
  9. 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."
  10. 23:58 <krh> runeks: everything about input
  11. 23:59 <runeks> From this blog post: http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/
  12. -!- Day changed to Tuesday, March 05, 2013
  13. 00:00 <krh> there's nothing priviledge about wl_shell
  14. 00:00 <krh> I think the author mistakes it for the interface required to implement a shell
  15. 00:01 <krh> that interface is desktop_shell and is only available to the desktop-shell.c client that the compositor forks
  16. 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?
  17. 00:01 <airlied> RAOF: if you do it upstream, yes
  18. 00:02 <airlied> I think the most compelling argument is argument-from-control-of-project
  19. 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
  20. 00:02 <RAOF> airlied: I think that people in charge are uncertain that it would be accepted upstream.
  21. 00:02 <krh> that's what pisses me off
  22. 00:02 <krh> you can do whatever you want and you don't need my permission
  23. 00:02 <krh> but don't piss on wayland in the process
  24. 00:02 <airlied> RAOF: you work upstream, you don't have to be accepted
  25. 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
  26. 00:03 <RAOF> airlied: You always have to be accepted, unless you want to fork?
  27. 00:03 <crazedpsyc> ugh, this is so annoying. "We don't understand wayland, so we need to create our own system from scratch"
  28. 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.
  29. 00:05 <airlied> RAOF: fail, you assign devs to work on the upstream project, to enact your design
  30. 00:05 <RAOF> krh: I don't think we *meant* to piss all over wayland.
  31. 00:05 <krh> RAOF: yes, so don't go and tell the world it's broken
  32. 00:05 <krh> if you don't know what it is
  33. 00:05 <airlied> they become part of the upstream project, and are no different
  34. 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"
  35. 00:06 <RAOF> krh: I don't think we *did* say that? It's a mistake if so - wayland certainly doesn't.
  36. 00:06 <krh> I'll have fun explaining how that's not the case to everybody for the next few months
  37. 00:07 <airlied> krh: definitely need a single place of explaination to point others a
  38. 00:07 -!- olesalscheider [~olesalsch@2001:4dd0:ff00:835c:6ef0:49ff:fe02:25e3] has quit [Quit: Konversation terminated!]
  39. 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
  40. 00:08 <krh> RAOF: but I know Iit has to be under C control and be GPL CLA so that fine
  41. 00:08 <RAOF> krh: Likewise; but is that actually *useful* if we replace all the interfaces?
  42. 00:08 <krh> but those reasons look bad on the web page, I know
  43. 00:08 -!- uartie [uartie@nat/intel/x-bcdajueitxzaktln] has joined #wayland
  44. 00:08 <RAOF> airlied: That assumes everyone upstream shares the same goals?
  45. 00:08 <krh> RAOF: I don't think you need to replace them
  46. 00:08 <airlied> RAOF: okay if your goals are GPL and company controlled, then probably not
  47. 00:09 <krh> none of the reasons listed on the page are valid
  48. 00:09 -!- msclrhd [~msclrhd@85.211.124.135] has joined #wayland
  49. 00:09 <krh> none of them calls for a change in any of the core interfaces
  50. 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.
  51. 00:12 -!- plombo [~plombo@129.15.131.187] has joined #wayland
  52. 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
  53. 00:12 <krh> it's like throwing X away because EMWH isn't a fit for what you want to build
  54. 00:13 <krh> there's event a tablet-shell example/mockup in weston to illustrate how you can build a new shell type
  55. 00:13 <krh> *even
  56. 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?
  57. 00:13 <krh> RAOF: different buffer allocation semantics?
  58. 00:14 <RAOF> Server-allocated buffers
  59. 00:14 -!- tangentstorm [~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net] has left #wayland["WeeChat 0.3.2"]
  60. 00:14 <krh> RAOF: yes, wl_shell and wl_shell_surface aren't core wayland
  61. 00:14 <krh> and server allocated vs client allocated isn't a wayland protocol thing
  62. 00:14 <krh> or even a weston thing
  63. 00:15 <krh> it's in the wl_drm interface, which is EGL driver specific
  64. 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?
  65. 00:15 <Prf_Jakob> RAOF: why do you guys want server-allocated buffers?
  66. 00:15 <RAOF> Prf_Jakob: Mostly arm damage, there.
  67. 00:15 <Prf_Jakob> RAOF: so thats whats its really about then? Closed source drivers?
  68. 00:16 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has joined #wayland
  69. 00:16 <RAOF> No - arm hardware (apparently) has insane constraints that make server allocation more attractive.
  70. 00:16 <krh> but that's not something wayland can't support
  71. 00:16 * magn3ts probably missed all of the interesting Mir talk :(
  72. 00:16 <RAOF> eg - you have at most 6 buffers that are framebuffer-compatible.
  73. 00:16 <krh> we have those GPUs at intel too
  74. 00:17 <krh> weston runs on those
  75. 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
  76. 00:18 -!- mayhew [~justin@hlfxns0163w-047054165110.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #wayland
  77. 00:18 -!- gallo [gallo@2a02:1610:1:1003:20c:29ff:fe3e:4633] has joined #wayland
  78. 00:18 <RAOF> krh: I know we could have added a wl_server_side or somesuch interface, yea.
  79. 00:19 <krh> RAOF: no, you write a wl_drm interface that your driver uses
  80. 00:19 <Darxus> It seems weird that this conversation didn't happen before the mir announcement / decision.
  81. 00:19 <krh> wl_drm replacement
  82. 00:20 <RAOF> That's what I meant; I presumed calling it wl_drm would be a horrible name collision, though.
  83. 00:20 <krh> RAOF: if your driver want to do server side allocation, your driver will use a wl_$driver interface to do that
  84. 00:20 -!- cdidd [~cdidd@128-72-120-234.broadband.corbina.ru] has joined #wayland
  85. 00:20 <krh> yeah, but you don't call it that
  86. 00:21 <krh> on the server side your driver installs a driver specific extension
  87. 00:21 <krh> on the client side your egl client looks for that extension
  88. 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.
  89. 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
  90. 00:22 -!- ioo [~ioo@81-237-244-214-no52.tbcn.telia.com] has joined #wayland
  91. 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
  92. 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?
  93. 00:22 <krh> you can call it anything you want, as long as client and server side agrees on the name
  94. 00:22 <Prf_Jakob> RAOF: all the toolkits see is EGL.
  95. 00:23 <krh> RAOF: that's like saying, if we don't use EWMH is there any benefit to X?
  96. 00:23 <RAOF> Prf_Jakob: No, they also have to see some shell interface.
  97. 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
  98. 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).
  99. 00:23 -!- mgottschlag [~quassel@reactos/tester/phoenix64] has joined #wayland
  100. 00:24 <krh> on top of that you can write your own shell and port toolkits
  101. 00:24 <RAOF> Prf_Jakob: The toolkits will need to do *something* more than just draw to a buffer :)
  102. 00:24 <Prf_Jakob> RAOF: the more in this case is calling EGL calls.
  103. 00:24 <krh> RAOF: also, the shell-type integration points in something like qt or gtk+ are few and tiny
  104. 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.
  105. 00:25 <RAOF> Prf_Jakob: eg: eglCreateDialogWindow() doesn't really have a nice ring to it :)
  106. 00:25 <Prf_Jakob> RAOF: sure right and thats all handled by Wayland proto.
  107. 00:26 <RAOF> Prf_Jakob: But not if we're throwing away the existing shell-y bits of the wayland protocol.
  108. 00:26 <Prf_Jakob> krh: correct me if I'm wrong, the shell-y bits of wayland proto never touches the DRM bits?
  109. 00:27 <krh> Prf_Jakob: yes, it's completely separate
  110. 00:27 <Prf_Jakob> RAOF: ^
  111. 00:27 <krh> Prf_Jakob: and we could just have one EGL platform
  112. 00:27 -!- Hwkiller [~Hwkiller@cpe-174-098-166-167.triad.res.rr.com] has quit [Quit: WeeChat 0.4.0]
  113. 00:27 <Prf_Jakob> yeah
  114. 00:27 <RAOF> Prf_Jakob: They don't, right. But we *additionally* want to throw away the existing shell-y bits.
  115. 00:27 <krh> RAOF: yes, but that's not a good reason to reinvent buffer allocation, sharing, frame sync, input model etc
  116. 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?
  117. 00:28 <Prf_Jakob> RAOF: you only want to use server-allocation on drivers that really need it.
  118. 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
  119. 00:28 <glisse> if you look at mir example it's scary
  120. 00:28 <RAOF> Prf_Jakob: We want to use it everywhere.
  121. 00:28 <glisse> doesn't seems to have the notion of atomic commit
  122. 00:28 <krh> it's practically impossible to convince hw vendors to support new window systems
  123. 00:29 <glisse> or frame synchronisation
  124. 00:29 <krh> RAOF: you don't
  125. 00:29 <glisse> there is a bunch of usleep in them with bogus value to supposedly do 60fps
  126. 00:29 <Prf_Jakob> RAOF: why? I haven't we spent the last 10ish years trying to remove roundtrips to the server?
  127. 00:29 -!- aavci [~aavci@78.165.21.35] has quit [Quit: Konversation terminated!]
  128. 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.
  129. 00:30 <krh> RAOF: event X with DRI3 is removing server side allocated buffer where ever possible
  130. 00:30 <RAOF> Yes, I know.
  131. 00:31 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
  132. 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.
  133. 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
  134. 00:32 <dvdhrm> glisse, also a lot of roundtrips which really seem unnecessary like waiting until a buffer got released only to drop it.
  135. 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 :)
  136. 00:34 * RAOF wonders about that usleep in demo_client_accelerated.c; eglSwapBuffers *should* be blocking there
  137. 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.
  138. 00:35 <soreau> lol
  139. 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.
  140. 00:36 <RAOF> Darxus: It would have been nicer to show off a working prototype of a wayland compositor, yeah :)
  141. 00:36 -!- cpst1 [~Adium@d24-141-253-131.home.cgocable.net] has joined #wayland
  142. 00:37 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
  143. 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 :)
  144. 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.
  145. 00:38 <soreau> RAOF: To what comment does that refer?
  146. 00:38 <RAOF> soreau: To the toolkit API, as evident in the examples/ folder.
  147. 00:38 <soreau> oh
  148. 00:39 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
  149. 00:40 <daniels> Prf_Jakob: if you're referring to the server-side buffers thing, it's not something i can make public.
  150. 00:41 <Prf_Jakob> daniels: aww
  151. 00:41 <soreau> RAOF: So how are clients expected to work?
  152. 00:41 -!- vpovirk [~urk@75-146-153-89-minnesota.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
  153. 00:41 <soreau> RAOF: Now any graphical linux client would have to support wayland in addition to this Mir platform?
  154. 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
  155. 00:41 <daniels> Prf_Jakob: job done.
  156. 00:42 <Prf_Jakob> RAOF: Å
  157. 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
  158. 00:42 <Prf_Jakob> ^*
  159. 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
  160. 00:42 <daniels> that's it really
  161. 00:42 <Prf_Jakob> that be nice
  162. 00:42 <krh> that's how it should work
  163. 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
  164. 00:43 <krh> it's how it was designed
  165. 00:43 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
  166. 00:44 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
  167. 00:45 <RAOF> soreau: Clients are expected to use toolkits, and (I'm pretty sure) we've committed to porting & maintaining GTK and Qt.
  168. 00:45 <wm4> so what does that mean, assuming neither Mir nor Wayland dies, will drivers have to support both?
  169. 00:45 <soreau> RAOF: So you will have gtk and qt repos that are not master but housed in launchpad/bzr?
  170. 00:46 -!- cdidd [~cdidd@128-72-120-234.broadband.corbina.ru] has quit [Remote host closed the connection]
  171. 00:46 <RAOF> Prf_Jakob: Yes, it would be nice; at least we're going to be porting the toolkits.
  172. 00:46 <msclrhd> Gtk 2, 3 or both?
  173. 00:46 <RAOF> soreau: No. We expect to be able to provite Mir support in gtk and Qt master.
  174. 00:46 <daniels> wm4: yeah, it'll be great.
  175. 00:46 <Prf_Jakob> RAOF: any clients like games that talk directly to the platform?
  176. 00:46 <Prf_Jakob> and*
  177. 00:47 <RAOF> I *think* we might be porting SDL?
  178. 00:47 -!- mgottschlag [~quassel@reactos/tester/phoenix64] has quit [Ping timeout: 255 seconds]
  179. 00:47 <Prf_Jakob> I said directly :-/
  180. 00:47 <soreau> RAOF: That sounds pretty horrible
  181. 00:48 <RAOF> But, yeah. In an ideal world there wouldn't be extra Mir & Wayland backends required.
  182. 00:48 <RAOF> soreau: Horrible in what way?
  183. 00:48 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Remote host closed the connection]
  184. 00:48 <Prf_Jakob> so just use EGL and wayland, the shell-y bits wont be in the toolkits anyways.
  185. 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
  186. 00:49 -!- cdidd [~cdidd@95-27-225-136.broadband.corbina.ru] has joined #wayland
  187. 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
  188. 00:49 <soreau> RAOF: That's why it's horrible.
  189. 00:50 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has joined #wayland
  190. 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.\
  191. 00:50 -!- bluetech_ [~bluetech@109.64.29.128] has quit [Ping timeout: 255 seconds]
  192. 00:50 <RAOF> Although fewer toolkit changes than if you were, say, also changing out the input stack ☺
  193. 00:51 <soreau> RAOF: So now each client might support this or that compositor and there's no standardized anything?
  194. 00:51 <RAOF> soreau: Welcome!
  195. 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.
  196. 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?
  197. 00:53 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has joined #wayland
  198. 00:53 <RAOF> Well, if you're Valve, you probably use X for another couple of years.
  199. 00:53 -!- Jubb [~Jubb@pool-108-28-62-61.washdc.fios.verizon.net] has quit [Client Quit]
  200. 00:53 <RAOF> Then you see what's out there.
  201. 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.
  202. 00:53 <soreau> RAOF: So may the best man win
  203. 00:54 <MeanEYE> Different for the sake of being different. Sounds like the same story it was with Upstart.
  204. 00:54 <RAOF> MeanEYE: Except, of course, for the fact that upstart predated systemd by many years.
  205. 00:54 <MeanEYE> Except that.
  206. 00:55 <RAOF> Prf_Jakob: Yeah, in an ideal world…
  207. 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
  208. 00:56 <soreau> Maybe Canonical is just a division of Microsoft hired to try and take down Linux
  209. 00:56 <RAOF> Our secret is out!!!!!111111
  210. 00:56 -!- jbkonno [jbkonno@nat/intel/x-ltgtsvgtesvtqrou] has quit [Quit: Lost terminal]
  211. 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.
  212. 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?
  213. 00:57 <soreau> Unity is not helping *anyone*
  214. 00:57 <soreau> so that point is moot
  215. 00:58 <RAOF> Prf_Jakob: I understand that someone - possibly Thomas Voß? - is organising such a meeting.
  216. 00:58 <Prf_Jakob> RAOF: that would be awesome, because not having YAWS would be awesome.
  217. 00:59 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has quit [Remote host closed the connection]
  218. 00:59 <MeanEYE> RAOF: So if you are doing your own thing. What about applications that still require X?
  219. 00:59 <RAOF> Prf_Jakob: I wouldn't expect such a meeting to change our course, though, so don't get your hopes up :/
  220. 00:59 <RAOF> MeanEYE: They get X. Why wouldn't they?
  221. 01:00 <MeanEYE> RAOF: I meant if Ubuntu implements Mir... how would you start something that requires X?
  222. 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.
  223. 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.
  224. 01:00 <soreau> MeanEYE: <krh> classy <krh> they even renamed xwayland to xmir
  225. 01:01 -!- lasers [~lasers@unaffiliated/lasers] has joined #wayland
  226. 01:01 <RAOF> I'm not sure what *else* I would have called it!
  227. 01:01 -!- youlysses [~user@75-132-7-80.dhcp.stls.mo.charter.com] has joined #wayland
  228. 01:01 <RAOF> It's the standard nomenclature as far as I can tell - xquartz, xwayland, xmir
  229. 01:01 <MeanEYE> o_0
  230. 01:01 <soreau> how about NOT renaming it in the first place?
  231. 01:01 <soreau> and NOT forking the whole project?
  232. 01:01 <RAOF> It's not a rename of xwayland?
  233. 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.
  234. 01:02 <RAOF> Because - and I know this may shock you - it talks to a Mir server rather than a wayland server?
  235. 01:02 <MeanEYE> o_0
  236. 01:02 <soreau> MeanEYE: Right, they didn't mention any of these concerns until after announcing this
  237. 01:02 <RAOF> (It also has a crazy thread-to-eventloop proxy, because of threading)
  238. 01:02 <MeanEYE> o_0
  239. 01:03 <daniels> RAOF: even if you bin the shell interfaces, you still at least share core surface management, input, etc
  240. 01:03 <soreau> RAOF: I'm not shocked, I'm appalled
  241. 01:03 <soreau> I'm offended
  242. 01:03 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has quit [Quit: Konversation terminated!]
  243. 01:03 -!- JesseBarker [~jesse@linaro/JesseBarker] has quit [Quit: Ex-Chat]
  244. 01:04 <RAOF> soreau: I'm sorry that you're offended.
  245. 01:05 <RAOF> daniels: Yeah; we seem to like the android input stack. This is something that I'm not totally familiar with.
  246. 01:05 * RAOF wishes we still had Chase
  247. 01:06 <daniels> RAOF: curious - you mean core input (key/pointer/touch), or input methods?
  248. 01:07 <RAOF> Core input, and possibly input methods - I'm unsure about the latter.
  249. 01:08 -!- gmaxwell [~greg@wikimedia/KatWalsh/x-0001] has joined #wayland
  250. 01:08 -!- metajack [~Adium@c-68-35-124-4.hsd1.nm.comcast.net] has joined #wayland
  251. 01:09 <daniels> interesting
  252. 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
  253. 01:10 <oneman> so say we all
  254. 01:10 <daniels> RAOF: IT'S LITERALLY YOUR FAULT YOU ARE SUCH A DICK.
  255. 01:10 <oneman> ;)
  256. 01:11 * RAOF dies
  257. 01:11 <daniels> RAOF: soz
  258. 01:11 <RAOF> :)
  259. 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
  260. 01:11 <Zoxc> So wayland vs. Mir will be the new flamewar?
  261. 01:11 <RAOF> Incidentally, working on private stuff sucks.
  262. 01:12 <MeanEYE> Nope.
  263. 01:12 <RAOF> Zoxc: Yeah. upstart-vs-systemd has died down too much. We need something new and fresh!
  264. 01:12 <MeanEYE> According to Aaron Seigo, KDE developer, they won't accept it.
  265. 01:12 <RAOF> They're welcome to use X.
  266. 01:13 -!- rillian [~giles@mf4-xiph.osuosl.org] has joined #wayland
  267. 01:13 <MeanEYE> Yup. Alienating all of the Linux community will do good for Ubuntu.
  268. 01:13 <RAOF> MeanEYE: It's actually worked pretty well so far :)
  269. 01:13 <MeanEYE> It's like dealing with the whole fiasco MS created with IE in the early days.
  270. 01:13 <MeanEYE> Time will tell.
  271. 01:14 <min2> -
  272. 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
  273. 01:14 <MeanEYE> Jugling between TV, mobile, desktop, tablet... and now this.
  274. 01:14 -!- alexfpms [~Alex@unaffiliated/alexfpms] has quit [Ping timeout: 248 seconds]
  275. 01:15 <Prf_Jakob> soreau: now that isn't helping at all
  276. 01:15 <RAOF> soreau: Because we (still) believe open source is empowering and fundamentally the most efficient development method?
  277. 01:16 <soreau> Prf_Jakob: And forking wayland is?
  278. 01:16 <Prf_Jakob> soreau: two wrongs doesn't make a right.
  279. 01:16 <RAOF> We're not forking wayland; that's part of what krh is annoyed with?
  280. 01:17 <Prf_Jakob> RAOF: he said he was annoyed with you having a wiki page full of missunderstandings of how wayland work.
  281. 01:17 <RAOF> That too.
  282. 01:18 <Prf_Jakob> RAOF: and I would guess that you are doing pretty much exactly what wayland does but a tiny bit differently.
  283. 01:18 <soreau> It is
  284. 01:18 <Siekacz> Little things that matter
  285. 01:18 <soreau> It stands on the groundwork that was laid over several years for wayland
  286. 01:18 <Prf_Jakob> RAOF: and that you guys gave ZERO feedback on Wayland.
  287. 01:18 <MeanEYE> Am not worried. If Mir is optimized as good as Unity is. :) It'
  288. 01:18 <MeanEYE> It's an easy choice for me.
  289. 01:19 <Prf_Jakob> RAOF: Which could have avoided this whole mess to begin with.
  290. 01:19 -!- hardening [~hardening@2001:5c0:1502:900:5873:a175:9b40:c975] has quit [Quit: Quitte]
  291. 01:19 <soreau> MeanEYE: I think they optimized it to fail-fast
  292. 01:19 <soreau> crashes pretty quick
  293. 01:19 <MeanEYE> Don't know. Don't use it. I don't think window manager should eat 100+ MB of RAM.
  294. 01:20 <soreau> MeanEYE: I switched to xubuntu the year they released it, never looked back
  295. 01:20 <Prf_Jakob> soreau: if you actually want them to use your project I would recommend not insulting them.
  296. 01:20 <MeanEYE> Am on i3wm. Quite a breeze. 6MB of RAM usage. :)
  297. 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.
  298. 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
  299. 01:21 <Siekacz> soreau: and quite unusable for non-geek stuff
  300. 01:22 <MeanEYE> Am not insulting, am merely stating my observation.
  301. 01:22 <Prf_Jakob> soreau: I find unity perfectly capable for my usecases btw.
  302. 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
  303. 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.
  304. 01:22 <RAOF> soreau: Infancy? It's been around, what, 5 years?
  305. 01:23 <runeks> But Mir *could* become compatible with Wayland, as far as I understand, right?
  306. 01:23 <soreau> RAOF: ok, a child can only be considered an infant for what, 9 months?
  307. 01:23 <soreau> You get my point.
  308. 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."
  309. 01:24 <RAOF> runeks: Yes; I'm not sure if we'll do that work, and it doesn't help the driver situation.
  310. 01:24 <RAOF> I hope we can do something for the driver situation, frankly.
  311. 01:24 <runeks> RAOF: What is the driver situation, exactly?
  312. 01:24 <MeanEYE> Wow, what a counterproductive action.
  313. 01:25 <MeanEYE> Want to help with driver situation, makes it more complicated for companies writing drivers.
  314. 01:25 <KiBi> They just have to publish open source drivers. Easy.
  315. 01:25 <Prf_Jakob> RAOF: Again the input cituation could have been improved if you guys actually talked to the Wayland developers.
  316. 01:26 <soreau> MeanEYE: They're saving all rational logical decisions to be made in their original display server code
  317. 01:26 <soreau> KiBi: heh
  318. 01:26 <RAOF> KiBi: That does neatly solve the situation :)
  319. 01:26 <MeanEYE> Am gonna go watch something. This conversation makes my brain hurt. Too few logical decisions for my liking. ^^
  320. 01:26 <soreau> RAOF: How many people are supposed to be working on this code?
  321. 01:27 <wm4> didn't the Mir wiki page say they've been in "contact" with vendors of closed source drivers
  322. 01:27 <RAOF> It does indeed.
  323. 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."
  324. 01:27 <RAOF> soreau: Some
  325. 01:27 <wm4> so what does that mean
  326. 01:28 -!- sirdancealo2 [~sirdancea@98.82.broadband5.iol.cz] has quit [Ping timeout: 252 seconds]
  327. 01:28 <soreau> RAOF: That sounds like maybe a few+
  328. 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. ..."
  329. 01:28 * RAOF has no idea if # of developers in company-confidential, and doesn't know off the top of his head.
  330. 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.
  331. 01:30 <min2> Hello I've just finished reading it... woah
  332. 01:30 <soreau> This decision is worse than Bush's decision to double the .us national debt
  333. 01:30 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has joined #wayland
  334. 01:32 <Siekacz> RAOF: weren't you fed up with waiting on waiting for wayland to get mature?
  335. 01:32 <min2> so what, wrote bullshit about wayland (again). sigh. not that anyone reads it except the peanut gallery
  336. 01:33 <RAOF> Siekacz: It's not going to get mature without someone using it in anger. We *could* have been that someone.
  337. 01:33 <RAOF> Indeed, were starting to become that someone.
  338. 01:33 <Jasper> This is fun.
  339. 01:33 <soreau> This is the only good thing that can come of this
  340. 01:34 <min2> hell, and mir sounds like a cool marketing project i might as well contribute a few patches
  341. 01:34 <soreau> min2: patches not welcome
  342. 01:34 <gallo> Mir might be the very ingredience to make it "mature". After all, competition is healthy.
  343. 01:34 <Siekacz> RAOF: as far as I remeber there was an attempt to use wayland as system compositor, why did it fail?
  344. 01:34 <RAOF> soreau: That's unfair
  345. 01:35 <Jasper> RAOF, I have one technical question: how are you going to implement input methods?
  346. 01:35 <Jasper> Is it going to be like XKB where you have input methods directly in the path of the input stack?
  347. 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.
  348. 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?
  349. 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.
  350. 01:36 <min2> but yes this patch is fun finally something happens after an year
  351. 01:36 -!- sylware [~sylware@88.188.175.165] has quit [Remote host closed the connection]
  352. 01:36 <min2> this chat
  353. 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.
  354. 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.
  355. 01:37 <Jasper> RAOF, well, that becomes complicated when you want the IM to use a toolkit.
  356. 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.
  357. 01:38 -!- otaylor [~otaylor@c-76-127-164-212.hsd1.ct.comcast.net] has joined #wayland
  358. 01:39 <Jasper> But you still have the goal that two same-privilege processes can send each other fake events
  359. 01:39 -!- dog [~quassel@134.134.137.71] has joined #wayland
  360. 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.
  361. 01:39 <soreau> heh, #mir is Musical Information Retrieval
  362. 01:39 <Jasper> RAOF, OK, so now you have an external process that can send any other client keyboard events.
  363. 01:40 -!- jmsaunde [~jmsaunde@staples.cmclub.uwaterloo.ca] has joined #wayland
  364. 01:40 -!- ssalbiz [~ssalbiz@artificial-flavours.csclub.uwaterloo.ca] has joined #wayland
  365. 01:40 <magn3ts> Will Mir require toolkits to build in support for it or will it be compatible with Wayland?
  366. 01:40 <RAOF> Jasper: Not necessarily - you can require the IM to register itself as an IM and get privileged access.
  367. 01:40 <Jasper> And what prevents some application from doing that?
  368. 01:40 <min2> soreau: mir is many things, a russian space shuttle and peace in russian
  369. 01:41 <RAOF> Jasper: Because its manifest doesn't have the requisite permission request?
  370. 01:41 <Jasper> RAOF, do you have application sandboxing?
  371. 01:41 <soreau> min2: great too, that mir is completely unique and easily searchable
  372. 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.
  373. 01:41 <min2> soreau: ok. please will you test my focusstealing patch ??? please
  374. 01:41 <Jasper> RAOF, OK.
  375. 01:42 <min2> soreau: it applies i promise
  376. 01:42 <Jasper> RAOF, that means that Mir has some permission model greater than Wayland.
  377. 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
  378. 01:42 <Jasper> And it assumes something about manifests and so on.
  379. 01:42 <soreau> min2: I wouldn't be able to give any suggestion
  380. 01:42 <soreau> or opinion
  381. 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.
  382. 01:42 <Siekacz> мир also means "the world"
  383. 01:43 <Jasper> RAOF, OK.
  384. 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.
  385. 01:43 <Jasper> RAOF, so input methods are not Mir's problem, they're Unity's problem.
  386. 01:43 <Jasper> RAOF, oh, you're not going to implement the "system compositor" idea?
  387. 01:43 <min2> soreau: but you simply just type in editor, simply just run ./clients/focusstealer
  388. 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.
  389. 01:44 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #wayland
  390. 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.
  391. 01:44 <Jasper> Right.
  392. 01:44 <min2> soreau: maybe read this http://www.chaosreigns.com/wiki/Wayland_genericpage5#.5Bshell.5D_focus_stealing
  393. 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.
  394. 01:45 <soreau> min2: Sorry, I don't have time right now. I have to go soon too
  395. 01:45 <min2> soreau: ok never mind
  396. 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 ☺
  397. 01:45 <Jasper> RAOF, yeah, landing IM support was a big thing for GNOME 3.6 and GNOME 3.8.
  398. 01:46 <soreau> min2: maybe a little later
  399. 01:46 <RAOF> Jasper: Whatever happened to the branch of gnome-shell using wayland?
  400. 01:46 -!- polysix [~hoax@mew.chickenkiller.com] has quit [Ping timeout: 252 seconds]
  401. 01:46 <Jasper> RAOF, it's always been an Intel thing
  402. 01:46 -!- sirdancealot [~sirdancea@98.82.broadband5.iol.cz] has joined #wayland
  403. 01:46 <Jasper> RAOF, it's something we want to do but don't really have the time.
  404. 01:47 -!- iksaif_ [~iksaif@iksaif.net] has quit [Ping timeout: 252 seconds]
  405. 01:48 <Jasper> RAOF, I think halfline might have been working on a Wayland backend for plymouth, too.
  406. 01:49 <Jasper> RAOF, by the way, do you have a link to your Wayland system compositor?
  407. 01:49 <RAOF> I think we might have a Mir backend for plymouth lying around somewhere, but I've never seen it.
  408. 01:50 <RAOF> Jasper: https://github.com/RAOF/weston/tree/system-compositor + xserver + xf86-video-ati + xf86-video-nouveau (I think)
  409. 01:50 <Jasper> RAOF, thanks!
  410. 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.
  411. 01:51 <RAOF> Check out clients/simple-display-manager.c for that; there's also a lightdm branch somewhere that worked.
  412. 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
  413. 01:52 -!- klusark [~klusark@S0106d4ca6d3286ef.vc.shawcable.net] has joined #wayland
  414. 01:52 -!- mayhew [~justin@hlfxns0163w-047054165110.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Quit: leaving]
  415. 01:52 -!- chatsiri_ [~chatsiri_@node-4ch.pool-118-173.dynamic.totbb.net] has joined #wayland
  416. 01:53 <Jasper> soreau, can we try and keep the discussion technical?
  417. 01:53 <soreau> Jasper: If that's the case, can we keep it wayland-only?
  418. 01:53 <Jasper> soreau, sure; that's what I've been trying to do.
  419. 01:53 <soreau> I could have called OT a long time ago
  420. 01:54 <soreau> but considering the circumstances..
  421. 01:54 -!- polysix [hoax@mew.chickenkiller.com] has joined #wayland
  422. 01:55 <daniels> Jasper, RAOF: aiui the mutter wayland port is being revived
comments powered by Disqus