Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/31/2017 01:53 PM, Alan Cox wrote: > On Tue, 19 Dec 2017 15:07:53 +0100 > Oliver Neukum wrote: > >> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: Would you like me to extend the FB API or not? >>> >>> Yes. Well for real I'd like you to do kms, so

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On Tue, 19 Dec 2017 15:07:53 +0100 Oliver Neukum wrote: > Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: > > > Would you like me to extend the FB API or not? > > > > Yes. Well for real I'd like you to do kms, so maybe you need to explain > > why exactly you

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/20/2017 04:35 PM, Ray Strode wrote: > Hi, > >> Actually, I don't want that :) >> >> This was a design decision that I've made to keep the code small and simple >> to audit. >> As it is, the simple bootsplash code will make 99% of people happy. > You think only 1% of linux users have more

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Hi, > Actually, I don't want that :) > > This was a design decision that I've made to keep the code small and simple > to audit. > As it is, the simple bootsplash code will make 99% of people happy. You think only 1% of linux users have more than one monitor or a 4k screen? > I've made this

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/19/2017 10:01 PM, Ray Strode wrote: > Hi, > > On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote: >> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a >> functional extension of that. It just happens that fbcon sits on top of FB, >> so I >>

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

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: > > Would you like me to extend the FB API or not? > > Yes. Well for real I'd like you to do kms, so maybe you need to explain > why exactly you absolutely have to use fbdev (aka which driver isn't > supported by drm that you want to

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Hi, On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote: > I'm hooking into the in-kernel terminal emulator, because the bootsplash is a > functional extension of that. It just happens that fbcon sits on top of FB, > so I > work with what I get. > > And the console in turn

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/19/2017 05:09 PM, Daniel Vetter wrote: > btw the reason drmcon didn't move is that David Herrmann moved on from > hacking on graphics stuff, and no one needs it. There's nothing > fundamentally wrong with his patches for a basic emergency console on > plain drm, or the simpledrm driver to

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

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

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

btw the reason drmcon didn't move is that David Herrmann moved on from hacking on graphics stuff, and no one needs it. There's nothing fundamentally wrong with his patches for a basic emergency console on plain drm, or the simpledrm driver to get a basic drm framebuffer up on vesafb/efifb and

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt wrote: > On 12/19/2017 02:57 PM, Daniel Vetter wrote: >> Where do drivers deal with struct file deep down? > > As an example, I remembered this to be the case in nouveau's code for > allocating a framebuffer. So I checked, and it's

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/19/2017 02:57 PM, Daniel Vetter wrote: > Where do drivers deal with struct file deep down? As an example, I remembered this to be the case in nouveau's code for allocating a framebuffer. So I checked, and it's much better now. So I was mistaken about this - sorry. Thanks a lot for

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On Tue, Dec 19, 2017 at 02:34:22PM +0100, Max Staudt wrote: > On 12/19/2017 01:23 PM, Daniel Vetter wrote: > > On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote: > >> 2) We need to go out of the way when a graphical application starts, and > >> come back when it's done. fbcon already has

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/19/2017 01:23 PM, Daniel Vetter wrote: > On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote: >> 2) We need to go out of the way when a graphical application starts, and >> come back when it's done. fbcon already has the logic for this, and >> fbcon is also the thing we're trying to

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote: > On 12/13/2017 10:35 PM, Daniel Vetter wrote: > > Using drm directly would allow you to flush the contents without the fake > > (and tbh, really expensive on most drivers) copy op. If you insist on > > using fbdev for this stuff, then at

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/13/2017 10:35 PM, Daniel Vetter wrote: > Using drm directly would allow you to flush the contents without the fake > (and tbh, really expensive on most drivers) copy op. If you insist on > using fbdev for this stuff, then at least add a new hook to flush cpu > rendering. My reasoning is as

[RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Framebuffers with deferred I/O need to be flushed to the screen explicitly, since we use neither the mmap nor the file I/O abstractions that handle this for userspace FB clients. Example: xenfb Some framebuffer drivers implement lazy access to the screen without actually exposing a fbdefio