[prev in list] [next in list] [ prev in thread ] [next in thread] List: kwin Subject: An EGLStreams backend for KWin From: Erik Kurzinger <ekurzinger () nvidia ! com> Date: 2018-11-12 13:43:25 Message-ID: 1594821.KLF6aR3QTc () kz-linux-dev [Download RAW message or body] Hi Everyone, Firstly, I'd take this chance to introduce myself to the KWin development community. My name is Erik Kurzinger and I'm a software engineer with the Linux graphics driver team at NVIDIA. I've contributed a couple small patches to the project before, but would now like to announce our intention of adding a backend for KWin's wayland compositor based on the EGLDevice, EGLOutput, and EGLStream extensions to exist alongside the current GBM implementation. This will allow KWin users on NVIDIA hardware to take full advantage of its wayland support. For anyone unfamiliar with the functionality these extensions provide, I'll briefly summarize it here: EGLDevice provides a way to enumerate native devices and create an EGLDisplay connection from them. EGLOutput then provides a way to access different portions of the display control hardware associated with such devices. For instance, an EGLOutputLayer represents hardware which can accept an image as input and present it to a display device. Finally, an EGLStream provides a notion of frame "producers" and "consumers" and a means to communicate between them. Hence, by attaching an EGLOutputLayer as the consumer of a stream and an EGLSurface as the producer, the compositor would be able to present rendered frames to the screen. Similarly, by attachign a GLTexture as a consumer it could receive frames from a wayland client acting as the producer to be composited into the final desktop image. Because of the abstractions that already exist in KWin's drm code, I believe support for the above can be implemented fairly cleanly and without an ton of modification to what's already there. I've hacked together quick proof-of-concept just to see if I can get an image on the screen and apart from a few issues to iron out related to damage tracking it looks like things are functioning as intended. I'm currently working toward cleaning up this initial implementation and plan on having a set of patches to present to the community in the near future. I just wanted to let everyone know about the endeavor now to see if there were any immediate questions, opinions, issues foreseen, ect. Cheers, Erik ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- [prev in list] [next in list] [ prev in thread ] [next in thread]