lkml.org 
[lkml]   [2017]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote:
> On 12/19/2017 05:02 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt <mstaudt@suse.de> wrote:
> >> On 12/19/2017 02:57 PM, Daniel Vetter wrote:
> >>> The problem is that defio is totally not how a real driver works.
> >>
> >> But they do exist and I can't ignore them.
> >>
> >> I'm afraid I don't understand - why are those, such as xenfb, not real drivers?
> >
> > I mean kms drivers. The problem is that the magic mapping that fbdev
> > expects is real pain. Everyone else, including kms, expects an
> > explicit flush operation. So instead of hacking around even more with
> > the defio corner cases that don't work, I'm suggesting we just add
> > that flush operation. At least internally.
> >
> > Fixing kms drivers to implement a better defio is probably not a
> > reasonable investement of time.
>
> Ah yes, I understand now, you mean that KMS drivers have explicit flush,
> and defio is a hack to retrofit such drivers to an API that never
> supported a flush operation (the fbdev API), but always used to expose
> the video memory directly. Right?
>
> If yes, then I agree. Fixing the defio in the KMS drivers wouldn't even
> solve my problem - I'd still need to implement flush. So might as well
> care about the flush straight away, yep!

Yup.

I'll leave the more fundamental discussion to the other thread on the
cover letter.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

\
 
 \ /
  Last update: 2017-12-20 10:46    [W:0.071 / U:2.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site