The issue is putc[s]. Th eothers could be done pretty easy. The question
is do we want to use fbcon for text modes. Fbcon is so big and heavy for
text mode. The /dev/fb interface in this case also doesn't make sense.
> Removed support for hardware cursor. Generic cursor code has enough
> troubles as is, in software mode.
I have patches that explain the new cursor api. Right now I'm recovering
from being sick so I haven't worked on fixes.
> No reasonable fbset support... It is especially annoying on multihead
> system, as 'stty cols XXX rows YYY' does not change pixclock...
Look at fbmon.c. There are functions that can generate reasonable values.
Personally I like to see tha ability to set the pixclock via sysfs.
The truth is that I never had go luck with that functionality. Many
drivers would freak out when I switched modes.
> Removed fastfont support. No way for it with current API.
Its there but I haven't implemented it yet, struct pixmap. In this case
struct pixmap would be a static map not a dynamic map as it is currently.
We can fix that one together.
> (Mis) Features inherited from generic fbdev API:
> Cursor on other framebuffers than primary one does not blink.
Each framebuffer will need a indepenednt timer.
> Contents of visible, but not foreground, display is not updated.
Ah the broken console system. Blanking is the same way. When the console
system blank all VTs blank. I will be working on my VGA/MDA system and
then all the sudden both console go blank. This will take some magic to do
without touching the core console code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/