Re: [Linux-fbdev-devel] Supporting various depth

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

> mmm, well, the problem is that most current 'millions of color' modes are in
> truth depth 24 ones, which are internally either 32bpp (as in the permedia3
> case) or 24bpp (saves bandwith, but no alpha channel and you may be forced to
> do some shifting).

Ugh!!!! This is a bug in fbset. It shouldn't be called depth. It should be
bpp. Depth is how the number of bits used to represent a color in a pixel.
bpp is how many bits per pixel. A good example would be a card with a 80
bpp. Out of the 80 bpp only 30 are used for rbg space (10:10:10). The rest
could be window IDs, depth buffer values etc. fbset should be using -bpp
and you use -rgba to set the size of each field. Unfortunely the current
fbdev api doesn't support things beyond RGBA in the buffer :-( 

> So what should happen if you try to set depth 24 with fbset ? Silently set 32
> bpp ? reject it ?
>
> Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or
> rejected ?

If we go by -depth really means -bpp then make it fail. If the user uses
-rgba along with it then make it work. Some cards have the alpha channel
as a seperate buffer. So these cards really have 24 bpp modes (8:8:8)
where you have to use a seperate buffer to access the alpha channels. The
same goes with cards with window IDs. Some have windows IDs interwoven
with the framebuffer. Other do not. Here we don't even have a alpha
channel. We still have 32 bpp but the depth is 24. The other 8 bits being
a window ID value. 

BTW we could treat the alpha channel as another framebuffer with
(0:0:0:8). Here with have a depth of 0 and bpp of 8. Right? Other types of
buffers could be treated the same way as well. Again fbdev doesn't support
this at present tho :-( That will have to change but this breaks backwards
compatibility.

> > > Also, i am experiencing some (maybe hardware) bugs, and would like to reset
> > > the graphic chip. Is there an existing way to do this kind of stuff via ioctl
> > > ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
> > > would be really happy with it).
> > 
> >    Not really. You could make it reset the card when unloading the module.
> 
> or when loading it ?

Good point. loading it should reset the mode since you have to set up the
card anyways with insmoding the driver.

> Would it be possible to run the vga text console on one head, and a pm3fb on
> the other ? (same chip).

The hardware would have to support that. 

> Well, the real problem here is not so much to reset to default mode, but to do
> a hardware reset on the chip, and initialize it again, to see if the problem
> goes away.

This is a problem for hardware that doesn't detect hardware faults. Some
cards are smart enough to raise a interrupt when the accel engine goes
bonkers. In the interrupt handler you reset the hardware to a sane state
then. Does the pm2 card have such a feature?