On 04/29/2013 04:04 PM, Arnd Bergmann wrote: > On Monday 29 April 2013, Laurent Pinchart wrote: >> On Monday 29 April 2013 23:31:30 Tomasz Figa wrote: >> >>> Good point. Stephen, would it be a problem to make this a KMS driver >>> instead? Old fbdev API could be emulated on top of it, until it goes out >>> of use, couldn't it? >> >> There's already an fbdev emulation layer in KMS, for such a simple use case it >> will work fine. > > I suggested the same to Stephen when he first brought up this driver. > Unfortunately his attempt to create a simple KMS driver resulted in a > significantly larger driver than the one he did for the framebuffer > interface. This means that either Stephen did something really wrong > in his attempt, or the KMS interface isn't as good as it should be > if we want to move people away from frame buffer drivers. Well, I didn't actually attempt to write the KMS driver; I simply took a look at existing KMS drivers (and perhaps some stub KMS driver; I forget right now) to see what it'd take, and it looked quite scary. The other issue is that the KMS semantics appear to desire that the driver allocate FB memory from some pool, and then point the display scanout at the allocated memory. However, this driver's semantics are that some other entity has allocated and reserved some memory region for scanout, and the simple FB driver exists solely to scribble to that memory region. Rob Clark said the thought this could be handled by writing a custom memory allocator to support this, but it seemed a little pointless to write a whole memory allocator when the existing FB interface allows the driver to just set a struct member to the address and be done with it. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
