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

Re: [Linux-fbdev-devel] clipping

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

On Fri, 2003-01-10 at 05:24, James Simmons wrote:
> 
> > 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.
>  
> I thought about this. Originally I did have this function but removed it.
> WHat do you think Geert?
> 
> > 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.
> 
> Yuck!!! The other way is better.
> 

Yes, I thought so too :-).

I think one scenario why we need clipping is changing bits_per_pixel,
ie, changing from 8->16 will drop your vyres by half and it's difficult
to determine this unless you do another check before the set_par(), as
Geert mentioned.  Worse still, there is little if no valid memory past
vyres but the console thinks there is.  That's where you will get a
segfault.

Whereas explicitly doing fbset -vyres 768 will not cause a segfault,
because you still have valid framebuffer memory past y=768.

Tony

Re: [Linux-fbdev-devel] rotation.

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

On Fri, 2003-01-10 at 03:54, James Simmons wrote:
> 
> > 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.
> 
> Yes. Hardware rotation shouldn't also not effect the way accel 
> operatations are done.
 
The main difference is if the hardware supports rotation, fbcon will
present it with "normal" data.  With the generic implementation, fbcon
will present the driver with rotated data.

So we need a driver capabilities field either in fb_info or
fb_fix_screeninfo.

> 
> > This will not be too processor intensive as long as some data is
> > prepared beforehand, like a rotated fontdata.
> 
> Yeap!! The only thing is we could end up with 4 times the amount of data.
>  

Not really.  We can dynamically rotate the fontdata using the default
display->fontdata into another buffer.  I believe I have functions that
do that in the patch I submitted.  (Sorry, I lost it when one of my
drives crashed :-(.

Tony

Re: [Linux-fbdev-devel] Re: xxx_check_var

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

> > > Yes, this wrong, and afaik, it's your original port to 2.5 that did that
> > > ;)
> > 
> > Yeap. The idea of check_var is to validate a mode. Note modedb uses just
> > check_var. It is okay to READ the values in your par. You shouldn't alter
> > the values in par.
> 
> Perhaps it makes sense to make the info parameter of fb_check_var() const to
> prevent this from happening?

Easy fix. I can whip up a quick patch for that.

None

[<za...@ci...>]

>
X-Mailer: PHP
X-Priority: 3
Content-Type: text/html; charset=windows-1251
Subject: [Linux-fbdev-devel] Ê âàì ïðèøëà îòêðûòêà.
Sender: lin...@li...
Errors-To: lin...@li...
X-BeenThere: lin...@li...
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
List-Help: <mailto:lin...@li...?subject=help>
List-Post: <mailto:lin...@li...>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel>,
	<mailto:lin...@li...?subject=subscribe>
List-Id: <linux-fbdev-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel>,
	<mailto:lin...@li...?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=linux-fbdev-devel>
Date: Thu Jan  9 16:50:02 2003
X-Original-Date: Fri, 10 Jan 2003 03:47:10 +0300 (MSK)

<br><font face=Arial size=2>
Ïðèâåòñòâóåì !<br><br>


Íà Âàøå èìÿ áûëà îòïðàâëåíà îòêðûòêà.<br>

×òîáû ïîëó÷èòü îòêðûòêó, íàæìèòå íà ýòó ññûëêó:<br><br>
<a href=http://mailart.ru/postcard/upload/pickup.php?ecard_id=0301100301100dgOAIW48a0E>http://mailart.ru/postcard/upload/pickup.php?ecard_id=0301100301100dgOAIW48a0E</a><br><br>


Ñ óâàæåíèåì,<br>
<b>MailArt.Ru</b><br>
post Card service <br><br><br><br><br>


____________________________________________________________<br>
<a href=http://mailart.ru/ob1.php><font size=-3 color =808080>1. Ïðîäàåòñÿ ñëîâåñíûé òîâàðíûé çíàê "Áðîêãàóç è Åôðîí".</font><font color=808000>Ïîäðîáíåå >></font></a><br>
<a href=http://mailart.ru/ob2.php><font size=-3 color =808080>2. Ïðîäàåòñÿ êíèãà Èîñèô Ôëàâèé "Èóäåéñêàÿ âîéíà". 4000 ýêçåìïëÿðîâ.</font><font color=808000>Ïîäðîáíåå >></font></a><br><br>
 
<a href=http://mailart.ru/reklama.php><font color =808080><font color=ff0000>ÁÅÑÏËÀÒÍÎ!!!</font>&nbsp;Â ïåðâûé ðàç äåëàåì ðåêëàìó áåñïëàòíî. Ðåêëàìà íà mailart.ru >></font></a></font>

Re: [Linux-fbdev-devel] clipping

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

On Thu, 9 Jan 2003, James Simmons wrote:
> > 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.
>  
> I thought about this. Originally I did have this function but removed it.
> WHat do you think Geert?

Yes, that's OK.

But I was most concerned about fb_ops.fb_imageblit(), since clipping impacts
fb_image.data as well. IIRC, all (most?) current clipping implementations
modify fb_image.{dx,dy,width,height} only, without updating fb_image.data.

> > 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.
> 
> Yuck!!! The other way is better.

Well, in between the calls to fb_ops.fb_check_var() and fb_ops.set_par() you
can still perform that check. But it's indeed ugly.

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] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods

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

> > 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.

Re: [Linux-fbdev-devel] clipping

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

> 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.
 
I thought about this. Originally I did have this function but removed it.
WHat do you think Geert?

> 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.

Yuck!!! The other way is better.

Re: [Linux-fbdev-devel] clipping

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

> > > 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?

I haven't fixed that issue yet. One the last close of /dev/fb the tty 
should be set back to its original state before /dev/fb was first open.

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

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

On Thu, 9 Jan 2003, James Simmons wrote:
> > :-) 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 -- 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

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

> > 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.
> 
> Yup. This is typically the case of PowerMacs where the VGA memory isn't
> even reachable on the PCI/AGP bus. 

Here are the case we will have.

1) Embedded devices. People here have a tendency to want to use serial 
   console and just want fbdev without fbcon. Fbcon set the graphics state  
   in fbcon_startup. Now the developers want to know if the hardware 
   actually worked. So they can call fb_set_var and fb_show_logo 
   themselves in there drivers. They want to fully bring up the hardware.
  
2) Now say the above want to use fbcon. Then they don't need to set the 
   graphics state in there driver. Fbcon will do it for them. 

3) The graphics card has some kind of default text mode state. For the 
   case  where we want to use /dev/fb without fbcon and the text mode then
   we don't want to change the graphics state in the intialization code. 
   It is done in the first open and the last close.

Re: [Linux-fbdev-devel] Radeonfb in 2.5.54bk (now 2.5.55)

[Joshua K. <jo...@lu...>]

Same problem. 2.5.55bk with pulled fbdev-2.5 and -dj

Regards
Josh

Rabid cheeseburgers forced James Simmons <jsi...@in...> to
write this on Thu, 9 Jan 2003 18:17:08 +0000 (GMT):	

> 
> > Latest patch? If it's the one you pushed to BK a day or two ago,
> > that is what I used in the compilation of my kernel. Hence it
> > doesn't quite work.
> > 
> > (to be precise, i issued:
> > bk clone http://linux.bkbits.net:8080/linux-2.5
> > bk -r get
> > bk pull http://fbdev.bkbits.net:8080/fbdev-2.5)
> > 
> > Anything wrong there? Do I have to bk -r get again?
> > 
> > Looks like I am subscribing to this list then. Sigh... too many
> > lists to take care of!! :(
> 
> More changes happened. Can you try another pull.
> 
> 


-- 
Joshua Kwan
jo...@ms...
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
 
It's hard to keep your shirt on when you're getting something off your
chest. 

Re: [Linux-fbdev-devel] rotation.

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

> 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.

Yes. Hardware rotation shouldn't also not effect the way accel 
operatations are done. 

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

Yeap!! The only thing is we could end up with 4 times the amount of data.
 
> 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 think it should video fbcon=rotate:90 command line for example.

> I submitted a patch before (see fbdev archives for "Console Rotation"
> thread) that rotates the console this way.  I had vga16fb, vesafb, and

I seen it and even have it still. 

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

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

> > 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).

Hooks already exist in struct fb_ops.

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

That will happen in the core console code.

[Linux-fbdev-devel] Re: rotation.

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

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

We already have a hook for hardware acceleration in struct fb_ops.

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

The fbdev level will have the functionalty but fbcon is the one that needs 
it.

[Linux-fbdev-devel] Rage1128

[Jon S. <jon...@ya...>]

Does anyone on this list have a Rage128 manual? 

Can anyone point me to source code for directly
reseting a Rage128? I already have the emulate real
mode and call C000:3 method.

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Linux-fbdev-devel] Rage128 as secondary adapter

[Jon S. <jon...@ya...>]

ATI has already released the much more sensitive data
of how to drive their Rage128 3D engine. It's all been
incorporated into X and is open source. 

I doubt if the procedure for resetting the board is
considered a trade secret. The problem is in getting
ATIs attention long enough to tell how to do it. It
may be as simple as poking an output port with a
special value. Hopefully someone with a manual can
tell me.



=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Linux-fbdev-devel] Rage128 as secondary adapter

[Stefan R. <st...@su...>]

* Jon Smirl <jon...@ya...> [030109 18:47]:
> Can someone with access to the Rage128 documentation
> tell me how to do this from protected mode? I have the
> ROM mapped so the code can get to constants stored in
> the ROM. What I need is a piece of C code equal to
> what the ROM initialization does minus the part about
> Int10 vector setup.
 
I'm almost certain that the information you need is only
available when signing an NDA and thus could not be used
in open source drivers. Also a big problem for open source
firmware implementations such as openbios

> The programmers at ATI probably have a piece of code
> available to do this since ATI's Windows driver can do
> it.  I've tried emailing and signing up as a developer
> without response.
 
This is a pretty common experience.

Stefan.

-- 
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense.                      -- E. W. Dijkstra

Re: [Linux-fbdev-devel] Radeonfb in 2.5.54bk

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

> Latest patch? If it's the one you pushed to BK a day or two ago, that is
> what I used in the compilation of my kernel. Hence it doesn't quite
> work.
> 
> (to be precise, i issued:
> bk clone http://linux.bkbits.net:8080/linux-2.5
> bk -r get
> bk pull http://fbdev.bkbits.net:8080/fbdev-2.5)
> 
> Anything wrong there? Do I have to bk -r get again?
> 
> Looks like I am subscribing to this list then. Sigh... too many lists to
> take care of!! :(

More changes happened. Can you try another pull.

Re: [Linux-fbdev-devel] const fb_{fillrect,copyarea,image}?

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

> drivers/video/fbmem.c:fb_show_logo() initializes only image.dx in each loop
> iteration:
> 
> | for (x = 0; x < num_online_cpus() * (LOGO_W + 8) &&
> |      x < info->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
> |         image.dx = x;
> |         info->fbops->fb_imageblit(info, &image);
> |         done = 1;
> | }

Oh.
 
> > > Of course this means that we have to modify the clipping code, which currently
> > > just modifies the passed structure.
> > 
> > :-( That is done to prevent someone from passing data that is larger than 
> > the framebuffer.
> 
> You can still do clipping without modifying the passed structure, right?

Probable it can be arranged this way.
 
> BTW, is it possible that someone passes data that is larger (except for bugs)?
> We have control over what happens in the kernel. Data passed from userspace is
> a different issue, of course.

Yes. Soon the standard ioctl for a cursor will be truly in place. This 
means cfb_imageblit could be a issue from userland.

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

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

> :-) 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. 

Re: [Linux-fbdev-devel] atyfb: 2.5.54

[Nico S. <sch...@wd...>]

James Simmons [Tue, Jan 07, 2003 at 09:54:51PM +0000]:
>=20
> > With 2.5.54 there is something like success with my hardware.
> > Now I get a cursor at the right position. I can't see what I type,
> > but I see the cursor moving correctly.
> > After unloading atyfb the console still behaves this way, nothing
> > changes.
> >=20
> > Are there some options I should set ? I am currently just loading
> > atyfb (with recognizes my card as PCI although it's AGP; seen in dmesg).
>=20
> Can do post your dmesg.

!dmesg

atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTA=
L, 230 MHz PLL, 50 Mhz MCLK
fb0: ATY Mach64 frame buffer device on PCI

Just tell me, if you need more information.

Nico

Re: [Linux-fbdev-devel] atyfb: 2.5.54

[Nico S. <sch...@wd...>]

Geert Uytterhoeven [Tue, Jan 07, 2003 at 10:58:25PM +0100]:
> Atyfb is known not to work on some Rage Mobility P/M (incl. the one in my=
 Vaio
> :-(
=20
I hope this changes soon ;)

Nico

[Linux-fbdev-devel] Rage128 as secondary adapter

[Jon S. <jon...@ya...>]

I'm working on aty128fb to make it support a Rage128
as a secondary adapter. It needs a few new minor
changes to do this.

My main problem is that secondary adapters are not
initialized at boot.  I have a program (vbios.vm86)
that will initialize the R128, but instead I would
like to do it when the driver loads. vbios.vm86 goes
through a complicated process in real mode of
emulating the system boot ROM (same thing X does).

Can someone with access to the Rage128 documentation
tell me how to do this from protected mode? I have the
ROM mapped so the code can get to constants stored in
the ROM. What I need is a piece of C code equal to
what the ROM initialization does minus the part about
Int10 vector setup.

The programmers at ATI probably have a piece of code
available to do this since ATI's Windows driver can do
it.  I've tried emailing and signing up as a developer
without response.

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

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

On Thu, 2003-01-09 at 17:50, Geert Uytterhoeven wrote:
> 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.
> 

This will be a problem only for DirectColor at >= 24 bpp.  At bpp's less
than that, linux_logo_16 will be used.

Another possible solution (in case it supports 24bpp) is to have 2
pseudo_palettes, one which is 16 entries long and public, and another
256-entries long and private.  Then if image.depth is < 24, it's safe to
use cfb_imageblit. Otherwise, it has to use it's own imageblit, one that
will use the private pseudo_palette.  The driver will have the
opportunity to build this because fb_set_cmap() is called for
directcolor modes >= 24bpp, and pseudocolor == 8bpp.

Hopefully, exotics such as this will not export their visuals as
truecolor or static pseudocolor because fb_set_cmap() will not be
called. Otherwise, we'll just make it mandatory to call fb_set_cmap()
for all visual modes requiring linux_logo.
  
> 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.
> 

I believe the cursor inversion value is unused anymore(?), since
fbcon_revc is gone. It has been replaced by the new cursor API which
allows the driver more intimate handling of the cursor.

Tony

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

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

On Thu, 2003-01-09 at 10:30, Geert Uytterhoeven wrote:
> 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.

Yup. This is typically the case of PowerMacs where the VGA memory isn't
even reachable on the PCI/AGP bus. 

Ben.