--- James Simmons <jsimmons@infradead.org> wrote:
No. The penguin code works for fbdev without console support. The logo can
be displayed for embedded fbdev devices so the developer knows it is
loaded.
Could the penguin code do the ioremap in its code? That way if it fails it
isn't fatal. Right now if the fb driver fails to load the penguin code is kind
of pointless.
The client of the framebuffer needs to be responsible for the ioremap(), not
the driver. Since if the buffer is mapped to high mem the client code needs to
match. The current scheme prevents a high mem mapping since the client code
isn't high mem aware.
I also think that it is wrong that the fb drivers should fail to load just
because it can't ioremap() to draw the penguin. It would be much better to have
the fb driver load and the penguin disappear.
quoted
Are there non-cfb drivers? How hard would it be to convert them?
Is there another solution to the problem?
There are several non-cfb drivers. Breaking the code up and pushing it
into the fbconsole layer is a bad idea.
Accelerated driver (non-cfb) don't need to ioremap the framebuffer memory
except for the case of fb_read/fb_write. That can be handled. What should
be done is a surface api that allocates the amount of memory we really
need at any time.
I'm still having trouble with the fb drivers doing the ioremap() when
fbconsole/penguin is the only client. 1600x1200x4 dual head still takes up 16MB
of address space. 16MB will fail ioremap() on my system. Aren't we just
delaying an inevitable problem with increasing resolutions?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf