Re: radeonfb & fbdev code status

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sun, 2003-11-16 at 07:51, Jordan Benjamin wrote:
> Hi, I'm very confused about the current status of these projects and I 
> was hoping someone might be able to clarify. First, is Benjamin 
> Herrenschmidt the author or maintainer of the radeonfb driver? What is 
> the relationship between that code and the fbdev.diff files distributed 
> by James Simmons? I've asked him about this already but he never 
> responded.

The author of radeonfb is Ani Joshi.

I took over maintainership of the 2.4 version a while ago and did
the initial port to 2.6. Lately, I've been working on a new version
significantly improved, though not completely ready to replace the
old one yet.

> What about the fbdev patches? Where do they come from? What are they? 
> Should they apply to any kernel version, and if not, how do you tell 
> which ones?

James Simmons maintains the core fbdev & fbcon, those patches are
the updates from his devel. tree, including some of the driver updates
sent to him by the various drivers maintainers, or things he did
himself. I beleive his latest patches contain a recent version of
my new radeonfb as well.

> I'm asking because I have an IBM ThinkPad T40 with a Radeon Mobility 
> 9000 card on which I'm running linux. I have a dream of one day having 
> accelerated 3d graphics, suspend/resume, refresh rate >50Hz, and 
> console resolution greater than 640x480, perhaps even the native 
> resolution of 1400x1050, all working at the same time. I can get the 
> first two by using vesafb; I haven't had time to invest in the refresh 
> rate yet, and so far it appears that vesafb won't support hi-res 
> consoles. The radeonfb drivers I've tried don't allow the use of 
> suspend/resume.

You should be able to get most of this with the new radeonfb (let me
know if that doesn't work), _except_ maybe the suspend/resume. What
happens on x86 laptops regarding suspend/resume is not very clear,
depending on if you are doing ACPI or APM suspend for example, and
in some case, the only solution is to actually reboot the chip from
scratch, which we cannot do, at least not with the current scheme.

Since it works with vesafb, I suppose your BIOS is taking care of
restoring the chip, so the problem may either be the radeonfb resume
code not properly restoring its own graphic setup, or the BIOS beeing
shoked by some of the settings changes done by radeonfb. It may be
worth trying to restore the initial state of the chip when suspending,
I'll investigate that.

First, try to get the new driver working and let me know of any
problem beside suspend/resume. Then, we'll see if we can get something
working for suspend/resume as well.

> I apologize if I sound frustrated, but it almost seems like the 
> framebuffer code development is occurring in secret. I've tried to find 
> information on the web and the list archives, but I've not been 
> successful. Messages from James Simmons on this and the kernel lists 
> have made reference to, e.g, "Ben's new driver," which I guessed might 
> be Benjamin Herrenschmidt, but his web page makes no reference to 
> anything other than LinuxPPC.

Well, radeonfb has been a fairly critical piece for the PowerMacs for
quite a while now, I only recently started caring myself about non
PPC machines when I took over the maintainership of the driver, I'm
not always fully aware of all the issues that plague the x86
platform unfortunately...

Ben.



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl