Weston DRM Compositor Support Proposed For NVIDIA's TK1

[kalrish]

Thanks for the answer Smitty.
But, when you mean "Wayland backend" you mean the compositor, right?
If so, NVidia would have to provide the nvidia-mutter-wayland, nvidia-efl-compositor, nvidia-kwin-compositor and so on?
And what about the optimus systems? It's up to the wayland client to choose the kms compositor or the nvidia compositor?
Im a bit confuse...

Yes, he probably meant the Weston compositor. Wayland, by itself, is a protocol "for a compositor to talk to its clients", unrelated to OpenGL, EGL, DRM,... With Wayland, a client tells the compositor where is its buffer, and the compositor then puts it on the screen as convenient. The compositor, of course, must be able to access the buffer, which means that, if the client uses OpenGL, the compositor has to know how to handle OpenGL buffers.

And, yes. I guess that's why it isn't so "trivial" for the propietary drivers to support Wayland: they would either have to develop a backend for each compositor that supported their own private modesetting API, or switch to DRM/KMS. The later option, however, is not feasible, because of licenses, I think.

About your last question, I think you have confused the "platform" on which the compositor runs (DRM/KMS, Wayland, X11, propietary-modesetting-APIs,...), which is related to where the compositor's output is displayed and how the compositor takes input, and the GPU renderer that's used by clients. Optimus systems have two GPUs, and the ability to compute graphics with any of them in a per-application basis - for now, the user has to set an environment variable for the application to tell Mesa which GPU to use. A client could use any GPU to render its graphics; it would be up to the compositor to display its buffer on screen, using whatever means it had (DRM/KMS, Wayland, X11,...).

[miskol]

nVidia K1 has openmax api

How about MPG or H.264 acceleration on this box? E.g. VDPAU

nVidia K1 has openMAX api
with working gstreamer
As far as I know VLC support openMAX too

[rxonda]

Yes, he probably meant the Weston compositor. Wayland, by itself, is a protocol "for a compositor to talk to its clients", unrelated to OpenGL, EGL, DRM,... With Wayland, a client tells the compositor where is its buffer, and the compositor then puts it on the screen as convenient. The compositor, of course, must be able to access the buffer, which means that, if the client uses OpenGL, the compositor has to know how to handle OpenGL buffers.

And, yes. I guess that's why it isn't so "trivial" for the propietary drivers to support Wayland: they would either have to develop a backend for each compositor that supported their own private modesetting API, or switch to DRM/KMS. The later option, however, is not feasible, because of licenses, I think.

About your last question, I think you have confused the "platform" on which the compositor runs (DRM/KMS, Wayland, X11, propietary-modesetting-APIs,...), which is related to where the compositor's output is displayed and how the compositor takes input, and the GPU renderer that's used by clients. Optimus systems have two GPUs, and the ability to compute graphics with any of them in a per-application basis - for now, the user has to set an environment variable for the application to tell Mesa which GPU to use. A client could use any GPU to render its graphics; it would be up to the compositor to display its buffer on screen, using whatever means it had (DRM/KMS, Wayland, X11,...).

Thanks again Kalrish,
I always forgot that you have a device for produce the framebuffer's content and a device to decode and output the framebuffer's content to the screen itself.
So, Wayland's clients can talk EGL to the NVidia's proprietary blob to produce the framebuffer's content, but clients can't tell wayland to use NVidia's blob to output that framebuffer.

[kalrish]

Thanks again Kalrish,
I always forgot that you have a device for produce the framebuffer's content and a device to decode and output the framebuffer's content to the screen itself.
So, Wayland's clients can talk EGL to the NVidia's proprietary blob to produce the framebuffer's content, but clients can't tell wayland to use NVidia's blob to output that framebuffer.

Well, applications (both X11 and Wayland clients) can't choose which EGL/OpenGL implementation they get; that's outside their scope. For instance, with Mesa, to choose an OpenGL renderer, the DRI_PRIME environment variable has to be set.

DRI_PRIME=1 very-heavy-game # render graphics with provider #1, which is more powerful

About your last question, if you're referring to changing the output of the compositor, there exists or is in its way a protocol called wl_randr or weston_randr, whose purpose is to allow changing monitor configuration (resolution, multi-monitor setups,...). However, if you're talking about switching the output, that is, changing from, say, being an X11 window to a Wayland surface, I think it isn't possible.

The example clients in the Weston tree are wells of information, so, if you know C, you could find some answers by hacking with Wayland.

[rxonda]

Well, applications (both X11 and Wayland clients) can't choose which EGL/OpenGL implementation they get; that's outside their scope. For instance, with Mesa, to choose an OpenGL renderer, the DRI_PRIME environment variable has to be set.

DRI_PRIME=1 very-heavy-game # render graphics with provider #1, which is more powerful

About your last question, if you're referring to changing the output of the compositor, there exists or is in its way a protocol called wl_randr or weston_randr, whose purpose is to allow changing monitor configuration (resolution, multi-monitor setups,...). However, if you're talking about switching the output, that is, changing from, say, being an X11 window to a Wayland surface, I think it isn't possible.

The example clients in the Weston tree are wells of information, so, if you know C, you could find some answers by hacking with Wayland.

Thanks Kalrish,
I will do that.