On 30/12/15 11:31, Sebastian Frias wrote: > Hi, > > On 12/30/2015 09:06 AM, Tomi Valkeinen wrote: >> >> Also note that I don't want new fbdev drivers into the mainline kernel. >> You should implement a DRM based driver instead. >> > > Thanks, is there a porting guide to go from fbdev to DRM? I don't think you should "port" the driver from fbdev to DRM, as the frameworks are just so different. You should implement the driver from scratch. Of course, the bits of code that actually touch the hardware can possibly be copied directly. Kernel docs contain documentation about DRM, but I don't know if there's really a "how to write a DRM driver" style documentation. There's an active mailing list and irc channel, though. > Does DRM provides a "fbdev" backward compatible API? Would that be > feasible? DRM provides an fbdev "emulation". I think it's mainly aimed at providing fb console, but many fbdev applications should work fine on top of it. > I did not find much about that. > > Currently our stack is something like: > > Qt -> eglfs -> Mali -> fbdev -> mem -> output > (HW) (HW) > > We don't control the eglfs/Mali (GPU) part. > From what I could see, Mali uses DRM with X11 which we do not need > (note: I'm not a Mali expert and just took a quick look at the code so I > may be wrong), which could be a problem. I'm not familiar with Mali, so I have no idea. > If "implement a DRM driver" is a lot of work, it would end up as a > business decision and probably would not happen. True. It's, of course, up to you. If the fbdev driver works fine for you and provides all the features, and you're happy with it, and there's no requirement to get the driver to the mainline Linux, there's not much point in going for a DRM driver. > Would you say there are good solid arguments to shake our current stack > (other than for dusting it off)? Fbdev is the legacy framework, hopefully deprecated at some point, and DRM is the current display framework. So DRM has much more features, is actively developed, has a community that may help you with your issues, etc. From purely technical point of view, it depends on the hardware in question. If the HW supports hardware overlays and multiple outputs, DRM supports those fully, whereas fbdev does not. I'm not that familiar with the 3D side, but I think that can be implemented properly with DRM, whereas on fbdev supporting 3D is always more or less a hack. > By the way, does DRM improves 2D acceleration support over fbdev? I don't know enough about 2D acceleration to answer that. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
