linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] fb_imageblit()

[Geert U. <ge...@li...>]

On 9 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > > c. Read color information from pseudopalette if directcolor/truecolor. 
> > 
> > Hoever, pseudopalette has entries for the first 16 colors only!
> > Hence you are limited to the 16 color for directcolor/truecolor modes.
> 
> That's why there's an fb_set_logo_directpalette(), for directcolor
> visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
> fb_set_logo().  Basically, it temporarily replaces info->pseudo_palette
> with one that has 256 entries to match linux_logo.  Logo drawing, using
> cfb_imageblit() has always worked for me in directcolor and truecolor
> modes.

I see a small inconsistency here, which may cause problems with some exotic
hardware: info->pseudo_palette is always initialized by the fbdev driver itself
(which knows the hardware), except for logo drawing, where it's done by the
generic code in fbmem.

On virtually all hardware that will work fine. But on some hardware the exact
pixel format cannot be represented by the {red,green,blue,transp} bitfields in
fb_var_screeninfo.

E.g. the Amiga CyberVision64 card has a S3Trio64. Since Amigas are little
endian and PCI is big endian, they swapped the data bus to simplify 256-color
modes. However, this also means that 16-bit pixel values have to be swapped. So
in depth 15, the pixel format is not ARRRRRGGGGGBBBBB, but GGGBBBBBARRRRRGG.
This can be handled fine in cyberfb by setting up a byteswapped pseudo palette,
but the fb_set_logo_{direct,true}palette() don't know about this. And of course
user space doesn't know about this neither.

One possible solution is to extend the pseudo palette to 256+1 entries if the
depth is at least 8. To save memory, we can still use a 16+1 entry pseudo
palette if depth < 8, but then we have to move the cursor inversion value from
index 16 to index -1.

Note that the old logo code suffered from the same problem and cyberfb hasn't
been updated since a while (it lacks pseudo palette support), so it may not be
that important. I just wanted to mention this case.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Re: 2.5 fbdev & driver initial mode

[Geert U. <ge...@li...>]

On Thu, 9 Jan 2003, James Simmons wrote:
> > How is a driver supposed to set the default mode on init lately ?
> > 
> > Looking at rivafb, it fills info->var from fb_find_mode with the mode
> > option if any, but then does nothing with it (and does nothing if
> > no mode option is passed).
> > 
> > On radeonfb, I fill a var  with the default mode obtained
> > from EDID or the option if any. Then, I basically do
> > 
> > 	info->var = var;
> > 	var.activate = FB_ACTIVATE_NOW;
> > 	fb_set_var(&var, info);
> > 
> > before calling register_framebuffer.
> > 
> > What is the right way to do ?
> 
> Sorry about the confusion. The answer depends on the driver. For the 
> rivafb driver because it has a VGA core we have it NOT switch to a 
> graphics state. The reason is 
> 
> 
> 1) If we run a /dev/fb app was can save the hardware text mode state and
>     restore it on closing /dev/fb. You can see this in rivafb_open and
>    rivafb_release. 
> 
> 2) We can test loading it as a module as see debugging info while still
>    having a VGA text mode. Makes life a little easier. The other thing 
>    I like to do is run mdacon and just the fbdev driver by itself. I can 
>    then test the fbdev driver. When I get really brave I test fbcon.c and
>    can debug it.
> 
> Now for graphics hardware built in that has no hardware text mode. It is 
> better to set the video mode right away.

Note: on some platforms graphics chips with VGA cores are _not_ initialized to
VGA mode by the firmware. So great care should be taken when not explicitly
switching to graphics mode on those platforms.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

[Linux-fbdev-devel] Re: 2.5 fbdev & driver initial mode

[James S. <jsi...@in...>]

> How is a driver supposed to set the default mode on init lately ?
> 
> Looking at rivafb, it fills info->var from fb_find_mode with the mode
> option if any, but then does nothing with it (and does nothing if
> no mode option is passed).
> 
> On radeonfb, I fill a var  with the default mode obtained
> from EDID or the option if any. Then, I basically do
> 
> 	info->var = var;
> 	var.activate = FB_ACTIVATE_NOW;
> 	fb_set_var(&var, info);
> 
> before calling register_framebuffer.
> 
> What is the right way to do ?

Sorry about the confusion. The answer depends on the driver. For the 
rivafb driver because it has a VGA core we have it NOT switch to a 
graphics state. The reason is 


1) If we run a /dev/fb app was can save the hardware text mode state and
    restore it on closing /dev/fb. You can see this in rivafb_open and
   rivafb_release. 

2) We can test loading it as a module as see debugging info while still
   having a VGA text mode. Makes life a little easier. The other thing 
   I like to do is run mdacon and just the fbdev driver by itself. I can 
   then test the fbdev driver. When I get really brave I test fbcon.c and
   can debug it.

Now for graphics hardware built in that has no hardware text mode. It is 
better to set the video mode right away.

[Linux-fbdev-devel] 2.5 fbdev & driver initial mode

[Benjamin H. <be...@ke...>]

Hi James !

How is a driver supposed to set the default mode on init lately ?

Looking at rivafb, it fills info->var from fb_find_mode with the mode
option if any, but then does nothing with it (and does nothing if
no mode option is passed).

On radeonfb, I fill a var  with the default mode obtained
from EDID or the option if any. Then, I basically do

	info->var = var;
	var.activate = FB_ACTIVATE_NOW;
	fb_set_var(&var, info);

before calling register_framebuffer.

What is the right way to do ?

Ben.

[Linux-fbdev-devel] [BK FBDEV updates]

[James S. <jsi...@in...>]

Linus, please do a

	bk pull http://fbdev.bkbits.net:8080/fbdev-2.5

This will update the following files:

 include/video/font.h            |   24 
 arch/m68k/kernel/m68k_defs.c    |    2 
 drivers/video/Kconfig           |    2 
 drivers/video/Makefile          |    3 
 drivers/video/aty/atyfb_base.c  |    4 
 drivers/video/console/Kconfig   |   14 
 drivers/video/console/fbcon.c   |   90 +-
 drivers/video/console/sticon.c  |  101 +-
 drivers/video/console/sticore.c |  159 ++--
 drivers/video/fbmem.c           |   13 
 drivers/video/fbmon.c           |  369 ++++++++++
 drivers/video/i810/i810.h       |    2 
 drivers/video/i810/i810_accel.c |   11 
 drivers/video/i810/i810_dvt.c   |    2 
 drivers/video/i810/i810_main.c  |   51 -
 drivers/video/i810/i810_main.h  |   79 --
 drivers/video/riva/Makefile     |    2 
 drivers/video/riva/fbdev.c      | 1468 +++++++++++++++++++---------------------
 drivers/video/riva/nv_driver.c  |  212 +++++
 drivers/video/riva/riva_hw.c    |  350 +++++++--
 drivers/video/riva/rivafb.h     |   15 
 drivers/video/sstfb.c           |  711 +++++++++----------
 drivers/video/sstfb.h           |   31 
 drivers/video/sticore.h         |   58 -
 drivers/video/stifb.c           |  103 ++
 include/linux/fb.h              |    4 
 include/linux/font.h            |   30 
 27 files changed, 2337 insertions(+), 1573 deletions(-)

through these ChangeSets:

<jsi...@ma...> (03/01/08 1.887)
   [MONITOR support] GTF support for VESA complaint monitors. Here we calculate the general timings needed so we don't over step the bounds for a monitor.
   
   [fbmem.c cleanup] Name change to make teh code easier to read.

<jsi...@ma...> (03/01/07 1.879.2.95)
   Updates from Helge Deller for the console/fbdev drivers for the PARISC platform. Small fix for clearing the screen and a string typo for the Voodoo 1/2 driver.

<jsi...@ma...> (03/01/06 1.879.2.93)
   [RIVA FBDEV] Driver now uses its own fb_open and fb_release function again. It has no ill effects. The drivers uses strickly hardware acceleration so we don't need cfb_fillrect and cfb_copyarea.
   Cleaned up font.h. Geerts orignal pacth broke them up into a font.h in video and one in  linux. Now I put them back together again in include/linux. The m68k platform has been updated for this change.
   

<jsi...@ma...> (03/01/06 1.879.2.92)
   Added resize support for the framebuffer console. Now you can change the console size via stty. Also support for color palette changing on VC switch is supported.

<jsi...@ma...> (03/01/06 1.879.2.91)
   I810 fbdev updates. Cursor fix for ati mach 64 cards on big endian machines. Buffer over flow fix for fbcon putcs function. C99 initializers for the STI console drivers.Voodoo 1/2 and NVIDIA driver updates.

The diff is located at

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 18:47, Geert Uytterhoeven wrote:
> On Tue, 7 Jan 2003, James Simmons wrote:
> > > 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

Re: [Linux-fbdev-devel] rotation.

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 06:44, James Simmons wrote:
> 
> I'm about to implement rotation which is needed for devices like the ipaq. 
> The question is do we flip the xres and yres values depending on the 
> rotation or do we just alter the data that will be drawn to make the 
> screen appear to rotate. How does hardware rotate view the x and y axis?
> Are they rotated or does just the data get rotated? 
> 

If the graphics card has hardware support for rotation, then there is
nothing to be done.  It's the job of the driver if it wants to rotate
the display or not.  This is similar to video overlay mirroring.  What
the user app sees is the framebuffer in "normal" orientation, but what
gets displayed is mirrored.

However, as Geert mentioned, if you want to support rotation
generically, then you have to do it in the fbcon level.  The driver need
not know if the display is rotated or not.  All it needs to do is fill a
region with color, color expand a bitmap and move blocks of data, and
optionally 'pan' the window.  Fbcon will pass the correct (ie, oriented)
information for the driver.

This will not be too processor intensive as long as some data is
prepared beforehand, like a rotated fontdata.

The main difficulty with this approach is how do you tell the console to
rotate the display?  We cannot use fbset because the changes will not be
visible to fbcon. 

I submitted a patch before (see fbdev archives for "Console Rotation"
thread) that rotates the console this way.  I had vga16fb, vesafb, and
i810fb rotate the display without any driver code change. Display
panning was also supported.

However, because we use mmap to expose the framebuffer memory, we will
not be able to completely support rotation for user applications.  They
have to do it on their own.


Tony

Re: [Linux-fbdev-devel] Re: [PATCH]: image.depth fix to accomodate monochrome cards

[Geert U. <ge...@li...>]

On 9 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 17:52, Geert Uytterhoeven wrote:
> > On 8 Jan 2003, Antonino Daplas wrote:
> > > On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote: 
> > > > On 8 Jan 2003, Antonino Daplas wrote:
> > > > > 2.  diff submitted by Geert: cleaner logo data preparation for
> > > > > monochrome cards and correct initialization of palette_cmap.transp.
> > > > 
> > > > I'll have to do some more fixes there, since the monochrome logo is used not
> > > > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > > > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > > > correct `black' and `white' colors on such displays.
> > > > 
> > > > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > > > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > > > entries of {red,green,blue}8[] in fbcmap.c.
> > > > 
> > > 
> > > Hmm, I see.  I think only linux_logo_bw will be the only one affected,
> > > since linux_logo_16 happens to match the console palette and in
> > > linux_logo, we either reset the palette and/or the cmap.
> > 
> > Indeed.
> > 
> > > Would expanding each bit to the full bit depth work?  Ie for bpp=8 using
> > > monochrome data, white is 0 and black is 0xff.
> > 
> > For bpp=8 that won't work, since we have 16 console colors only :-)
> > 
> 
> Of course :-)
> 
> > But for bpp=[1-3] that's OK, cfr. fbcmap.c.
> > 
> > BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
> > pixel values to the logo conversion routine? Preferably through a 2-element
> > array, so we can index it with the logo data bit value instead of using
> > tests/branches. Then we'd have:
> > 
> 
> Something like this?
> 
> static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
> {
> 	int i, j;
> 	u8 mask[2] = {0,0};
> 
> 	switch (needs_logo) {
> 	case 4:
> 		for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) { 
> 			logo[i*2] = linux_logo16[i] >> 4;
> 			logo[(i*2)+1] = linux_logo16[i] & 0xf;
> 		}
> 		break;
> 	case 1:
> 	case ~1:
> 		mask[1] = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
> 		for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
> 		       u8 d = linux_logo_bw[i];
>                        for (j = 0; j < 8; j++, d <<= 1)
>                                logo[i*8+j] = mask[((d ^ needs_logo) >> 7) & 1];
> 		}
> 		break;
> 	}
> }

Yes, looks ok.

BTW, you can get rid of the `d ^ needs_logo' inside the loop by initializing
mask[] based on the value of needs_logo.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] fb_imageblit()

[Geert U. <ge...@li...>]

On 9 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > > c. Read color information from pseudopalette if directcolor/truecolor. 
> > 
> > Hoever, pseudopalette has entries for the first 16 colors only!
> > Hence you are limited to the 16 color for directcolor/truecolor modes.
> 
> That's why there's an fb_set_logo_directpalette(), for directcolor
> visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
> fb_set_logo().  Basically, it temporarily replaces info->pseudo_palette
> with one that has 256 entries to match linux_logo.  Logo drawing, using
> cfb_imageblit() has always worked for me in directcolor and truecolor
> modes.

Bummer, /me should read the code more thoroughfully...

Perhaps renaming `{saved_,}palette' to `{saved_,}pseudo_palette' would make
this clearer...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] clipping

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 17:54, Geert Uytterhoeven wrote:
> On Tue, 7 Jan 2003, James Simmons wrote:
> > > > > BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
> > > > Personally, I don't think we need clipping.  I tried removing it before
> > > > (circa linux-2.5.30+), but the console segfaults whenever I decrease
> > > > var->yres_virtual.  I haven't tried this again with the newest
> > > > framebuffer framework though.
> > > 
> > > Any definitive answer on this?
> > > 
> > > What happens if you resize the VT to such a large size that columns*fontwidth >
> > > xres_virtual or rows*fontheight > yres_virtual? I guess clipping prevents a
> > > crash there?
> > 
> > Correct. Actually fbcon_resize checks to make sure the user doesn't do 
> > something stupid like this. So we might not needed. Hm.
> 
> And what if you use fbset to reduce the resolution below what's needed to
> accomodate the current console size?
> 
Then we do need clipping :-)  I think that happened to me, I just did
not recognize it.  I accidentally lowered the window size using fbset,
and suddenly I had a console where the tail end of each row of text
wraps to the next row.  I wasn't using cfb_imageblit then so this was
done by hardware.  If I was using cfb_imageblit, this will be clipped.

So, I think we do need clipping, but instead of implementing it in
fb_{fillrect,copyarea,imageblit}, we implement it higher up, in
accel_putcs() and family.  This should also protect drivers using 
hardware-based drawing. 

So perhaps, a function something like this:

void fb_clip(struct fb_fillrect *region, struct fb_fillrect *clip);

This should not be difficult to implement, and I'll code it if everyone
agrees.

The other option (which I don't like) is just to check the passed
fb_var_screeninfo in the put_var ioctl against the current console
window size.  But this is not foolproof as we will not be sure of the
resulting window size _after_ the fb_set_var() call.

Tony

Re: [Linux-fbdev-devel] Re: [PATCH]: image.depth fix to accomodate monochrome cards

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 17:52, Geert Uytterhoeven wrote:
> On 8 Jan 2003, Antonino Daplas wrote:
> > On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote: 
> > > On 8 Jan 2003, Antonino Daplas wrote:
> > > > 2.  diff submitted by Geert: cleaner logo data preparation for
> > > > monochrome cards and correct initialization of palette_cmap.transp.
> > > 
> > > I'll have to do some more fixes there, since the monochrome logo is used not
> > > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > > correct `black' and `white' colors on such displays.
> > > 
> > > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > > entries of {red,green,blue}8[] in fbcmap.c.
> > > 
> > 
> > Hmm, I see.  I think only linux_logo_bw will be the only one affected,
> > since linux_logo_16 happens to match the console palette and in
> > linux_logo, we either reset the palette and/or the cmap.
> 
> Indeed.
> 
> > Would expanding each bit to the full bit depth work?  Ie for bpp=8 using
> > monochrome data, white is 0 and black is 0xff.
> 
> For bpp=8 that won't work, since we have 16 console colors only :-)
> 

Of course :-)

> But for bpp=[1-3] that's OK, cfr. fbcmap.c.
> 
> BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
> pixel values to the logo conversion routine? Preferably through a 2-element
> array, so we can index it with the logo data bit value instead of using
> tests/branches. Then we'd have:
> 

Something like this?

static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
{
	int i, j;
	u8 mask[2] = {0,0};

	switch (needs_logo) {
	case 4:
		for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) { 
			logo[i*2] = linux_logo16[i] >> 4;
			logo[(i*2)+1] = linux_logo16[i] & 0xf;
		}
		break;
	case 1:
	case ~1:
		mask[1] = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
		for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
		       u8 d = linux_logo_bw[i];
                       for (j = 0; j < 8; j++, d <<= 1)
                               logo[i*8+j] = mask[((d ^ needs_logo) >> 7) & 1];
		}
		break;
	}
}

Tony

Re: [Linux-fbdev-devel] fb_imageblit()

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > c. Read color information from pseudopalette if directcolor/truecolor. 
> 
> Hoever, pseudopalette has entries for the first 16 colors only!
> Hence you are limited to the 16 color for directcolor/truecolor modes.

That's why there's an fb_set_logo_directpalette(), for directcolor
visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
fb_set_logo().  Basically, it temporarily replaces info->pseudo_palette
with one that has 256 entries to match linux_logo.  Logo drawing, using
cfb_imageblit() has always worked for me in directcolor and truecolor
modes.

Tony

Re: [Linux-fbdev-devel] fb_imageblit()

[Geert U. <ge...@li...>]

On 8 Jan 2003, Antonino Daplas wrote:

> On Wed, 2003-01-08 at 06:23, James Simmons wrote: 
> > > >     
> > > >     If monochrome image data would be packed as well, it could be handled by
> > > >     setting fb_image.fg_color = 1 and fb_image.bg_color = 0 (or vice versa for
> > > >     mono10), and fb_set_logo() becomes simpler as well.
> > > > 
> > > >     If we retain the unpacked data for images, we need some other flag to
> > > >     indicate color expansion. Perhaps setting fb_image.depth to 0?
> > > > 
> > > If we change the contents of the logo data, then it makes sense to pack
> > > the logo data also.  However, if we stick to indices, we might as well
> > > retain the "unpacked" 8-bit format.  I think setting fb_image.depth to 0
> > > to mean color expansion is more appropriate. Drivers that will need
> > > trivial changing would be tgafb, i810fb, rivafb, tdfxfb, atyfb, vga16fb
> > > and of course cfb_imgblt.c, softcursor.c and fbcon.c.
> > 
> > The requirement I made of imageblit was to always use packed data. What 
> > the indices approach was to to always use a struct fb_cmap. This way it 
> > didn't matter if used a pseudocolor mode or a directcolor mode.
>  
> I've thought of that also, packing the data according to the pixel depth.  
> However, this will be very inefficient since image blitting
> will go like this: 
> 
> a. Prepare logo data so each pixel of data is in directcolor format (if
> we will use the cmap), so depth corresponds to framebuffer depth, and
> data is packed. 
> 
> b. Pass the structure to cfb_imageblit. 
> 
> c. In cfb_imageblit, unpack the logo data: 
> 
> d. Get each color component from the cmap data. 
> 
> e. Recreate pixel data based on var.[color].offset and
> var.[color].length. 
> 
> f. Write the pixel data in packed form to the framebuffer. 
> 
> Whereas, with the current approach: 
> 
> a. Prepare logo data such that each pixel corresponds to one byte. 
> 
> b. Pass the structure to cfb_imageblit. 
> 
> c. Read color information from pseudopalette if directcolor/truecolor. 

Hoever, pseudopalette has entries for the first 16 colors only!
Hence you are limited to the 16 color for directcolor/truecolor modes.

> d. Write the pixel data in packed form to the framebuffer. 

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Re: rotation.

[Sven L. <lu...@dp...>]

On Wed, Jan 08, 2003 at 12:05:48PM +0000, John Bradford wrote:
> > > > > I'm about to implement rotation which is needed for devices
> > > > > like the ipaq.
> > > > > The question is do we flip the xres and yres values depending
> > > > > on the rotation or do we just alter the data that will be
> > > > > drawn to make the screen appear to rotate. How does hardware
> > > > > rotate view the x and y axis?  Are they rotated or does just
> > > > > the data get rotated?
> > > > 
> > > > Where are you going to implement the rotation? At the fbcon or
> > > > fbdev level? 
> > > > 
> > > > Fbcon has the advantage that it'll work for all frame buffer
> > > > devices.
> > > 
> > > But you could also provide driver hooks for the chips which have
> > > such a rotation feature included (don't know if such exist, but i
> > > suppose they do, or may in the future).
> 
> It would be nice to have an option to be able to do the rotation
> entirely in software - some desktop users might prefer to have a
> portait-orientated display, when their graphics card doesn't have any
> hardware rotation facilities at all.

Well, that is James plan. I suppose that for hardware that can do
hardware rotation, it will be faster to do it instead of having the
software do it though, and thus it would be nice to have a driver hook
or something.

This way, if rotation is asked, then if the driver supports hardware
rotation, do it, and if not, do it in software.

At first, no driver will support hardware rotation anyway, so it would
be done in software.

And then, you reuse the same stuff to drive a chinese console or
something such.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Re: rotation.

[John B. <jo...@gr...>]

> > > > I'm about to implement rotation which is needed for devices
> > > > like the ipaq.
> > > > The question is do we flip the xres and yres values depending
> > > > on the rotation or do we just alter the data that will be
> > > > drawn to make the screen appear to rotate. How does hardware
> > > > rotate view the x and y axis?  Are they rotated or does just
> > > > the data get rotated?
> > > 
> > > Where are you going to implement the rotation? At the fbcon or
> > > fbdev level? 
> > > 
> > > Fbcon has the advantage that it'll work for all frame buffer
> > > devices.
> > 
> > But you could also provide driver hooks for the chips which have
> > such a rotation feature included (don't know if such exist, but i
> > suppose they do, or may in the future).

It would be nice to have an option to be able to do the rotation
entirely in software - some desktop users might prefer to have a
portait-orientated display, when their graphics card doesn't have any
hardware rotation facilities at all.

John.

Re: [Linux-fbdev-devel] Re: rotation.

[<mr...@us...>]

Sven Luther <lu...@dp...> writes:

> > > I'm about to implement rotation which is needed for devices like th=
e ipaq.=20
> > > The question is do we flip the xres and yres values depending on th=
e=20
> > > rotation or do we just alter the data that will be drawn to make th=
e=20
> > > screen appear to rotate. How does hardware rotate view the x and y =
axis?
> > > Are they rotated or does just the data get rotated?=20
> >=20
> > Where are you going to implement the rotation? At the fbcon or fbdev =
level?
> >=20
> > Fbcon has the advantage that it'll work for all frame buffer devices.
>=20
> But you could also provide driver hooks for the chips which have such a
> rotation feature included (don't know if such exist, but i suppose they
> do, or may in the future).

I heard of someone have problems with the display getting rotated in
Windows.  I don't know what chip it was.

--=20
M=E5ns Rullg=E5rd
mr...@us...

Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods

[Geert U. <ge...@li...>]

On Tue, 7 Jan 2003, James Simmons wrote:
> > 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 -- ge...@li...

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

Re: [Linux-fbdev-devel] Re: rotation.

[Sven L. <lu...@dp...>]

On Wed, Jan 08, 2003 at 11:24:22AM +0100, Geert Uytterhoeven wrote:
> On Tue, 7 Jan 2003, James Simmons wrote:
> > I'm about to implement rotation which is needed for devices like the ipaq. 
> > The question is do we flip the xres and yres values depending on the 
> > rotation or do we just alter the data that will be drawn to make the 
> > screen appear to rotate. How does hardware rotate view the x and y axis?
> > Are they rotated or does just the data get rotated? 
> 
> Where are you going to implement the rotation? At the fbcon or fbdev level?
> 
> Fbcon has the advantage that it'll work for all frame buffer devices.

But you could also provide driver hooks for the chips which have such a
rotation feature included (don't know if such exist, but i suppose they
do, or may in the future).

So, we also support fbcon for not left to righ locales ?

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: rotation.

[Geert U. <ge...@li...>]

On Tue, 7 Jan 2003, James Simmons wrote:
> I'm about to implement rotation which is needed for devices like the ipaq. 
> The question is do we flip the xres and yres values depending on the 
> rotation or do we just alter the data that will be drawn to make the 
> screen appear to rotate. How does hardware rotate view the x and y axis?
> Are they rotated or does just the data get rotated? 

Where are you going to implement the rotation? At the fbcon or fbdev level?

Fbcon has the advantage that it'll work for all frame buffer devices.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] clipping

[Geert U. <ge...@li...>]

On Tue, 7 Jan 2003, James Simmons wrote:
> > > > BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
> > > Personally, I don't think we need clipping.  I tried removing it before
> > > (circa linux-2.5.30+), but the console segfaults whenever I decrease
> > > var->yres_virtual.  I haven't tried this again with the newest
> > > framebuffer framework though.
> > 
> > Any definitive answer on this?
> > 
> > What happens if you resize the VT to such a large size that columns*fontwidth >
> > xres_virtual or rows*fontheight > yres_virtual? I guess clipping prevents a
> > crash there?
> 
> Correct. Actually fbcon_resize checks to make sure the user doesn't do 
> something stupid like this. So we might not needed. Hm.

And what if you use fbset to reduce the resolution below what's needed to
accomodate the current console size?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Re: [PATCH]: image.depth fix to accomodate monochrome cards

[Geert U. <ge...@li...>]

On 8 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote: 
> > On 8 Jan 2003, Antonino Daplas wrote:
> > > 2.  diff submitted by Geert: cleaner logo data preparation for
> > > monochrome cards and correct initialization of palette_cmap.transp.
> > 
> > I'll have to do some more fixes there, since the monochrome logo is used not
> > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > correct `black' and `white' colors on such displays.
> > 
> > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > entries of {red,green,blue}8[] in fbcmap.c.
> > 
> 
> Hmm, I see.  I think only linux_logo_bw will be the only one affected,
> since linux_logo_16 happens to match the console palette and in
> linux_logo, we either reset the palette and/or the cmap.

Indeed.

> Would expanding each bit to the full bit depth work?  Ie for bpp=8 using
> monochrome data, white is 0 and black is 0xff.

For bpp=8 that won't work, since we have 16 console colors only :-)

But for bpp=[1-3] that's OK, cfr. fbcmap.c.

BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
pixel values to the logo conversion routine? Preferably through a 2-element
array, so we can index it with the logo data bit value instead of using
tests/branches. Then we'd have:

  - mono01: black = (1<<bits_per_pixel)-1, white = 0
  - mono10: black = 0, white = (1<<bits_per_pixel)-1
  - pseudocolor depth 1: black = 0, white = 1
  - pseudocolor depth 2: black = 0, white = 3
  - pseudocolor depth 3: black = 0, white (actually light grey) = 7

And thanks to the `(1<<depth)-1' instead of `1' for the mono* cases, monochrome
with bits_per_pixel = e.g. 8 will work as well.

What do you think?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size

[Antonino D. <ad...@po...>]

Hi James, 

Here's an improved GTF implementation.  I was a bit delayed because I
was trying to find a way to do square roots without using floating
point.  The diff is against linux-2.5.54 + your latest fbdev.diff.

static int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo
		       *var, struct fb_info *info);

if flags == 0:  maximize timings
            1:  vrefresh rate driven calculation
            2.  hscan rate driven calculation
	    3.  pixelclock driven calculation.

The parameter 'val' depends on the parameter 'flags':  ignored if flags
== 0, in Hz if 1 and 2, in picoseconds if 3.

The flags are useful for cases such as a fixed-frequency monitor (pass
flags = 2) or for hardware which only have several sets of dotclocks to
use.  In this case, it will run the GTF first, get the resulting
pixelclock to select a dotclock from the driver's own set, then rerun
the GTF using flags=3, and val = selected dotclock.

Probably still has precision errors, like converting KHZ to picoseconds,
but is more or less usable.  Tested with i810fb and rivafb. (For rivafb,
I have to use a hacked version. The latest one does not work for the
riva128).

BTW, I downloaded the source code of read-edid, and it seems that the
following monitor limits are parsable from the EDID block: HorizSync,
VertRefresh, DotClock, and GTF capability. We may change info->monspecs
to match that. Also, the EDID contains a list of supported modes, but
there's only 4 of them(?).  

Tony

diff -Naur linux-2.5.54/drivers/video/fbmon.c linux/drivers/video/fbmon.c
--- linux-2.5.54/drivers/video/fbmon.c	2003-01-08 04:19:48.000000000 +0000
+++ linux/drivers/video/fbmon.c	2003-01-08 04:18:11.000000000 +0000
@@ -289,7 +289,376 @@
 }
 #endif
 
+/* 
+ * VESA Generalized Timing Formula (GTF) 
+ */
+
+#define FLYBACK                     550
+#define V_FRONTPORCH                1
+#define H_OFFSET                    40
+#define H_SCALEFACTOR               20
+#define H_BLANKSCALE                128
+#define H_GRADIENT                  600
+#define C_VAL                       30
+#define M_VAL                       300
+
+struct __fb_timings {
+	u32 dclk;
+	u32 hfreq;
+	u32 vfreq;
+	u32 hactive;
+	u32 vactive;
+	u32 hblank;
+	u32 vblank;
+	u32 htotal;
+	u32 vtotal;
+};
+
+/*
+ * a simple function to get the square root of integers 
+ */
+static u32 fb_sqrt(int x)
+{
+	register int op, res, one;
+
+	op = x;
+	res = 0;
+
+	one = 1 << 30;
+	while (one > op) one >>= 2;
+
+	while (one != 0) {
+		if (op >= res + one) {
+			op = op - (res + one);
+			res = res +  2 * one;
+		}
+		res /= 2;
+		one /= 4;
+	}
+	return((u32) res);
+}
+
+/**
+ * fb_get_vblank - get vertical blank time
+ * @hfreq: horizontal freq
+ *
+ * DESCRIPTION:
+ * vblank = right_margin + vsync_len + left_margin 
+ *
+ *    given: right_margin = 1 (V_FRONTPORCH)
+ *           vsync_len    = 3
+ *           flyback      = 550
+ *
+ *                          flyback * hfreq
+ *           left_margin  = --------------- - vsync_len
+ *                           1000000
+ */
+static u32 fb_get_vblank(u32 hfreq)
+{
+	u32 vblank;
+
+	vblank = (hfreq * FLYBACK)/1000; 
+	vblank = (vblank + 500)/1000;
+	return (vblank + V_FRONTPORCH);
+}
+
+/** 
+ * fb_get_hblank_by_freq - get horizontal blank time given hfreq
+ * @hfreq: horizontal freq
+ * @xres: horizontal resolution in pixels
+ *
+ * DESCRIPTION:
+ *
+ *           xres * duty_cycle
+ * hblank = ------------------
+ *           100 - duty_cycle
+ *
+ * duty cycle = percent of htotal assigned to inactive display
+ * duty cycle = C - (M/Hfreq)
+ *
+ * where: C = ((offset - scale factor) * blank_scale)
+ *            -------------------------------------- + scale factor
+ *                        256 
+ *        M = blank_scale * gradient
+ *
+ */
+static u32 fb_get_hblank_by_hfreq(u32 hfreq, u32 xres)
+{
+	u32 c_val, m_val, duty_cycle, hblank;
+
+	c_val = (((H_OFFSET - H_SCALEFACTOR) * H_BLANKSCALE)/256 + 
+		 H_SCALEFACTOR) * 1000;
+	m_val = (H_BLANKSCALE * H_GRADIENT)/256;
+	m_val = (m_val * 1000000)/hfreq;
+	duty_cycle = c_val - m_val;
+	hblank = (xres * duty_cycle)/(100000 - duty_cycle);
+	return (hblank);
+}
+
+/** 
+ * fb_get_hblank_by_dclk - get horizontal blank time given pixelclock
+ * @dclk: pixelclock in Hz
+ * @xres: horizontal resolution in pixels
+ *
+ * DESCRIPTION:
+ *
+ *           xres * duty_cycle
+ * hblank = ------------------
+ *           100 - duty_cycle
+ *
+ * duty cycle = percent of htotal assigned to inactive display
+ * duty cycle = C - (M * h_period)
+ * 
+ * where: h_period = SQRT(100 - C + (0.4 * xres * M)/dclk) + C - 100
+ *                   -----------------------------------------------
+ *                                    2 * M
+ *        M = 300;
+ *        C = 30;
+
+ */
+static u32 fb_get_hblank_by_dclk(u32 dclk, u32 xres)
+{
+	u32 duty_cycle, h_period, hblank;;
+
+	dclk /= 1000;
+	h_period = 100 - C_VAL;
+	h_period *= h_period;
+	h_period += (M_VAL * xres * 2 * 1000)/(5 * dclk);
+	h_period *=10000; 
+
+	h_period = fb_sqrt((int) h_period);
+	h_period -= (100 - C_VAL) * 100;
+	h_period *= 1000; 
+	h_period /= 2 * M_VAL;
+
+	duty_cycle = C_VAL * 1000 - (M_VAL * h_period)/100;
+	hblank = (xres * duty_cycle)/(100000 - duty_cycle) + 8;
+	hblank &= ~15;
+	return (hblank);
+}
+	
+/**
+ * fb_get_hfreq - estimate hsync
+ * @vfreq: vertical refresh rate
+ * @yres: vertical resolution
+ *
+ * DESCRIPTION:
+ *
+ *          (yres + front_port) * vfreq * 1000000
+ * hfreq = -------------------------------------
+ *          (1000000 - (vfreq * FLYBACK)
+ * 
+ */
+
+static u32 fb_get_hfreq(u32 vfreq, u32 yres)
+{
+	u32 divisor, hfreq;
+	
+	divisor = (1000000 - (vfreq * FLYBACK))/1000;
+	hfreq = (yres + V_FRONTPORCH) * vfreq  * 1000;
+	return (hfreq/divisor);
+}
+
+static void fb_timings_vfreq(struct __fb_timings *timings)
+{
+	timings->hfreq = fb_get_hfreq(timings->vfreq, timings->vactive);
+	timings->vblank = fb_get_vblank(timings->hfreq);
+	timings->vtotal = timings->vactive + timings->vblank;
+	timings->hblank = fb_get_hblank_by_hfreq(timings->hfreq, 
+						 timings->hactive);
+	timings->htotal = timings->hactive + timings->hblank;
+	timings->dclk = timings->htotal * timings->hfreq;
+}
+
+static void fb_timings_hfreq(struct __fb_timings *timings)
+{
+	timings->vblank = fb_get_vblank(timings->hfreq);
+	timings->vtotal = timings->vactive + timings->vblank;
+	timings->vfreq = timings->hfreq/timings->vtotal;
+	timings->hblank = fb_get_hblank_by_hfreq(timings->hfreq, 
+						 timings->hactive);
+	timings->htotal = timings->hactive + timings->hblank;
+	timings->dclk = timings->htotal * timings->hfreq;
+}
+
+static void fb_timings_dclk(struct __fb_timings *timings)
+{
+	timings->hblank = fb_get_hblank_by_dclk(timings->dclk, 
+						timings->hactive);
+	timings->htotal = timings->hactive + timings->hblank;
+	timings->hfreq = timings->dclk/timings->htotal;
+	timings->vblank = fb_get_vblank(timings->hfreq);
+	timings->vtotal = timings->vactive + timings->vblank;
+	timings->vfreq = timings->hfreq/timings->vtotal;
+}
+
+/*
+ * fb_get_mode - calculates video mode using VESA GTF
+ * @flags: if: 0 - maximize vertical refresh rate
+ *             1 - vrefresh-driven calculation;
+ *             2 - hscan-driven calculation;
+ *             3 - pixelclock-driven calculation;
+ * @val: depending on @flags, ignored, vrefresh, hsync or pixelclock
+ * @var: pointer to fb_var_screeninfo
+ * @info: pointer to fb_info
+ *
+ * DESCRIPTION:
+ * Calculates video mode based on monitor specs using VESA GTF. 
+ * The GTF is best for VESA GTF compliant monitors but is 
+ * specifically formulated to work for older monitors as well.
+ *
+ * If @flag==0, the function will attempt to maximize the 
+ * refresh rate.  Otherwise, it will calculate timings based on
+ * the flag and accompanying value.  
+ *
+ * All calculations are based on the VESA GTF Spreadsheet
+ * available at VESA's public ftp (http://www.vesa.org).
+ * 
+ * NOTES:
+ * The timings generated by the GTF will be different from VESA
+ * DMT.  It might be a good idea to keep a table of standard
+ * VESA modes as well.  The GTF may also not work for some displays,
+ * such as, and especially, analog TV.
+ *   
+ * REQUIRES:
+ * A valid info->monspecs, otherwise 'safe numbers' will be used.
+ */ 
+int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_info *info)
+{
+	struct __fb_timings timings;
+	u32 interlace = 1, dscan = 1;
+	u32 hfmin, hfmax, vfmin, vfmax;
+
+	/* 
+	 * If monspecs are invalid, use values that are enough
+	 * for 640x480@60
+	 */
+	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	    info->monspecs.hfmax < info->monspecs.hfmin ||
+	    info->monspecs.vfmax < info->monspecs.vfmin) {
+		hfmin = 29000; hfmax = 30000;
+		vfmin = 60; vfmax = 60;
+	} else {
+		hfmin = info->monspecs.hfmin;
+		hfmax = info->monspecs.hfmax;
+		vfmin = info->monspecs.vfmin;
+		vfmax = info->monspecs.vfmax;
+	}
+
+	memset(&timings, 0, sizeof(struct __fb_timings));
+	timings.hactive = var->xres;
+	timings.vactive = var->yres;
+	if (var->vmode & FB_VMODE_INTERLACED) { 
+		timings.vactive /= 2;
+		interlace = 2;
+	}
+	if (var->vmode & FB_VMODE_DOUBLE) {
+		timings.vactive *= 2;
+		dscan = 2;
+	}
+
+	switch (flags) {
+	case 0: /* maximize refresh rate */
+		timings.hfreq = hfmax;
+		fb_timings_hfreq(&timings);
+		if (timings.vfreq > vfmax) {
+			timings.vfreq = vfmax;
+			fb_timings_vfreq(&timings);
+		}
+		break;
+	case 1: /* vrefresh driven */
+		timings.vfreq = val;
+		fb_timings_vfreq(&timings);
+		break;
+	case 2: /* hsync driven */
+		timings.hfreq = val;
+		fb_timings_hfreq(&timings);
+		break;
+	case 3: /* pixelclock driven */
+		timings.dclk = PICOS2KHZ(val) * 1000;
+		fb_timings_dclk(&timings);
+		break;
+	default:
+		return -EINVAL;
+		
+	} 
+	
+	if (timings.vfreq < vfmin || timings.vfreq > vfmax || 
+	    timings.hfreq < hfmin || timings.hfreq > hfmax)
+		return -EINVAL;
+
+
+	var->pixclock = KHZ2PICOS(timings.dclk/1000);
+	var->hsync_len = (timings.htotal * 8)/100;
+	var->right_margin = (timings.hblank/2) - var->hsync_len;
+	var->left_margin = timings.hblank - var->right_margin - var->hsync_len;
+	
+	var->vsync_len = (3 * interlace)/dscan;
+	var->lower_margin = (1 * interlace)/dscan;
+	var->upper_margin = (timings.vblank * interlace)/dscan - 
+		(var->vsync_len + var->lower_margin);
+	
+	return 0;
+}
+	
+/*
+ * fb_validate_mode - validates var against monitor capabilities
+ * @var: pointer to fb_var_screeninfo
+ * @info: pointer to fb_info
+ *
+ * DESCRIPTION:
+ * Validates video mode against monitor capabilities specified in
+ * info->monspecs.
+ *
+ * REQUIRES:
+ * A valid info->monspecs.
+ */
+int fb_validate_mode(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+	u32 hfreq, vfreq, htotal, vtotal, pixclock;
+	u32 hfmin, hfmax, vfmin, vfmax;
+
+	/* 
+	 * If monspecs are invalid, use values that are enough
+	 * for 640x480@60
+	 */
+	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	    info->monspecs.hfmax < info->monspecs.hfmin ||
+	    info->monspecs.vfmax < info->monspecs.vfmin) {
+		hfmin = 29000; hfmax = 30000;
+		vfmin = 60; vfmax = 60;
+	} else {
+		hfmin = info->monspecs.hfmin;
+		hfmax = info->monspecs.hfmax;
+		vfmin = info->monspecs.vfmin;
+		vfmax = info->monspecs.vfmax;
+	}
+
+	if (!var->pixclock)
+		return -EINVAL;
+	pixclock = PICOS2KHZ(var->pixclock) * 1000;
+	   
+	htotal = var->xres + var->right_margin + var->hsync_len + 
+		var->left_margin;
+	vtotal = var->yres + var->lower_margin + var->vsync_len + 
+		var->upper_margin;
+
+	if (var->vmode & FB_VMODE_INTERLACED)
+		vtotal /= 2;
+	if (var->vmode & FB_VMODE_DOUBLE)
+		vtotal *= 2;
+
+	hfreq = pixclock/htotal;
+	vfreq = hfreq/vtotal;
+
+	return (vfreq < vfmin || vfreq > vfmax || 
+		hfreq < hfmin || hfreq > hfmax) ?
+		-EINVAL : 0;
+}
+
 EXPORT_SYMBOL(parse_edid);
 #ifdef CONFIG_PCI
 EXPORT_SYMBOL(get_EDID);
 #endif
+EXPORT_SYMBOL(fb_get_mode);
+EXPORT_SYMBOL(fb_validate_mode);
diff -Naur linux-2.5.54/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.54/include/linux/fb.h	2003-01-08 04:20:07.000000000 +0000
+++ linux/include/linux/fb.h	2003-01-08 04:19:26.000000000 +0000
@@ -468,6 +468,10 @@
 extern int fbmon_valid_timings(u_int pixclock, u_int htotal, u_int vtotal,
 			       const struct fb_info *fb_info);
 extern int fbmon_dpms(const struct fb_info *fb_info);
+extern int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var,
+		       struct fb_info *info);
+extern int fb_validate_mode(struct fb_var_screeninfo *var,
+			    struct fb_info *info);
 
 /* drivers/video/fbcmap.c */
 extern int fb_alloc_cmap(struct fb_cmap *cmap, int len, int transp);

Re: [Linux-fbdev-devel] fbmem.c : FBIOGETCMAP

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 06:37, James Simmons wrote:
> 
> > I can run the fb color map tests now if you had a
> > chance to fix the code.
> > 
> > I am just running fbtest from the sourceforge fb cvs.
> 
> I'm CC the fbdev list because the fb color map code is a mess. I like to 
> know what the best approach would be to clean it up.
> 
> FIrst the main bug. In fb_copy_cmap we should be testing to see if 
> copy_from[to]_user fails. We don't. The other issue is for fb_copy_cmap
> We handle memcpy, copy_from_user, and copy)to_user. Now in fb_set_cmap
> we use get_user also without any checks. 
> 
> So we could have fb_copy_cmap keep handling all these issues and remove 
> get_user from fb_set_cmap. We would just pass in fbcmap we got from 
> fb_copy_cmap and pass into fb_set_cmap. The other approach is to 
> remove copy_from_user in fb_copy_cmap and place it int fb_set_cmap. 
> 
> What do you think is the best approach to this?
> 
> 
I don't know, it looks okay to me except for the following:

1.  In case FBIOPUTCMAP, fb_set_cmap() must pass 1 (to imply get info
from user space).

2.  In case FBIOGETCMAP, fb_copy_cmap() must pass 2 (to imply copy cmap
from kernel space to user space)

3.  no checks when doing the user access functions (should have no
effect really, except for the extra processing).

I think fb_set_cmap() is a bit misleading.  It mostly implies set the hardware 
DAC based on the color information in fb_cmap.  fb_cmap is either in kernel 
space or user space.  There is no need to copy the actual cmap to kernel 
space and we just let the user app keep a copy of its own.

So fb_copy_cmap() is not necessary when doing an fb_set_cmap() because
you have to allocate memory for it, which has to be deallocated after
doing an fb_set_cmap().  We cannot use info->cmap because it might be of
different length, and it will clobber the console cmap.

The copy_from_user() of fb_copy_cmap() may not be needed unless we
have support for it.  If this is the case, then we have to find a way of
saving info->cmap first then allocate memory for the new cmap.  Then
deallocate the new cmap and restore the default cmap to info->cmap
afterwards.  You will need additional code for this. In any case, info->cmap
is driver-private anyway, and user apps have no business replacing
info->cmap with its own.

I think the main use of those 2 ioctls is this:

1. save kernel cmap by doing FBIOGETCMAP,
2. set hardware DAC based on user app's cmap using FBIOPUTCMAP,
3. upon exit of the app, restore hardware DAC by doing FBIOPUTCMAP using
the cmap taken from FBIOGETCMAP.

Tony 

Re: [Linux-fbdev-devel] fb_imageblit()

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 06:23, James Simmons wrote: 
> > >     
> > >     If monochrome image data would be packed as well, it could be handled by
> > >     setting fb_image.fg_color = 1 and fb_image.bg_color = 0 (or vice versa for
> > >     mono10), and fb_set_logo() becomes simpler as well.
> > > 
> > >     If we retain the unpacked data for images, we need some other flag to
> > >     indicate color expansion. Perhaps setting fb_image.depth to 0?
> > > 
> > If we change the contents of the logo data, then it makes sense to pack
> > the logo data also.  However, if we stick to indices, we might as well
> > retain the "unpacked" 8-bit format.  I think setting fb_image.depth to 0
> > to mean color expansion is more appropriate. Drivers that will need
> > trivial changing would be tgafb, i810fb, rivafb, tdfxfb, atyfb, vga16fb
> > and of course cfb_imgblt.c, softcursor.c and fbcon.c.
> 
> The requirement I made of imageblit was to always use packed data. What 
> the indices approach was to to always use a struct fb_cmap. This way it 
> didn't matter if used a pseudocolor mode or a directcolor mode.
 
I've thought of that also, packing the data according to the pixel depth.  
However, this will be very inefficient since image blitting
will go like this: 

a. Prepare logo data so each pixel of data is in directcolor format (if
we will use the cmap), so depth corresponds to framebuffer depth, and
data is packed. 

b. Pass the structure to cfb_imageblit. 

c. In cfb_imageblit, unpack the logo data: 

d. Get each color component from the cmap data. 

e. Recreate pixel data based on var.[color].offset and
var.[color].length. 

f. Write the pixel data in packed form to the framebuffer. 

Whereas, with the current approach: 

a. Prepare logo data such that each pixel corresponds to one byte. 

b. Pass the structure to cfb_imageblit. 

c. Read color information from pseudopalette if directcolor/truecolor. 

d. Write the pixel data in packed form to the framebuffer. 

Aside from the inefficiency of the method (pack, unpack, pack), drawing
the logo will become inconsistent with the behavior of the rest of the
functions, since it's the only one that gets color info differently.  If
you look at color_imageblit() and slow_imageblit(), they basically use
the same code logic. 

Secondly, indexing the cmap instead of the pseudo_palette means that
cfb_imageblit has to know the native framebuffer format.  This was
argued before that the generic drawing functions need not know of the
format, one of the reasons we have info->pseudopalette.  Actually, in
order to be really consistent, I would rather have everything refer to
the pseudopalette, regardless of the visual format.  This will be better
especially for some of the corner cases, like monochrome cards with
bits_per_pixel = 8. 

Thirdly, it's much simpler for drivers to draw the logo.  Just get the
corrct pixel data from it's own palette.  No need to construct each
pixel from the cmap.  That's tedious, slow, and will contribute to code
bloat.  Which is easier?  Get each byte from the logo data, and use it as an 
index to the pseudo_palette, or unpack the data, separate each unit to 4 
color components, and construct pixel data from cmap using the 4 extracted 
indices?

I agree that it would be faster in some cases to draw a packed logo
data, but if we're going to be inconsistent, let's do it all the way. 
Make the logo data match the native framebuffer format.  This will be
very efficient, and this is the one that I actually prefer.

Tony 

Re: [Linux-fbdev-devel] Re: [PATCH]: image.depth fix to accomodate monochrome cards

[Antonino D. <ad...@po...>]

On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote: 
> On 8 Jan 2003, Antonino Daplas wrote:
> > 2.  diff submitted by Geert: cleaner logo data preparation for
> > monochrome cards and correct initialization of palette_cmap.transp.
> 
> I'll have to do some more fixes there, since the monochrome logo is used not
> only on monochrome displays, but on all other displays with bits_per_pixel < 4
> Since the pixel data in fb_image are colormap indices, they have to reflect the
> correct `black' and `white' colors on such displays.
> 
> E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> entries of {red,green,blue}8[] in fbcmap.c.
> 

Hmm, I see.  I think only linux_logo_bw will be the only one affected,
since linux_logo_16 happens to match the console palette and in
linux_logo, we either reset the palette and/or the cmap.

Would expanding each bit to the full bit depth work?  Ie for bpp=8 using
monochrome data, white is 0 and black is 0xff.

I think we still have several corner cases, such as TRUECOLOR with bpp
<= 8, I'm not sure if that works.

Anyway, here's an updated patch for linux-2.5.54 + James Simmons' latest
fbdev.diff.  Not sure if it works though :-)

Tony

diff -Naur linux-2.5.54/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.54/drivers/video/cfbimgblt.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2003-01-08 01:51:21.000000000 +0000
@@ -323,7 +323,7 @@
 	bitstart &= ~(bpl - 1);
 	dst1 = p->screen_base + bitstart;
 
-	if (image->depth == 1) {
+	if (image->depth == 0) {
 		if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
 		    p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
 			fgcolor = ((u32 *)(p->pseudo_palette))[image->fg_color];
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.54/drivers/video/console/fbcon.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2003-01-07 15:43:52.000000000 +0000
@@ -395,7 +395,7 @@
 	image.dx = xx * vc->vc_font.width;
 	image.dy = yy * vc->vc_font.height;
 	image.height = vc->vc_font.height;
-	image.depth = 1;
+	image.depth = 0;
 
 	if (!(vc->vc_font.width & 7)) {
 		unsigned int pitch, cnt, i, j, k;
@@ -1170,7 +1170,7 @@
 	image.dy = real_y(p, ypos) * vc->vc_font.height;
 	image.width = vc->vc_font.width;
 	image.height = vc->vc_font.height;
-	image.depth = 1;
+	image.depth = 0;
 	image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width;
 
 	info->fbops->fb_imageblit(info, &image);
diff -Naur linux-2.5.54/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.54/drivers/video/fbmem.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/fbmem.c	2003-01-08 01:53:22.000000000 +0000
@@ -386,6 +386,7 @@
 	palette_cmap.red = palette_red;
 	palette_cmap.green = palette_green;
 	palette_cmap.blue = palette_blue;
+	palette_cmap.transp = NULL;
 
 	for (i = 0; i < LINUX_LOGO_COLORS; i += n) {
 		n = LINUX_LOGO_COLORS - i;
@@ -448,26 +449,33 @@
 		palette[i] = i << redshift | i << greenshift | i << blueshift;
 }
 
-static void __init fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
+#if defined (__BIG_ENDIAN)
+#define BIT_SHIFT(x, shift) ((x) >> (shift))
+#else
+#define BIT_SHIFT(x, shift) ((x) << (shift))
+#endif
+
+static void fb_set_logo(struct fb_info *info, u8 *logo, int needs_logo)
 {
 	int i, j;
+	u8 mask = (u8) ~(BIT_SHIFT(0xffff, info->var.bits_per_pixel));
 
 	switch (needs_logo) {
 	case 4:
-		for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) {
+		for (i = 0; i < (LOGO_W * LOGO_H)/2; i++) { 
 			logo[i*2] = linux_logo16[i] >> 4;
 			logo[(i*2)+1] = linux_logo16[i] & 0xf;
 		}
 		break;
 	case 1:
 	case ~1:
-	default:
-		for (i = 0; i < (LOGO_W * LOGO_H)/8; i++)
-			for (j = 0; j < 8; j++)
-				logo[i*8 + j] = (linux_logo_bw[i] &  (7 - j)) ?
-						((needs_logo == 1) ? 1 : 0) :
-						((needs_logo == 1) ? 0 : 1);
-			break;
+		for (i = 0; i < (LOGO_W * LOGO_H)/8; i++) {
+		       u8 d = linux_logo_bw[i];
+                       for (j = 0; j < 8; j++, d <<= 1)
+                               logo[i*8+j] = (((d ^ needs_logo) >> 7) & 1) ?
+				       mask : 0;
+		}
+		break;
 	}
 }
 
diff -Naur linux-2.5.54/drivers/video/i810/i810_accel.c linux/drivers/video/i810/i810_accel.c
--- linux-2.5.54/drivers/video/i810/i810_accel.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/i810/i810_accel.c	2003-01-07 15:45:47.000000000 +0000
@@ -404,7 +404,7 @@
 		return;
 	}
 
-	if (par->depth == 4 || image->depth != 1) {
+	if (par->depth == 4 || image->depth != 0) {
 		wait_for_engine_idle(par);
 		cfb_imageblit(p, image);
 		return;
diff -Naur linux-2.5.54/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.54/drivers/video/riva/fbdev.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2003-01-07 15:47:28.000000000 +0000
@@ -1323,7 +1323,7 @@
 	volatile u32 *d;
 	int i, j, size;
 
-	if (image->depth != 1) {
+	if (image->depth != 0) {
 		wait_for_idle(par);
 		cfb_imageblit(info, image);
 		return;
diff -Naur linux-2.5.54/drivers/video/skeletonfb.c linux/drivers/video/skeletonfb.c
--- linux-2.5.54/drivers/video/skeletonfb.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/skeletonfb.c	2003-01-07 15:59:33.000000000 +0000
@@ -445,9 +445,14 @@
  *      @fg_color: For mono bitmap images this is color data for     
  *      @bg_color: the foreground and background of the image to
  *		   write directly to the frmaebuffer.
- *	@depth:	How many bits represent a single pixel for this image.
+ *	@depth:	This will be zero (0) if color expanding (character drawing).  
+ *              If nonzero, this represent the pixel depth of the data. 
  *	@data: The actual data used to construct the image on the display.
- *	@cmap: The colormap used for color images.   
+ *             It is a monochrome bitmap if color expanding.  For image
+ *             drawing, each byte of data represents 1 pixel irrespective
+ *             of the framebuffer depth.  The byte is either an index to the
+ *             pseudo_palette for directcolor and truecolor, or the 
+ *             actual pixel written to the framebuffer.
  */
 }
 
diff -Naur linux-2.5.54/drivers/video/softcursor.c linux/drivers/video/softcursor.c
--- linux-2.5.54/drivers/video/softcursor.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/softcursor.c	2003-01-07 15:39:15.000000000 +0000
@@ -47,7 +47,7 @@
 	image.dy = cursor->image.dy;
 	image.width = cursor->image.width;
 	image.height = cursor->image.height;
-	image.depth = cursor->image.depth;
+	image.depth = 0;
 	image.data = data;
 
 	if (info->fbops->fb_imageblit)
diff -Naur linux-2.5.54/drivers/video/tdfxfb.c linux/drivers/video/tdfxfb.c
--- linux-2.5.54/drivers/video/tdfxfb.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/tdfxfb.c	2003-01-07 15:46:33.000000000 +0000
@@ -939,7 +939,7 @@
 	u8 *chardata = (u8 *) pixmap->data;
 	u32 srcfmt;
 
-	if (pixmap->depth == 1) {
+	if (pixmap->depth == 0) {
 		banshee_make_room(par, 8 + ((size + 3) >> 2));
 		tdfx_outl(par, COLORFORE, pixmap->fg_color);
 		tdfx_outl(par, COLORBACK, pixmap->bg_color);
diff -Naur linux-2.5.54/drivers/video/tgafb.c linux/drivers/video/tgafb.c
--- linux-2.5.54/drivers/video/tgafb.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/tgafb.c	2003-01-07 15:44:35.000000000 +0000
@@ -572,7 +572,7 @@
 	   can do better than the generic code.  */
 	/* ??? There is a DMA write mode; I wonder if that could be
 	   made to pull the data from the image buffer...  */
-	if (image->depth > 1) {
+	if (image->depth > 0) {
 		cfb_imageblit(info, image);
 		return;
 	}
diff -Naur linux-2.5.54/drivers/video/vga16fb.c linux/drivers/video/vga16fb.c
--- linux-2.5.54/drivers/video/vga16fb.c	2003-01-08 01:53:45.000000000 +0000
+++ linux/drivers/video/vga16fb.c	2003-01-07 15:50:49.000000000 +0000
@@ -1301,7 +1301,7 @@
 				
 void vga16fb_imageblit(struct fb_info *info, struct fb_image *image)
 {
-	if (image->depth == 1)
+	if (image->depth == 0)
 		vga_imageblit_expand(info, image);
 	else if (image->depth == info->var.bits_per_pixel)
 		vga_imageblit_color(info, image);