Re: [RFC PATCH 0/3] staging: remove fbdev drivers

[Dave Airlie <airlied@gmail.com>]

On 9 December 2016 at 07:28, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> 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.

What are people using fbcon for that needs acceleration, this is where I get
a bit lost.

It's a console, if you aren't sshing into the machine.

It's main purpose should just be for gathering oopses and you've a lot better
chance of getting an oops if you don't have some sketchy gpu accel in the way.

The acceleration that most of the 2D things provide isn't ever that
great, and shadowing is a lot more effective if done properly. It's a feature
that kernel ppl obsess over but I don't get a lot of real world feedback,
(booting 9000 scsi nodes with debug on takes a long time was possibly
something I heard once, and I think we resolved).

Dave.