Re: [Linux-fbdev-devel] Re: [PATCH] fbdev updates.

[James S. <jsi...@tr...>]

> > It is and has started to got into the mainline kernel. The thing was I was
> > bending over backwards to not break peoples drivers.
>
> If it's something small, then driver people don't mind having their
> drivers fixed.
>
> However, if its something large, just break them and let the driver people
> fix up the pieces (assuming you've got adequate documentation either in
> code or elsewhere for people to see both the reasons for the breakage,
> the direction you're heading in, and an example driver to follow.)
> Chances are that they'll know their driver better than anyone else.  If
> it stays broken through the next stable series, then start considering
> dropping the driver.
>
> That's how it works in the other subsystems.

Thinking about it I realized I did the wrong approach. Should I back out
all fbdev driver changes I did or leave some? In this case next week I
will start breaking the upper layer. First to go is the old fbgen code.
Then fields in struct display will start going away. Then get_fix and
stuff will go away.

> (FYI, you'll probably find that most people who didn't use the fbgen layer
> decided not to use it because of the fix <-> par <-> var mess it forced
> into the driver design.)

    I don't like it much either but at the same time I don't want to
break userland. I hate the converting back and forth. I want to make
it better.
    The idea was to make the drivers focused on a par but still generate
a var and fix and update struct fb_info for the upper layer to use. Par is
the main focus and it can be anything. Fix,var and struct fb_info are
only things to generate for the upper layer. We still want some kind of
data struct independent of the driver so we have a common code base for
fbcon. That was the whole idea.