On Fri, Jul 05, 2002 at 12:32:57PM -0700, James Simmons wrote:
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.
(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.)
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf
quoted
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.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf