Attached is a patch against 2.5.54 in an attempt to add putcs() and
setfont() methods for fbdev drivers that require them:
...
struct fb_char {
__u32 dx; /* where to place chars, in pixels */
__u32 dy; /* where to place chars, in scanline */
__u32 len; /* number of characters */
__u32 fg_color;
__u32 bg_color;
__u32 *data; /* array of indices to fontdata */
};
struct fb_fontdata {
__u32 width; /* font width */
__u32 height; /* font height */
__u32 len; /* number of characters */
__u8 *data; /* character map */
};
...
/* upload character map */
int (*fb_setfont)(struct fb_info *info, const struct fb_fontdata
*font);
/* write characters */
int (*fb_putcs)(struct fb_info *info, const struct fb_char *chars);
fb_setfont() uploads the character map to fbdev and makes it the current
map
fb_putcs() writes characters to display
I also did some rudimentary testing by adding test hooks to various
fbdev drivers but haven't examined its full effects (ie, different
character maps per console).
Tony
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
@@ -295,6 +295,23 @@structfb_cmapcmap;/* color map info */};+structfb_char{+__u32dx;/* where to place chars, in pixels */+__u32dy;/* where to place chars, in scanline */+__u32len;/* number of characters */+__u32fg_color;+__u32bg_color;+__u32*data;/* array of indices to fontdata */+};++structfb_fontdata{+__u32width;/* font width */+__u32height;/* font height */+__u32len;/* number of characters */+__u8*data;/* character map */+};++/**hardwarecursorcontrol*/
@@ -375,6 +392,10 @@unsignedlongarg,structfb_info*info);/* perform fb specific mmap */int(*fb_mmap)(structfb_info*info,structfile*file,structvm_area_struct*vma);+/* upload character map */+int(*fb_setfont)(structfb_info*info,conststructfb_fontdata*font);+/* write characters */+int(*fb_putcs)(structfb_info*info,conststructfb_char*chars);};structfb_info{
From: Antonino Daplas <redacted>
Date: Sat, Jan 04, 2003 at 05:25:14PM +0800
Attached is a patch against 2.5.54 in an attempt to add putcs() and
setfont() methods for fbdev drivers that require them:
And those drivers would be the matrox framebuffer drivers, for example?
That would be really great!
Thanks,
Jurriaan
--
Me I'm just like you
I don't have a clue
Shotgun Messiah - Nobody's Home
GNU/Linux 2.5.53 SMP/ReiserFS 2x2752 bogomips 7 users load av: 2.24 1.99 1.56
From: James Simmons <hidden> Date: 2003-01-04 21:00:17
quoted
Attached is a patch against 2.5.54 in an attempt to add putcs() and
setfont() methods for fbdev drivers that require them:
And those drivers would be the matrox framebuffer drivers, for example?
That would be really great!
I'm porting this driver to the new api. I'm alomst finished with the
nvidia driver. Once I'm done on that the matrox driver is next. Sorry it
is taking so long but I have alot of drivers to deal with.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Petr Vandrovec <hidden> Date: 2003-01-04 20:33:41
On Sat, Jan 04, 2003 at 05:25:14PM +0800, Antonino Daplas wrote:
Attached is a patch against 2.5.54 in an attempt to add putcs() and
setfont() methods for fbdev drivers that require them:
Looks good.
...
struct fb_char {
__u32 dx; /* where to place chars, in pixels */
__u32 dy; /* where to place chars, in scanline */
These two are questionable. I do not know what DaveM will need, but
I'll be happier with character coordinates for text mode. So for me it is
just question whether I'll do divide by width/height stored from setfont
in text mode, or multiply when in graphics mode. So I must remember
character cell size in any case. But having multiply in matroxfb could
save multiply here in generic code.
I have strong feeling that doing multiply in generic code, and then divide
in fbdev driver is waste of time, but if Dave is happier with pixel
coordinates, I can definitely live with it.
__u32 len; /* number of characters */
__u32 fg_color;
__u32 bg_color;
__u32 *data; /* array of indices to fontdata */
};
struct fb_fontdata {
__u32 width; /* font width */
__u32 height; /* font height */
__u32 len; /* number of characters */
__u8 *data; /* character map */
};
...
/* upload character map */
int (*fb_setfont)(struct fb_info *info, const struct fb_fontdata
*font);
/* write characters */
int (*fb_putcs)(struct fb_info *info, const struct fb_char *chars);
It would be nice to have old accel_putcs() available for modules, so driver
could decide on case-by-case basis whether it will use its own code or
generic without touching pointer (without modifying potentially constant
fb_ops structure common to all fbdev instances).
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
From: James Simmons <hidden> Date: 2003-01-04 21:03:54
I'll be happier with character coordinates for text mode.
Yuck!! Using fbcon for text modes is just bloat. For hardware text mode it
is much better to write a nice small console driver like newport_con.c
could decide on case-by-case basis whether it will use its own code or
generic without touching pointer (without modifying potentially constant
fb_ops structure common to all fbdev instances).
The patch was rejected. I working on your driver. I can throw in a text
mode driver as well.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Petr Vandrovec <hidden> Date: 2003-01-04 23:09:39
On Sat, Jan 04, 2003 at 09:12:24PM +0000, James Simmons wrote:
quoted
I'll be happier with character coordinates for text mode.
Yuck!! Using fbcon for text modes is just bloat. For hardware text mode it
is much better to write a nice small console driver like newport_con.c
When I said before christmas that I'll have to write matroxcon to get
reasonable functionality, you laughed... Now, it is clear that there is
no other way...
quoted
could decide on case-by-case basis whether it will use its own code or
generic without touching pointer (without modifying potentially constant
fb_ops structure common to all fbdev instances).
The patch was rejected. I working on your driver. I can throw in a text
mode driver as well.
You can throw anything in and out, of course... It is GPL, after all.
Only question left is whether I'll be satisfied with functionality you
offer.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2003-01-07 21:38:52
quoted
quoted
I'll be happier with character coordinates for text mode.
Yuck!! Using fbcon for text modes is just bloat. For hardware text mode it
is much better to write a nice small console driver like newport_con.c
When I said before christmas that I'll have to write matroxcon to get
reasonable functionality, you laughed... Now, it is clear that there is
no other way...
No I didn't laugh. I didn't like the idea of another fbcon like system
being developed just to support this text mode. I have no problem with
a matroxcon.
You can throw anything in and out, of course... It is GPL, after all.
Only question left is whether I'll be satisfied with functionality you
offer.
:-) I'm working on your driver the latest few days. I managed to shrink
most of the accel code into one common base.I still have alot to go tho.
You have a matroxfb_check_var which makes my life much easier.
From: James Simmons <hidden> Date: 2003-01-04 20:59:00
Rejected. I have put thought into it and the whole point was to not allow
the fbdev layer to touch console data. I stand firm on this!!! The reason
being is the core console layer is going to change the next development
cycle. We have to change to deal with things like the PC9800 type hardware
that support more than 512 fonts. Do we realy want to break every fbdev
driver again. This way the breakage is once and for all. Its is also a
pandoras box. If we place these hooks in we end up with the same crappy
driver problem we had before. I never heard anyone every say the old api
we clean.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Rejected. I have put thought into it and the whole point was to not allow
Personally, that's fine by me since I have no need for those 2
extensions. But please apply the accel_putcs() buffer overrun patch.
BTW, attached is another patch that will change the resolution of the
console via tty ioctl TIOCSWINSZ. I'm not sure if this is the correct
solution, but it's the only one I can think of without really adding a
lot of extra code. This is implemented by adding a con_resize() hook to
fbcon, so the window size can be changed such as by using:
stty cols 128 rows 48 (1024x768 with font 8x16)
The new window size should also be preserved per console. Still, there
are other fb parameters that can screw up the console (such as changing
yres_virtual and bits_per_pixel) but the window size is the most
important.
Tony
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
From: James Simmons <hidden> Date: 2003-01-07 21:35:35
Personally, that's fine by me since I have no need for those 2
extensions. But please apply the accel_putcs() buffer overrun patch.
Applied.
BTW, attached is another patch that will change the resolution of the
console via tty ioctl TIOCSWINSZ. I'm not sure if this is the correct
solution, but it's the only one I can think of without really adding a
lot of extra code. This is implemented by adding a con_resize() hook to
fbcon, so the window size can be changed such as by using:
stty cols 128 rows 48 (1024x768 with font 8x16)
Yes this is the correct approach.
The new window size should also be preserved per console. Still, there
are other fb parameters that can screw up the console (such as changing
yres_virtual and bits_per_pixel) but the window size is the most
important.
Updatevar in fbcon.c should handle yres_virtual properly. The scrolling
code needs alot of work. It is a mess. Bits_per_pixel will be trickier to
handle.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: Petr Vandrovec <hidden> Date: 2003-01-04 23:22:14
On Sat, Jan 04, 2003 at 09:07:29PM +0000, James Simmons wrote:
Rejected. I have put thought into it and the whole point was to not allow
the fbdev layer to touch console data. I stand firm on this!!! The reason
being is the core console layer is going to change the next development
cycle. We have to change to deal with things like the PC9800 type hardware
that support more than 512 fonts. Do we realy want to break every fbdev
driver again. This way the breakage is once and for all. Its is also a
Why? (a) only those which will use putcs, and (b) I see no 512 chars limit
anywhere in new code. And in old code it is there only because of passed
data are only 16bit, not 32bit wide... With simple search&replace you can
extend it to any size you want, as long as you'll not use sparse font
bitmap.
pandoras box. If we place these hooks in we end up with the same crappy
driver problem we had before. I never heard anyone every say the old api
we clean.
I believe that I repeatedly said that I see no problem with old API which
cannot be solved by incremental updates and without removing functionality.
It is like with modules - some believe in evolution, and some in revolution...
Fortunately modules situation finally settled down and it is enough just install
new app to handle module loading/unloading. With current fbdev even trivial
console resizing does not do anything useful (thanks, Antonio).
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
From: James Simmons <hidden> Date: 2003-01-07 21:44:21
Why? (a) only those which will use putcs, and (b) I see no 512 chars limit
anywhere in new code. And in old code it is there only because of passed
data are only 16bit, not 32bit wide... With simple search&replace you can
extend it to any size you want, as long as you'll not use sparse font
bitmap.
The current "core" console code screen_buf layout is designed after VGA
text mode. 16 bits which only 8 bits are used to represent a character, 9
if you have high_fonts flag set. The other 8,7 bits are for attributes.
This is very limiting and it does effect fbcon.c :-( I like to the console
system remove these awful limitation in the future. This why I like to see
fbdev drivers avoid touching strings from the console layer.
Why? (a) only those which will use putcs, and (b) I see no 512 chars limit
anywhere in new code. And in old code it is there only because of passed
data are only 16bit, not 32bit wide... With simple search&replace you can
extend it to any size you want, as long as you'll not use sparse font
bitmap.
The current "core" console code screen_buf layout is designed after VGA
text mode. 16 bits which only 8 bits are used to represent a character, 9
if you have high_fonts flag set. The other 8,7 bits are for attributes.
This is very limiting and it does effect fbcon.c :-( I like to the console
system remove these awful limitation in the future. This why I like to see
fbdev drivers avoid touching strings from the console layer.
Please note that Tony's new accel_putcs() code uses __u32 to pass the character
indices. So it's not limited to 256/512 characters per font. Fonts can be as
large as you want. Sparse fonts can be handled as well, if accel_putcs() takes
care of the conversion from sparse character indices to dense character
indices.
His code can be viewed as a way to do multiple monochrome to color expansions
with one single call, using a predefined table of patterns. Quite generic,
unless you want to have multi-color fonts later :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
On Wed, 2003-01-08 at 18:47, Geert Uytterhoeven wrote:
On Tue, 7 Jan 2003, James Simmons wrote:
quoted
quoted
Why? (a) only those which will use putcs, and (b) I see no 512 chars limit
anywhere in new code. And in old code it is there only because of passed
data are only 16bit, not 32bit wide... With simple search&replace you can
extend it to any size you want, as long as you'll not use sparse font
bitmap.
The current "core" console code screen_buf layout is designed after VGA
text mode. 16 bits which only 8 bits are used to represent a character, 9
if you have high_fonts flag set. The other 8,7 bits are for attributes.
This is very limiting and it does effect fbcon.c :-( I like to the console
system remove these awful limitation in the future. This why I like to see
fbdev drivers avoid touching strings from the console layer.
Please note that Tony's new accel_putcs() code uses __u32 to pass the character
indices. So it's not limited to 256/512 characters per font. Fonts can be as
large as you want. Sparse fonts can be handled as well, if accel_putcs() takes
care of the conversion from sparse character indices to dense character
indices.
His code can be viewed as a way to do multiple monochrome to color expansions
with one single call, using a predefined table of patterns. Quite generic,
unless you want to have multi-color fonts later :-)
:-) I did not want prolong the discussion, but...
Geert is correct that the functions are generic. The fb_putcs() and
fb_setfont() can be compared to Tile blitting. Tile blitting is a
common operation in some games such as Warcraft, Starcraft, and most
RPG's. I'm think there is Tile Blitting support in DirectFB.
In a tile-based game, the basic unit is a Tile which is just a bitmap
with a predefined width and height. The game has several tiles stored in
memory each with it's own unique id. To draw the background/layer, a
TileMap is constructed which is basically another array. Its format is
something like this - TileMap[x] = y which means draw Tile y at screen
position x.
In the fbcon perspective, we can think of each character as a Tile, and
fontdata as the collection of tiles. fb_char.data is basically a
TileMap. Of course, tile blitting in games is more complicated than
this, since games have multiple layers for the background, so layer
position, transparency, etc has to be considered.
So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
It can be even be expanded by including fb_tiledata.depth
fb_tiledata.cmap so we can support multi-colored tiled blitting.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: James Simmons <hidden> Date: 2003-01-09 18:01:26
:-) I did not want prolong the discussion, but...
Geert is correct that the functions are generic. The fb_putcs() and
fb_setfont() can be compared to Tile blitting. Tile blitting is a
common operation in some games such as Warcraft, Starcraft, and most
RPG's. I'm think there is Tile Blitting support in DirectFB.
In a tile-based game, the basic unit is a Tile which is just a bitmap
with a predefined width and height. The game has several tiles stored in
memory each with it's own unique id. To draw the background/layer, a
TileMap is constructed which is basically another array. Its format is
something like this - TileMap[x] = y which means draw Tile y at screen
position x.
In the fbcon perspective, we can think of each character as a Tile, and
fontdata as the collection of tiles. fb_char.data is basically a
TileMap. Of course, tile blitting in games is more complicated than
this, since games have multiple layers for the background, so layer
position, transparency, etc has to be considered.
So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
It can be even be expanded by including fb_tiledata.depth
fb_tiledata.cmap so we can support multi-colored tiled blitting.
This I have no problem with. I'm willing to accept this. As long as data
from the console layer is not touched. As for loadtiles one thing I like
to address is memory allocation. It probable is good idea to do things
like place the tile data in buffers allocated by pci_alloc_consistent.
The other fear is it will only support so many tiles.
:-) I did not want prolong the discussion, but...
Geert is correct that the functions are generic. The fb_putcs() and
fb_setfont() can be compared to Tile blitting. Tile blitting is a
common operation in some games such as Warcraft, Starcraft, and most
RPG's. I'm think there is Tile Blitting support in DirectFB.
In a tile-based game, the basic unit is a Tile which is just a bitmap
with a predefined width and height. The game has several tiles stored in
memory each with it's own unique id. To draw the background/layer, a
TileMap is constructed which is basically another array. Its format is
something like this - TileMap[x] = y which means draw Tile y at screen
position x.
In the fbcon perspective, we can think of each character as a Tile, and
fontdata as the collection of tiles. fb_char.data is basically a
TileMap. Of course, tile blitting in games is more complicated than
this, since games have multiple layers for the background, so layer
position, transparency, etc has to be considered.
So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
It can be even be expanded by including fb_tiledata.depth
fb_tiledata.cmap so we can support multi-colored tiled blitting.
This I have no problem with. I'm willing to accept this. As long as data
from the console layer is not touched. As for loadtiles one thing I like
to address is memory allocation. It probable is good idea to do things
like place the tile data in buffers allocated by pci_alloc_consistent.
The other fear is it will only support so many tiles.
I think it's best to let the driver allocate it. That way the driver can put it
where it's best suited. pci_alloc_consistent() is meant for PCI only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: James Simmons <hidden> Date: 2003-01-09 21:16:55
quoted
This I have no problem with. I'm willing to accept this. As long as data
from the console layer is not touched. As for loadtiles one thing I like
to address is memory allocation. It probable is good idea to do things
like place the tile data in buffers allocated by pci_alloc_consistent.
The other fear is it will only support so many tiles.
I think it's best to let the driver allocate it. That way the driver can put it
where it's best suited. pci_alloc_consistent() is meant for PCI only.
Sorry about the confusiing. I was meaning things like pci_alloc_consistent
of course would be handled for each driver that needed it.
So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
It can be even be expanded by including fb_tiledata.depth
fb_tiledata.cmap so we can support multi-colored tiled blitting.
This I have no problem with. I'm willing to accept this. As long as data
from the console layer is not touched. As for loadtiles one thing I like
to address is memory allocation. It probable is good idea to do things
like place the tile data in buffers allocated by pci_alloc_consistent.
The other fear is it will only support so many tiles.
Hmm, so you're willing to accept this... okay, attached is another
patch, made it a bit cleaner so none of the console data will be ever
touched. Also expanded it so tile blitting has an equivalent
counterpart with classic blitting.
Thinking about it, I think tile blitting may one day become useful if
ever the console supports more than 16-colors. Imagine how expensive it
would be to draw 32-bit fonts using classic blitting.
Tried it with a few test hooks, works fine except for one thing: the
font is initially scrambled at boot, but became fixed later on. I don't
know how to fix that.
Tony
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
@@ -173,6 +173,10 @@#define FB_VMODE_SMOOTH_XPAN 512 /* smooth xpan possible (internally used) */#define FB_VMODE_CONUPDATE 512 /* don't update x/yoffset */+/* Driver Capability */+#define FB_CAPS_CLIPPING 1 /* hardware can do clipping */+#define FB_CAPS_TILEBLIT 2 /* hardware can do tileblits */+#define PICOS2KHZ(a) (1000000000UL/(a))#define KHZ2PICOS(a) (1000000000UL/(a))
@@ -377,6 +381,77 @@int(*fb_mmap)(structfb_info*info,structfile*file,structvm_area_struct*vma);};+/* +*TileBlittingSupport+*+*InTileBlitting,thebasicunitisaTilewhichisabitmapwith+*apredefinedwidthandheight,andoptionally,otherproperties+*suchascolordepth,spacing,transparency,etc.Fornow,we'll+*justsupportwidth,height,andcolordepth.+*+*Alloperationsareanalogoustoclassicblittingoperationswhich+*usepixelsasthebasicunit.Insteadofpixels,itwillusetiles,+*insteadofinfo->pseudo_palette,itwillusetiledata,etc.+*/++structfb_tile{+__u32width;/* tile width in pixels */+__u32height;/* tile height in scanlines */+__u32depth;/* pixel depth */+};++structfb_tiledata{+structfb_tiletile;/* tile properties */+__u32len;/* number of tiles in the map */+__u8*data;/* packed tile data */+};++structfb_tileblit{+__u32dx;/* destination x origin, in tiles */+__u32dy;/* destination y origin, in tiles */+__u32width;/* destination window width, in tiles */+__u32height;/* destination window height, in tiles */+__u32fg_color;/* fg_color if monochrome */+__u32bg_color;/* bg_color if monochrome */+__u32*data;/* tile map - array of indices to tiledata */+};++structfb_tilecopy{+__u32dx;/* destination window origin... */+__u32dy;/* in tiles */+__u32width;/* destination width, in tiles */+__u32height;/* destination height, in tiles */+__u32sx;/* source window origin ... */+__u32sy;/* in tiles */+};++structfb_tilefill{+__u32dx;/* destination window origin ... */+__u32dy;/* in tiles */+__u32width;/* destination width in tiles */+__u32height;/* destination height in tiles */+__u32fg_color;/* fg_color if monochrome */+__u32bg_color;/* bg_color if monochrome */+__u32rop;/* rop operation */+__u32idx;/* index to current tiledata */+};++structfb_tileops{+/* upload tile data to driver and make it current... the driver+*mustcopythecontentsoftiledata.data,notjustthepointertoit*/+int(*fb_loadtiles)(structfb_info*info,+conststructfb_tiledata*tile);+/* blit tiles to destination from a tilemap */+void(*fb_tileblit)(structfb_info*info,+conststructfb_tileblit*tilemap);+/* copy tiles from one region of fb memory to another */+void(*fb_tilecopy)(structfb_info*info,conststructfb_tilecopy*area);+/* fill a region of fb memory with a tile */+void(*fb_tilefill)(structfb_info*info,+conststructfb_tilefill*region);+/* If driver is to support tile blitting, all hooks above are required */+};+structfb_info{kdev_tnode;intflags;
@@ -388,6 +463,7 @@structfb_cursorcursor;/* Current cursor */structfb_cmapcmap;/* Current cmap */structfb_ops*fbops;+structfb_tileops*tileops/* Tile blitting */char*screen_base;/* Virtual address */structvc_data*display_fg;/* Console visible on this display */intcurrcon;/* Current VC. */