no need to change the type. It's still a DrmBuffer*

same here

shouldn't we move that into the HAVE_GBM part?

maybe ifdef the complete DrmSurfaceBuffer based on HAVE_GBM? Might simplify the ifdef logic in other areas.

Or: move the DrmSurfaceBuffer into a dedicated .h and .cpp file and only include the .cpp if we have gbm. Then we don't need any ifdefs at all.

why change here? From what I see only the DrmBuffer API is used, isn't it?

What happens in the other case? Does it fallback to QPainter when Platform::createOpenGLBackend() is called?

The cursor is always a dumb buffer. So I'm not really seeing the advantage of using the abstract type (using DrmDumbBuffer in contrast gives this information directly to the reader). Also in showCursor(..) we call the function DrmDumbBuffer::handle() only known to DrmDumbBuffer. So we would either need to define this function also in DrmBuffer or do a dynamic_cast in showCursor(..).

See my comment https://phabricator.kde.org/D4026#inline-16024

handle() is not known to DrmBuffer right now, because it's not needed for a DrmSurfaceBuffer. Also doesn't it make more sense to specify the argument as much as possible so it's easier to read the code? A cursor buffer is always a dumb buffer.

it more or less terminates. Without the else part calls the Platform default impl which returns a nullptr. If createOpenGLBackend returns a nullptr, the Scene cannot be created which means compositing is not possible and KWin terminates.