On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote: > > With drmfb you basically have to shadow everything into memory & copy > > over everything, and locks you out of simple 2D accel. For a simple text > > console the result is orders of magnitude slower and memory hungry than > > a simple fbdev. > > Not true, we have full fbdev emulation, and drivers can implement the 2d > accel in there. And a bunch of them do. It's just that most teams decided > that this is pointless waste of their time.j Ok so my knowledge might be outdated here. I was complaining to Dave about how cirrusdrmfb didn't even use blits for fbcon scrolling and always double buffered everything, and Dave made the point that you basically had to do that for security reasons that I mostly forgot the details of. It looks like bochsdrmfb and astdrmfb are the same. If things have changed, then cool. Can you point me to a drmfb driver that is a good (and not too complex) example with simple 2d accel ? I'm thinking mostly of color expansion, bitblt and solid fill for fbcon, the way I used to do it in radeonfb for example. > > At least that was the case last I looked at the DRM stuff with Dave, > > maybe things have changed... > > > > Not everything has a powerful 3D GPU. > > That's correct, and drm can cope. And compared to fbdev there's a very > active community who improves&refactors it every kernel release to make it > even better. Since about 2 years (when atomic landed) we merge new drivers at > a rate of 2-3 per kernel release, and those new drivers get ever simpler > and smaller thanks to all this work. Yeah it's hard to follow from outside :-) As I said above, it would help if you could point to a good modern example driver to use as reference. Thanks ! Cheers, Ben. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
