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 [off-list ref] wrote:

quoted

On 12/19/2017 02:57 PM, Daniel Vetter wrote:

quoted

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!

quoted

quoted

So
preferrably bootsplash would use kms directly, and use the explict dirtyfb
callback.

Sure, if I'd be hooking into drmcon, that would be great.

But drmcon doesn't exist yet, so it doesn't get us further to talk about a bootsplash on KMS :(

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.

Why do you need a console for a boot splash? You're not drawing
console output afaiui ... And even your current fbdev-based
implementation only interfaces with fbcon insofar as you're making
sure fbcon doesn't wreak your boot splash. Or I'm missing something
somewhere.

Errr... true. I'll answer it below, where you ask again.

quoted

In fact, if I define fbops->flush(), defio drivers can still add their own proper flushing function, so everybody wins. I like that, see below.

tbh I'd forget about ever touching any of the existing fbdev drivers.
Imo just not worth the time investement.

Fair point. It's optional anyway, and can still be done (quickly and painlessly) on demand.

Since my goal here is making a nice bootsplash, I'll touch as few drivers as I can.

quoted

quoted

quoted

So, what shall I do? As it is, the hack is already specific to devices that really, really need it.

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 enable this on).

See Oliver's reply - we have plenty of fb-only systems deployed in the real world. Think Xen. Think AArch64 with efifb. Think any system before the KMS driver is loaded (which is a case that the splash is supposed to handle).

And you need a real pretty boot-splash on those? That sounds all like
servers, and I haven't yet seen a request for real pretty&fast boot
splash for servers.

Yeah, every little helps.

And the vesafb/efifb case is valid for all of the desktop/laptop machines as well.

quoted

Also, where would I hook into KMS, were I to implement it on top of KMS right now? I'm not working on top of FB per se, but on top of fbcon. So in a KMS world I wouldn't work on KMS itself, but on top of... drmcon, which doesn't exist.

Hm, I guess I need to double check again, but I don't get why you need
to sit on top of a console for the boot splash. I mean I understand
that you need to shut up the console when the boot splash is on, but
from a quick look you're not using fbcon to render anything or
otherwise tie into it. Where's the connection?

Fair point.

So the case you're looking at is someone who wants to have a bootsplash, yet doesn't want to have fbcon. Correct?

I agree, this is a case that is not covered with the current code. However such a generic solution would require the definition of new semantics of both fbcon and the bootsplash fighting for the same FB device - well, as long as no graphical application uses it. Urgh... It is a lot simpler to just dual-purpose fbcon, since it knows when to shut up on its own.

And I simply assume that those who load a bootsplash file into their initramfs won't be short a few bytes to compile in fbcon as well.

So... I've hooked into fbcon for simplicity's sake, so I don't have up to three parties fighting for the same device, and so I don't have to define semantics and interfaces to solve that conflict.



Max