lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 20 Dec 2017 10:45:28 +0100
From:   Daniel Vetter <>
To:     Max Staudt <>
Cc:     Daniel Vetter <>,
        Bartlomiej Zolnierkiewicz <>,
        Linux Fbdev development list <>,,,
        Oliver Neukum <>,
        Takashi Iwai <>,
        dri-devel <>,
        Linux Kernel Mailing List <>,
        Bero Rosenkränzer 
Subject: Re: [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 <> 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!


I'll leave the more fundamental discussion to the other thread on the
cover letter.
Daniel Vetter
Software Engineer, Intel Corporation

Powered by blists - more mailing lists