On 2019-03-27 10:41 a.m., Daniel Vetter wrote: > On Wed, Mar 27, 2019 at 10:10 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: >> Am 26.03.19 um 15:53 schrieb Daniel Vetter: >>> >>> Looks surprisingly clean, at least from a quick read. Only big thing I >>> noticed on the implementation side is that you probably want to use the >>> simple display helpers. At least that's a much better fit for simple >>> display hw supported by these fbdev drivers. >> >> I thought about using the simple-DRM helpers, but found that a full DRM >> driver would be more helpful for porting over fbdev drivers. Unless >> simple DRM is a hard requirement, I'd prefer to leave it this way. >> >> For those devices that only support a single pipeline, the conversion to >> simple DRM should then be mandatory during the porting process. > > fbdev only supports a single output, all multi-head extensions are > driver specific ioctl hacks. Given that all you can do is switch it on > or off (with a given mode), simple pipe helpers are the perfect fit > for fbdev. > > Some drivers might support more (like multiple heads, or at least > different outputs), and those we should convert over. But at least for > step 1 in converting fbdev drivers over, simple pipe is the right > starting point I think. Converting an fbdev driver to a KMS one loses some features: 1) Dynamically switching modes / colour formats via fbdev. 2) fbcon acceleration (or maybe this can be preserved?). In turn, it allows exposing additional functionality: 3) Multiple outputs via KMS. Is there any benefit in converting a driver without adding 3)? If not, is simple pipe still a good starting point? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
