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 follows:
1) The splash screen is meant to appear as early as possible in the boot process, and even on devices that don't have a DRM driver. For example, an ARM box with only efifb. Thus, the choice to work on top of FB.
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 hide. So it seems natural to add the splash on top of fbcon - at least for now.
3) I can't use DRM from the kernel, for the same reason for which there is no "drmcon" to supplant fbcon: There is no interface to reserve framebuffer memory from kernel space: To get memory for a framebuffer, one needs to have a struct file that is passed through the DRM stack down into the drivers.
If this interface existed, then there could be a generic "fb2drm" translation layer, and we would no longer need FB compatibility code in each KMS driver. Actually, I tried to implement this translation layer a year ago, and hit too many walls.
I've prepared the code for a future in which fbdev no longer exists: My sysfs interface is generically called "bootsplash", in the hope that it will one day move on top of KMS. The hooks into fbcon are minimal and the code is straightforward to port to KMS operations rather than FB. But that's for another day, as far as I can see.
4) I don't fully understand what you'd like me to do. Last time I tried to add a new entry to the fbops struct (namely fb_open_adj_file()), you told me not to touch the framebuffer subsystem anymore, as it is meant to die and driver developers shall use KMS instead. Have I misunderstood?
Something like fb->flush() to finish kernel space accesses would be nice to have, but would need to be implemented for all affected drivers separately. The copy op hack is ugly, but solves the problem generically.
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?
>> + *
>> + * A few DRM drivers' FB implementations are broken by not using
>> + * deferred_io when they really should - we match on the known
>> + * bad ones manually for now.
>> + */
>> + if (info->fbdefio
>> + || !strcmp(info->fix.id, "astdrmfb")
>> + || !strcmp(info->fix.id, "cirrusdrmfb")
>> + || !strcmp(info->fix.id, "mgadrmfb")) {
>
> We have a shared defio implementation now in drm_fb_helper.c, there's not
> really many excuses to not fix up these drivers to just use those ...
I'll look into it.
Thanks!
Max
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
