On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote: > Yeah, small drivers like these we have piles now, things exploded a lot > after atomic landed two years ago. And they seem to shrink with every > release a bit more (since lots more drivers gives you lots more insight > into what other refactorings would make sense). Those we have a big pile > of, and nowadays (at least with developers expirienced with upstream, but > not necessarily with drm) it takes but a few weeks from initial submission > to getting them merged. > > What we don't yet have a nice tidy example driver of is the even simpler > "dumb framebuffer behind a slow bus with explicit/manual upload", for like > small i2c/spi panels (and conceptually also usb, even though there bw and > panel size are a bit scaled up). We've gained some really nice helpers for > this this year, and there's 3 drivers in-flight to make use of it. But > since that's right now just a hobbyist effort it's moving a bit slower > (and I was mistaken a few weeks back where I assumed that one of them > landed already). What I find usually confusing is the interaction with the TTM and overall fb memory management, when trying to plumb in simple 2d accel to speed up fbcon mostly (but I don't mind making it available to user space via ioctls, though that's not a priority). As I mentioned earlier, probably 1 or 2 years ago, Dave made the argument that shadowing through memory was necessary and precluded 2D accel, though I don't fully remember the root of the argument. If that is indeed not the case, then my main objection is lifted. Cheers, Ben. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
