1. 24

  2. [Comment removed by author]

    1. 4

      Holy crap! This is by far one of the coolest Linux projects I’ve seen this year. Piping windows? YES PLZ!!! :D

      I have a few quick questions about it:

      • Does it support X applications, or is there some kind of X compatibility layer?
      • How hard is it to port X code to Arcan?
      • I have a poor understanding of the Linux graphics stack - so I’m probably wrong, but if it’s using mesa, that means it could use nvidia drivers too, right?
      1. 1

        So I am quite slow to reply (and notice), but:

        1. it does not currently support X (the protocol) and I don’t think I’ll write a translation layer for the wire format (a will to live and all that) – but there’s more to it. The strategy for ‘compatibility’ is (in order of priority):

          • VM integration (with QEmu and BHyve being my main targets) because I believe with all the mishmash of stuff people depend on from windows, OSX, android, X - it’s the solution with the best bang for the buck, and well within reach to push overhead down to what you pay for the rather scary Xorg stack.

          • SDL2 with some special work-arounds because the model I’m pushing is quite favorable to games – and they do less complicated things when it comes to OS integration (think dependent sub-windows and popups re-layouting and moving around on parent window resize) yet are good performance indicators.

          • Xlib emulation library (don’t agree with the XWayland approach at all, it’s a square peg forcibly pushed through a round hole, but I guess they had to do ‘something’) and Wayland - I’m coding on these two right now but it’s mostly tedium and boiler plate code – and they are competing with cooler things like VR support :-)

        2. Depends a bit on what you are translating, but it’s quite difficult and quite possibly not worth the work outside some edge cases, any specific targets in mind?

        3. the graphics stack is in quite a bit of flux and disarray, and it is really the limiting factor here. While the KMS- (“kernel mode switching, or telling displays on what to draw and how it’s formatted) approach to display control will win and gain adoption outside Linux (BSDs are a priority of mine), the actual model for the second most important part in the chain, "how can GPU-bound resources be allocated and shared between processes” is far from decided. Wayland has quite a few hacks for it that they get away with because of the overlap with Mesa development, but oh boy is it immature and does not blend well with Vulkan. Unfortunately, for every little bit of technical relevant information out there you have to wade through metric tons of manure.

        There is also something of a relevant update in https://arcan-fe.com/2016/09/02/arcan-monthly-september-edition/ and another little plea in https://lists.freebsd.org/pipermail/freebsd-current/2016-September/063222.html - don’t know if it’s anything to consider “newsworthy” so didn’t post)

    2. 2

      This is simply amazing!