D18570: EGLStream DRM Backend Initial Implementation
Roman Gilg <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kwin |
|---|---|
| Message-ID | <[email protected]> |
romangg added a comment. In D18570#412443 <https://phabricator.kde.org/D18570#412443>, @ekurzinger wrote: > In D18570#408853 <https://phabricator.kde.org/D18570#408853>, @romangg wrote: > > > First off: a driver not supporting Atomic Mode Setting is nothing modern. Does Nvidia has a plan to improve in this regard? > > > > I'm really not happy, that the `DrmOutput::present` is not run and we have to export these internals from DrmOutput to the EglStreamBackend, which replaces the flip with an EGL function call. Why does the Nvidia driver not integrate with the libdrm API in regards to page flipping? It should be possible to at least offer a wrapper around it or not? > > > Well, our DRM-KMS driver technically does support atomic modesetting, however currently we only allow the presentation of GPU-accessible buffers through the EGLDevice / EGLOutput extensions. In fact, these use atomic modesetting capabilities in their implementation. As far as I know this will remain the case until work on the Unix device memory allocation library is complete and while this is still on the table it's a ways off yet. The new backend really just uses DrmOutputs to track whether a page flip is pending. If we don't want to expose these internals, an alternative might be to track this separately from DrmOutput::m_pageFlipPending and maybe install a different page flip handler when using EGL streams that would just clear this flag (and re-start the compositor). I'll see if I can get something like that thrown together, it might be a bit cleaner, actually. In this case it seems better to me to not write the EGLStreams support directly into the DRM Backend at all, but create a new EGLStream Backend on same level as DRM Backend. This would separate the code better. When at some point a generic Unix device memory allocation library comes along we can then write this one into the DRM backend. What is actually needed from the DRM Backend? If currently the DrmOutputs are only used for tracking page flips, this could be done in some minimal EglStreamBackend and EglStreamOutput classes inheriting Platform and AbstractOutput. Or maybe EGLStreams provides a signal for that as well through EGL extension such that the DRM device does not even have to be opened directly by KWin as done in `DrmBackend::openDrm`? There is some other functionality in DrmBackend and DrmOutput, that it would need to replicate, or better directly move it to a higher abstraction level, since it does belong here and not in the DRM backend code (for example `DrmBackend::m_dpmsFilter` of type DpmsInputEventFilter class, large parts of `DrmOutput::transform` and `DrmOutput::automaticRotation`). REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D18570 To: ekurzinger, davidedmundson, graesslin, #kwin, romangg Cc: wchilders, ognarb, abrahams, schernikov, guilhermesi, fredrik, cfeck, rapiteanu, romangg, hein, nicolasfella, zzag, kwin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart