concerns over wayland and need for wayland app display to X Server
daniel at fooishbar.org
Mon Feb 27 11:29:46 PST 2012
On 27 February 2012 19:13, David Jackson <djackson452 at gmail.com> wrote:
> mesa? really? I thought that the whole purpose of mesa was to render
> everything that opengl provides in userspace on the CPU. mesa is useful in
> cases where you you dont have a video card with a GPU or any OpenGL
> capabilities, which is what video cards once were.
> This gets at the question I have, how is an application going to actually
> tell the GPU to render a square sized 40x40 at coordinates 30x30 , without
> actually doing this rendering itself and writing it to a video buffer?
> if it cant, all the application can do is use something like mesa to render
> that square itself ion the computers CPU.
> Increasingly it may be desirable to move rendering off the CPU into the GPU
> which means your going to need an OpenGL API for an application to use to
> send OpenGL commands to hardware through a driver.
I really don't want to discourage you - it seems like you're very
enthusiastic - but please do some basic reading on the topics you're
discussing here. I hope this clears up some of your misconceptions:
Mesa has a software rasterisation API, yes, but it has also provided
hardware-accelerated OpenGL drivers for Intel, AMD, NVIDIA, 3dfx, S3,
and many others, for the past 15 years or thereabouts. It provides
the standard OpenGL and OpenGL ES APIs which, as you alluded to
before, are some kind of common driver abstraction.
Most of the existing Wayland clients - as you can see from the
examples today - render with OpenGL ES, using Mesa's
hardware-accelerated drivers, and then pass a buffer ID to Wayland
without the server having to know anything.
Applications are also free to render from the CPU, or whatever. If
they want high-level vector representations, then great, that's up to
GLX is unsuitable for modern applications because it has not been
updated in a very long time, and does not even support GL 2.0.
Wayland is the culmination of many years of work within and including
X11, such as DRM/KMS, pciaccess, Mesa, DRI2, XI2, et al. Adding still
more extensions to X doesn't help after a point - adding a fifth input
API wouldn't help solve the problem that you cannot use
brightness/volume/etc hotkeys while a popup menu is active - because
some issues are fundamentally unfixable with X11. Including many
where the X11 protocol explicitly precludes achieving Wayland's goal
of 'every frame is perfect'.
Applications today do not use X11's rendering primitives, and instead
compose everything to one giant image on the client side and then just
post buffers to the X11 server. Much like Wayland, in fact.
Your suggestion of command-line arguments would not work because the
Wayland library cannot process command-line arguments without the app
asking it to. Even if it could, what you've suggested - a display
system abstraction that lets the application express slightly
higher-order requests about window management, buffer management,
input handling, etc, which then translated them to one or more window
system requests - is in fact a toolkit. This is the basis of GTK, of
Qt, of Firefox and Chromium, etc.
As reiterated earlier, there is already support for displaying on an X
server within the Wayland compositor, and the reverse of having an X
server display X applications within a Wayland session. I also fully
expect remote-display capabilities will be developed for Wayland which
will be a great deal faster than X11, as X11 requires an insane amount
of network bandwidth to use as a bandaid over its complete lack of
client/server/window-manager synchronisation, and also requires a lot
of roundtrips which are extremely expensive and make the performance
of your entire session bound on some very unfortunate multiple of the
I hope this clears things up for you.
More information about the wayland-devel