x11/GLX/GL on top of wayland
Hi, I quickly saw that there is a effort to put xorg on wayland, which is the correct migration path. My concern is, it seems, to be limited to basic x11. What about xorg/GLX/GL on top of wayland? regards, -- Sylvain BERTRAND ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: x11/GLX/GL on top of wayland
On Fri, Jul 04, 2014 at 03:14:43PM +0200, Kalrish Bäakjen wrote: If I have understood you correctly, GLX (the means for setting up an OpenGL context under X) will interact with the XWayland instance, which will then, in turn, interact with the Wayland compositor, giving it the image rendered by its client. So, AFAIK, legacy applications that use GLX should work fine with XWayland - unless, of course, they use X-specific paths. Was that what you were referring to? Yes. But legacy apps could use X-specific paths since then would see only x11. I'm takling about a full xorg/GLX/GL driver stack on wayland. The driver would not be an hardware driver... but a wayland compositor driver. My guess is the current implementation gives basic x11 support. I was wondering about a full GLX/GL stack as well. Coze steam is arriving on gnu/linux hardcore, and that with many closed source games which will be sticking, probably, to x11/GLX/xorg. (Open source games or closed source games using open source middleware will be able to do a native wayland switch though). -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: x11/GLX/GL on top of wayland
On Fri, Jul 04, 2014 at 09:48:20AM -0400, Jasper St. Pierre wrote: Xwayland has DRI3/Present support, which means that any app that uses DRI3 will work fine under it. Right now, this is the Intel driver, with support for the other FOSS drivers coming soon. Otherwise, we fall back to non-hardware-accelerated codepaths. It won't break, but it will mean that you won't get hardware-accelerated rendering. This is good news. I need just a bit more of your lights on the matter: the wayland dri3 driver is intel specific. You mean that it needs hw specific paths? The mapping of xorg/glx/GL calls into wayland/egl/gl must inclue hw specifities? -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: x11/GLX/GL on top of wayland
On Fri, Jul 04, 2014 at 10:31:53AM -0400, Jasper St. Pierre wrote: It's at a lower level than translating GLX to EGL. The client renders into specific card-buffers given its hardware-specific drivers inside mesa, and then passes a handle to those buffers to what it thinks is the X server using the DRI3 protocol. Xwayland can in turn pass those buffers to the real Wayland compositor using the secret wl_drm interface. I'm told that the nouveau and radeon drivers now have support for DRI3 as of last week. Ok then. I guess I'll dig in dri3/wayland support in mesa. Good news to know that the migration path from x11/GLX/GL to wayland/EGL/GL is nearly there! best regards, -- Sylvain BERTRAND ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [libinput] AC_PROG_CXX missing in libinput/configure.ac
On Mon, Mar 31, 2014 at 08:08:32AM +1000, Peter Hutterer wrote: note that the only binary that needs a C++ compiler is the C++ build test. the library itself only needs a C compiler. A good thing, would be to compile the lib with tinycc and/or open64 to kind of be sure it's not hard dependent on gcc. -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [libinput] AC_PROG_CXX missing in libinput/configure.ac
On Sat, Mar 29, 2014 at 06:59:12PM +0100, Jonas Ådahl wrote: Yes, for now at least. Sad. But till there is no crazy code generator, it should be easy to write a makefile/shell script to by-pass the autotools and build the lib. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [libinput] AC_PROG_CXX missing in libinput/configure.ac
On Sat, Mar 29, 2014 at 02:44:13PM +0100, Jonas Ådahl wrote: Ah, thats unfortunate. I pushed a commit that unconditionally invokes A_PROG_CXX now. Thanks for the report. Does it mean a c++ compiler is now mandatory in any case? regards, -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: surface buffer cardinality and outputs
On Mon, Mar 18, 2013 at 03:55:03AM +0100, Sylvain BERTRAND wrote: But I'm still kind of uncomfortable to hand over to the compositor scaling in the case of fullscreen and buffer transform in the case of output tilting (renaming transform to tilting would not be a bad idea). Oops! Of course, if the output is tilted, the compositor must tilt the scanned out part of the buffer itself. The client knowns its surface is scanned out on a tilted output. In the case the surface spans over several outputs, it is in charge to find the best tradeoff to configure its rendering for all outputs, and that in one buffer. -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] add a shutdown event
On Sun, Mar 17, 2013 at 11:32:21PM +0100, Hardening wrote: This patch adds a shutdow event so that clients can be notified when the compositor is about to exit (and potentially kill its child processes). This patch is based on gh next. Is the socket disconnect not enough information for the clients? -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: surface buffer cardinality and outputs
Hi again, I put some more thoughts in those issues. A client knows on which outputs its surfaces span over. Then the client is in charge of configuring its rendering to find the best trade off, but with one buffer. If the surface was entered on 2 outputs with really different DPIs... well it should configure its rendering based on the average of output DPIs? The user would move/resize the surface on one output if he wants to get a GUI rendered properly again. For the double buffered flow and very long page flips that could be induced for a surface spanning over several outputs... well too bad for the surface and the client. Regarding a discret vs continuous compositor space. If we accept the previous tradeoffs, a dynamic continuous compositor space is fine. But I'm still kind of uncomfortable to hand over to the compositor scaling in the case of fullscreen and buffer transform in the case of output tilting (renaming transform to tilting would not be a bad idea). Another though which targets sub-surface interfaces: are the hardware overlays for YUV buffers that more energy efficient than GPU scaling/color space conversion since most the energy would be burned into the video decoding anyway? thanks. -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: surface buffer cardinality and outputs
It seems there is also an issue with the double buffered flow, namely to make it work cleanly in a the case of a surface spanning several outputs, those of course not in sync and with different refresh rates. Better not be in a hurry to do a page flip on a surface which covers several outputs. On Thu, Mar 14, 2013 at 06:01:10PM +0100, John Kåre Alsaker wrote: ... Anyway I do prefer the one workspace per output approach where you can't see these race issues at all :) I do agree, then: The idea of a discret 2D dynamic matrix of stacks of outputs instead of a continous compositor space is, in my opinon, a model closer to what we would see in the reality. I picture a 2D matrix with slots. Pointer navigation over this matrix of slots should be quite straight forward. Clone use case: in a slot you would have a stack of outputs, but one master and all the others degraded clones, namely scaled copies of the master. The clients would only care of rendering in the master output of a slot. The compositor would take in charge the copy/scaling of the master to the clones since the compositor would be granted scaling powers in that case. Then clones do not exist for the clients. As we agreed before and for what was said about that matter, a surface would belong to and be rendered on one output only (master of a slot in the 2D matrix). The pointer navigation would need a motion that would be enhanced with the slot information since we aren't anymore in a continuous compositor space. Additionnaly, a client should be able to target a specific slot/master output for surface creation, or let a compositor policy decides the slot/master output then be told about it. The shell part/decorations of the surface should be able to detect a drag which crosses a slot/master output boundary and then should do the jump to the new slot/master output, if it wants to. All that means a massive refurbishment of the protocol in many areas. A last note on fullscreen scaling. Scaling, in that case, targets master output/slot which should not be handed to the compositor and rendered only by the clients (using hardware or not). Thanks. -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
surface buffer cardinality and outputs
Hi, The protocol does allow several outputs in the compositor space but does not allow a client to render a surface based on output properties (dpi,subpixel,frame buffer pixel format...) since you can attach only one buffer to a surface. If wayland wants to give a client the ability to render its surfaces in regards of the properties of the outputs, the protocol should be modified to take into account that a client may have to render a surface differently for each output. It may have a don't care about output properties mode which would force the use of one buffer for all outputs. On the other hand, if wayland does not want to let the client render a buffer specific to the properties of each output, the output object should not expose any of its properties to clients. In another words, to give the subpixel format of an output to client and not supporting rendering per output would be inconsistent. How does we cleanly fix this, or did I miss something? -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: surface buffer cardinality and outputs
Well, if a toolkit wants to render the same GUI on outputs of differents properties (those properties significant for actual rendering), they will have to render several times, no other choice to do things properly. The other option would be to ignore those output properties, and the compositor would manage something with an output agnostic buffer. In that case, we would remove the subpixel property from the output to stay consistent (mode is used for shell surface fullscreen). Your proposal is middle ground: a set of buffers, and some heuristics applied on their properties to combine those in the compositor space. For simplicity, I dare to think one buffer for one output is quite clear cut and easier to deal with. Of course, there is also the brutal way: output becomes a singleton, keeps its properties to let the toolkit render properly (hopefully that would be significant), namely we would drop support of several outputs. -- Sylvain ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
