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

Tue Dec 19 16:09:41 UTC 2017

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 friends. Just wanted to bring this in since you
sound like you're expecting this to magically have happened somehow.
We don't merge code without real use-cases.
-Daniel


On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt <mstaudt at suse.de> 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 much better now.
>
> So I was mistaken about this - sorry.
>
> Thanks a lot for cleaning up this part of DRM, I'm looking forward to a nicer future! Hopefully we can get unify the FB emulation in a single place at some point, but that's just my dreams and is going off-topic, so I'll stop here.
>
>
>> 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?
>
>
>> 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.
>
> And the console in turn happens to work on all FB and KMS drivers, so it makes users of all kinds of drivers happy. In fact, that's why the FB emulation in KMS drivers came to be in the first place, if I remember right - to ensure fbcon continues to work.
>
> Thus, once drmcon exists and becomes dominant over fbcon, moving the bootsplash to it makes sense. On the other hand, hooking into a raw video subsystem doesn't make sense as far as I can see, so a bootsplash on top of raw KMS is just as meaningless as a bootsplash on top of raw FB. So I have no choice but to work on top of fbcon, and thus use the FB subsystem.
>
>
>> But if you insist on using fbdev, then I think the beast course
>> here is to wire up a new fb_ops->flush callback.
>
> Okay, makes sense. Thanks!
>
>
>> Note that you only need to type the 1 trivial implementation for the drm
>> fbdev emulation, as long as the callback is optional. Trying to make defio
>> work correctly, as fbdev assumes it should work, in all cases, on top of
>> drm is imo an entirely pointless endeavour.
>
> I'll look into it.
>
>
>> Yes, so lets ignore defio and do the flushing correctly, at least for kms
>> drivers.
>
> I agree.
>
> 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.
>
>
>>>>> What shall I do?
>>>>>
>>>>> Shall I add a new FB op for flushing when writing to the raw memory from the kernel?
>>>>> As far as I can see, it would be needed for defio drivers only, is that correct?
>>>>
>>>> Yes, which are kinda horrible anyway. I guess you could at least not do
>>>> all these hacks if it's not a defio driver.
>>>
>>> Again, I don't understand.
>>>
>>> In my patch (see below), I explicitly check for info->fbdefio, as well
>>> as three known broken drmfb emulations. I don't do the copy hack on any
>>> other device.
>>
>> Yeah, and if we'd to the explicit flush, you wouldn't even need to check
>> for that. So
>>
>> if (fbops->flush)
>>       fbops->flush(); /* this covers all drm drivers */
>> else if (fb->defio)
>>       copyarea hack, if you really still need to support some defio
>>       fbdev drivers, but really I think that's questionable
>
> I need to support xenfb, thus I might as well support all defio drivers.
>
> Also, I like that your suggestion allows for affected drivers to implement their own, more efficient fbops->flush() directly, while ensuring that those that don't still have a fallback, so there is some performance to be gained.
>
> I'll look into implementing this.
>
>
>> else
>>       ; /* nothing */
>>
>>> 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).
>
> 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.
>
>
>
> Max
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch