/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
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-
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
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
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 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
___
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 mailin
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
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 shou
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 t
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.
O
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 wo
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
13 matches
Mail list logo
