Here's a list of pending issues with fbdev (either upstream or in the
fbdev bk treee), I figured posting it here may help getting more people
on those issues as my time is sparse and I suppose James too.

A bit. I managed to create the first crack at the ioremap problem with 
machines with lots of memory. Had some problems tho.
 

 - First one, I will deal with, just writing it for completeness: When
switching from KD_GRAPHICS to KD_TEXT (either same console changing mode
or switching to a different console), we need a callback so the fbdev
has a chance to restore the accel engine setting (or even the whole
mode, to be safe).

This is a big problem. It's been around since the beginning of time. Also 
we have the case of fbdev/vgacon systems. Alot fo work has to be done 
here.

 - Memory corruption problems. There is still at least one identified
when using stty. Just use crazy values, like flipping rows & cols (like
stty rows 132 cols 30) and usually, you'll see the box blow up very soon
with heavy memory corruption.

Ug. I have to hunt down this problem.

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully working
with vi.

Also been around for ever. I think that will be a much easier fix.

 - Back buffer problem: maybe related to the logo ? After boot, doing
shift-pageup to go back to the boot message, usually you get crap
displayed at various places.

strange. I don't have that problem on my systems.

 - On x86, various junk displayed when the fbdev takes over. Reported
by radeonfb users, I couldn't test myself, I don't have an x86 with
radeon at hand for the moment. Apparently, the takeover from vgacon
doesn't properly "convert" the previous VGA text buffer content

I have to try that one out. I know I haven't seen the problem if you
have a fbdev driver and fbcon modular and load them. 
 

 - stty & mode picking. Currently, fbcon_resize() (called when stty is
used to resize the console) will hack a "var" strcture by just putting
new width/height in it and pass that to set_var. The way the various
drivers react to that mostly broken "var" structure is rather random.
We need to explicitely differenciate between a mode that is "complete"
(like what fbset or X passes down the fbdev) or a mode that is just
width/height and eventually a hint of frequency, like what fbcon passes
in this case. I added FB_ACTIVATE_FIND for that purpose, but that needs
better driver support to "pick" up a proper mode. The algorithm for
that isn't trivial. Could be moved to common code.

I think we should do better validating of the var passed in. This also 
needs a bit of work. 

 - fbset doesn't resize the console. I consider that a regression from
2.4. I have some code based on the notification mecanism to address
that, but it tends to trigger the same memory corruption problem as
reported with stty & bogus coordinates. There is something hairy going
on with console resizes. That code is a bit foreign to me though.

I had problems as well. I will have to work on it. 

Other problems have to deal with multiheaded system. Fbcon is multihead 
safe. Alot of gloabl variables that are shared with different framebuffers.
Also the mapping at boot time is really broke. That laso has had problems 
for ages :-(