linuxconsole-dev

mixing fb / direct access (was: Is a FontCache worth implementing

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

>speaking of that : what is  the simplest/safest solution to allow the use
>of direct access to the accel engine with the fb driver ?
>
>in my example, how can I make the use of glide safe with the fb driver on
>voodoo 1 ?

Their really is no way. What I did was just mmap the accel region and
framebuffer. Then pounded away on the mmio region. No DMA or anything like
that. It worked but fbdev wasn't designed with this in mind. Test to see
if a /dev/fb exist that uses the voodoo 1? You can create a while loop
that opens everything /dev/fbX and then do a ioctl for fb_fix_screeninfo.
Do a string compare with "Voodoo 1". If you get this then you can use a
fbdev interface. First you should lock the the VT to prevent VC switching.
Then place the keyboard in raw mode to read the keyboard. Also you will
need a way to deal with the VC switching back to the console. This
will require setting up signal handlers. Then it is safe to mmap the regions
and use /dev/fb. Pound away on the registers. Also make sure you use the
fbdev driver to set the mode instead of the glide library.
   This is for 2.4.X at present. Now for ruby once I add the final
touches. Do a while loop to look for the "Voodoo 1" string as above. Then
open /dev/fb. By doing this it will automatically lock the VT for you. The
n open /dev/eventX to see which input devices you have. Use /dev/eventX
to get input events for various devices. Now if you want to VT switch to
another terminal it is just as easy. First if you want to save the screens
contents copy them to a allocated chunk of memory. Then unmap the
framebuffer and mmio regions. Close /dev/fb which will allow VT switching
and reset the console back to original state for the VC you are switching
to. Close all /dev/eventX. You are done. As you can see with this you can
make a really small and simple glide library. Same for X servers ;-)

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

LinuxFB access control idea

[David H. <dho...@ca...>]

I don't know whether anyone on this list has considered this idea, but I
thought I'd put it up anyway:

I've recently been having a look at writing an FB driver, and it occurs to
me that it might be possible to control access to multiple virtual
framebuffers by making use of the Linux VM system.

Basically, when a framebuffer is active, the processes that use it would
have the relevant virtual pages marked as "present" in the page
table. When not active, the attached processes would have the same pages
marked as "not present".

This means that the "nopage" function on the VMA for the framebuffer would
be called to load the page. This could send a SIGTTOU signal to indicate
that the framebuffer is not available for use at the moment (rather than
sending a SIGBUS signal, since the page can't be made available). A
SIGCONT signal would then be automatically sent when the framebuffer
becomes available again.

Unless the SIGTTOU signal is trapped or ignored, this would suspend the
process, and the SIGCONT signal would resume it.

Cheers,
David Howells

Re: Is a FontCache worth implementing?

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

On Mon, Mar 12, 2001 at 04:45:35AM -0800, James Simmons wrote:
> 
> >Err, i was speaking of userland accelerated mesa support, not openGL in
> >fbdev, which i know will not be welcome in the kernel.
> 
> You don't need it in the kernel. Before DRI I hacked Mesa to use fbdev.
> Sure it is slow but it sure was faster than X with no acceleration.

Yes, but this is not the same mesa version that is used by X and which may be
HW accelerated on some board,s is it ?

So we would need a second opengl library lying around for fbdev opengl, this
is not nice, better to do it right and have fbdev to play nice with dri/drm.

> >I may be wrong, but i had the impression that it is not sane us to do DMA
> >without speaking to DRM about it.
> >
> >That said, maybe using DMA is not the nicest thing to do, maybe it is
> >wastefull for us, ...
> 
> But unfortunely it is needed for specific types of cards. DMA can be done
> internally. It is just a matter of making sure the console system is
> shutdown when KD_GRAPHICS is set. This way their is no conflict.

What about registering with drm, and then use the drm kernel module for doing
dma ? Is there something wrong with it ?

Friendly,

Sven Luther

mixing fb / direct access (was: Is a FontCache worth implementing ?)

[Ghozlane T. <gt...@pr...>]

From: "James Simmons" <jsi...@li...>

> >Textures is only one of the way of doing this. I guess games oriented
> >3dfx HW will only have textures, and not dedicated 2d font mapping stuff,
> >like bitmap expansion or direct glyph writing ?
>
> Yep. From what I seen in the specs this is the case. In fact their is no
> real framebuffer for the voodoo 1. With some magic we get a fbdev driver
> going.

speaking of that : what is  the simplest/safest solution to allow the use of
direct access to the accel engine with the fb driver ?

in my example, how can I make the use of glide safe with the fb driver on
voodoo 1 ?

how does "normal" fb driver cope with this kind of things , say switching
from the console using the frame buffer to X using "native" access to the
board ?

ghoz

console to graphics state

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

>Ok, good.  This is something I was going to bring up.  Most cards will
>require that they be in PIO mode before starting X.  Being in ProMo4
>will surely render the machine a temporary doorstop.

That is if they don't use the UseFBDev option for XF86Config. Then XFree86
counts on vgacon being present. I have done dumb mistakes with this. I
recently had problems when I was leaving X. All my fonts where corrupt. I
discovered I left the UseFBDev option on even tho I was then using vgacon.
Personally I think all mode switching for various cards should be handled
by the kernel on behalf of X or otherwise we will be running into all
sorts of problems. The reality is fbcon is required for some platforms no
matter how much some hate it and like to see it go away.

>It will probably have to be extended some way to change PCI access modes
>when X starts regardless of /dev/drm. How can we accomplish this
>(without modifying the X driver)?

Yuk!!!! X should not be touching PCI space IMNSHO.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] Endianess ???

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

>> >fb_bitfield.msb_right?
>>
>> Hum. Could be used this way. I never seen anyone take advantage of this
>> field. Also why is it used for each color component? Why not have just
>> one field for the framebuffer?
>
>Add the following fields to ruby and mark the others for depreciation:
>
>struct fb_info {
>    int msb_right;
>    int currcon;
>    ...
>};
>
>Why is msb_right __u32 in fb.h?  Isn't it boolean?

We have watch out here. We could add msb_right to fb_info but we can't
remove it from fb_fix_screeninfo without breaking things :-( I assume it
__u32 for word alignment issues. currcon is no longer need for ruby :-)
We have struct vt_struct to represent each VT and struct vc_data to
represent each virtual console that belongs to some VT.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] Re: Is a FontCache worth implementing ?

[Brad D. <br...@ne...>]

On 12 Mar 2001 04:19:06 -0800, James Simmons wrote:
> 
> >>I'm working on the removal of the console_spinlock so we can use DMA.
> >>This will greatly speed up fbcon.
> >
> >Err, ...
> >
> >so this would mean using the drm/dri stuff for doing DMA ?
> >
> >what about cards that don't have drm support yet ?
> >
> >Or will we just mess up things if we want to run simoultanous with
> >X+Accelerated OpenGL ?
> 
> No. For some cards like the intel i810 we have to use DMA/irq because we
> have no choice. Their is no mmio mode for these types of cards. Once of
> the big changes for 2.5.X is the comcept of a console state and a graphics
> state. When you open explictly /dev/fb or /dev/drm the console system
> shutdowns, via being replaced by dummy con. This prevents any conflicts
> while using the accel engine directly.

Ok, good.  This is something I was going to bring up.  Most cards will
require that they be in PIO mode before starting X.  Being in ProMo4
will surely render the machine a temporary doorstop.

It will probably have to be extended some way to change PCI access modes
when X starts regardless of /dev/drm.  How can we accomplish this
(without modifying the X driver)?

> >Will this enable us to do accelerated Mesa on fbdev ?
> 
> No. But I do have plans to merge fbdev and dri at some point in the
> future :-)

Hmm.  I'm going to take a gander at DRI API again.  I know it has
changed signifigantly since the last time I looked at it.  Maybe it
wouldn't be such a bad idea to use DRI to get in and out of ProMo4,
allocate buffers, etc.  I wonder what kinds of implications that would
have on X.

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth implementing ?

[Brad D. <br...@ne...>]

On 12 Mar 2001 11:43:07 +0100, Sven LUTHER wrote:
> On Sat, Mar 10, 2001 at 01:56:07AM -0800, James Simmons wrote:
> > 
> > >> Using a image blitter you can translate that data from normal RAM to
> > >> the video card memory. The nice thing about a image blitter is you can
> > >> do depth translations (mono to depth X).
> > >
> > >Yes, that was killed my current (test) implementation : 16 colors
> > >mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)
> > 
> > I agree with you about the PCI bus. Slow to go over. I want to maximize
> > fbcon as much as possible. I'm working on the removal of the
> > console_spinlock so we can use DMA. This will greatly speed up fbcon. I
> 
> Err, ...
> 
> so this would mean using the drm/dri stuff for doing DMA ?

No.  That is well beyond the scope of fbdev.  All we really want is fast
text. :-)  We'll be using DMA more like how storage controllers use it,
not how X uses it.

> Will this enable us to do accelerated Mesa on fbdev ?

Hmm.  I suppose in theory you could, but it would be card dependent with
lots of userland help.

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth

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

>> But font sizes like 6x11 exist. What could be done in this case is even
>> tho it is say a 6x11 font we bit padded it so it is 8x11. The fonts
>> will just appear to be farther spaced apart.
>
>I strongly disapprove that approach. I routinely use ProFont6x11 since
>it works on pm3fb (ok, this evening :-), and it's very useful to have a
>wider console (particulary since my XF4 is broken :-( ). Padding to 8
>pixels would be a waste.

I'm only talking about it for systems where this is a must (i.e amiga).
Otherwise you can do whatever you want.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Is a FontCache worth implementing?

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

>Err, i was speaking of userland accelerated mesa support, not openGL in
>fbdev, which i know will not be welcome in the kernel.

You don't need it in the kernel. Before DRI I hacked Mesa to use fbdev.
Sure it is slow but it sure was faster than X with no acceleration.

>I may be wrong, but i had the impression that it is not sane us to do DMA
>without speaking to DRM about it.
>
>That said, maybe using DMA is not the nicest thing to do, maybe it is
>wastefull for us, ...

But unfortunely it is needed for specific types of cards. DMA can be done
internally. It is just a matter of making sure the console system is
shutdown when KD_GRAPHICS is set. This way their is no conflict.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Is a FontCache worth implementing ?

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

>I think we should differentiate between pattern expansion fills and image
>writes (as said before). Also some card offer both a limited size pattern
>fill (mostly 32x32 i guess), but also a more generic patterned rendering,
>where any kind of bitmap can be expanded. (well a rectangular area of
>anysize). This would be faster by a factor of (depth of framebuffer) that
>using image writed for monochrome fonts.

No problem. I think the api is felxiable enough. Example psuedo code:

struct fb_image {
        __u32 width;                    /* Size of image */
        __u32 height;
        __u16 x;                        /* Where to place image */
        __u16 y;
        __u32 fg_color;                 /* Only used when a mono bitmap */
        __u32 bg_color;
        __u8  depth;                    /* Dpeth of the image */
        char  *data;                    /* Pointer to image data */
};

xxxfb_drawimage(struct fb_info *p, struct fb_image *image)
{
   if (image->depth == 1) {
	/* Use pattern fill */
   } else {
	/* Draw a color image */
   }
}

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Is a FontCache worth implementing ?

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

>>I'm working on the removal of the console_spinlock so we can use DMA.
>>This will greatly speed up fbcon.
>
>Err, ...
>
>so this would mean using the drm/dri stuff for doing DMA ?
>
>what about cards that don't have drm support yet ?
>
>Or will we just mess up things if we want to run simoultanous with
>X+Accelerated OpenGL ?

No. For some cards like the intel i810 we have to use DMA/irq because we
have no choice. Their is no mmio mode for these types of cards. Once of
the big changes for 2.5.X is the comcept of a console state and a graphics
state. When you open explictly /dev/fb or /dev/drm the console system
shutdowns, via being replaced by dummy con. This prevents any conflicts
while using the accel engine directly.

>Will this enable us to do accelerated Mesa on fbdev ?

No. But I do have plans to merge fbdev and dri at some point in the
future :-)

>Textures is only one of the way of doing this. I guess games oriented
>3dfx HW will only have textures, and not dedicated 2d font mapping stuff,
>like bitmap expansion or direct glyph writing ?

Yep. From what I seen in the specs this is the case. In fact their is no
real framebuffer for the voodoo 1. With some magic we get a fbdev driver
going.

>But notice that textures can be expensive to use, if other means are
>easily available, which are handled only in the fb access units.

I agree. I'm just showing it is possible to make drawimage flexiable
enough to do this.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth

[<dol...@cl...>]

> But font sizes like 6x11 exist. What could be done in this case is even
> tho it is say a 6x11 font we bit padded it so it is 8x11. The fonts will
> just appear to be farther spaced apart.

I strongly disapprove that approach. I routinely use ProFont6x11 since
it works on pm3fb (ok, this evening :-), and it's very useful to have a
wider console (particulary since my XF4 is broken :-( ). Padding to 8
pixels would be a waste.

-- 
DOLBEAU Romain               |
ENS Cachan / Ker Lann        | The Gods made Heavy Metal
Thesard IRISA / CAPS         |     and it's never gonna die
dol...@cl...    |           -- Manowar

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth

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

>Note that I prefer to have limitations on size and position. Do you
>really want to code the `generic' case for bitplanes? Limiting sizes and
>positions to multiple of 8 helps a lot here to keep the code simple. And
>you don't really need more for a text console.

But font sizes like 6x11 exist. What could be done in this case is even
tho it is say a 6x11 font we bit padded it so it is 8x11. The fonts will
just appear to be farther spaced apart.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: fbdev cursor management

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

>Guys,
>
>I've been taking a look at the cursor flashing code,
>from the point of view of how it's affected by the
>recent enabling of interrupts across the console code.

I see the problems. I just pursposed a new cursor api soe we can have a
clean fbdev to fbcon abstraction. Also we really need to move the curent
cursor code in fbcon.c:fbcon_startup. They really belong in their
respected drivers.

>It all happens in timer handlers and interrupt handlers,
>with no protection against mainline code accessing the
>hardware simultaneously.

Many drivers use spinlocks to manage access.

>- Collapse all the various per-driver cursor flashing
>  routines into a single place - manage the timer from
>  drivers/video/fbcon.c and from there, call into the
>  driver layer if requested.

fbcon_cursor :-)

> The only way we have of doing this at present is to call
> schedule_task() from within the timer handler.  This works
> fine, but it complicates the device close and module unload
> problem somewhat.  del_timer_sync + flush_scheduled_tasks
> will be needed in the right places.

Yuck!!! I see this also a problem for VBL dependent drivers. Some
drivers to require you sync with the VBL to do things like change
the color map. Worst some of these drivers require you poll a bit
to see if the VBL occured.

[snip] rivafb problems. These will be fixed now they are pointed out.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Mon, Mar 12, 2001 at 12:16:06PM +0100, Geert Uytterhoeven wrote:
> On Mon, 12 Mar 2001, Sven LUTHER wrote:
> > Textures is only one of the way of doing this. I guess games oriented 3dfx HW
> > will only have textures, and not dedicated 2d font mapping stuff, like bitmap
> > expansion or direct glyph writing ?
> 
> Before we go to far into this discussion, all we want is a (fast) text console
> implementation. That means
>   - rectangle copy
>   - rectangle fill
>   - monochrome expansion for text drawing
>   - pixmap drawing for penguin

Yes, sure, ...

> No OpenGL, mesa, DRM, DRI, textures, ...!

Err, i was speaking of userland accelerated mesa support, not openGL in fbdev,
which i know will not be welcome in the kernel.

That said :

Some cards do text drawing by applying textures, i think i saw some such
in the X permedia2 driver, not sure though

There were speaks of DMA, which we can do, as opposed to X which needs
kernel support for it. This could (well maybe) be a good thing. But if i
understood all things correctly, the drm kernel module was writen to
permit X/OpenGL to do DMA accesses to the chip, that is filling buffers
that are then DMA sent to the chip. I may be wrong, but i had the
impression that it is not sane us to do DMA without speaking to DRM about it.

That said, maybe using DMA is not the nicest thing to do, maybe it is
wastefull for us, ...

Also there is the fact that on most chips, the using of DRM/DRI on X and fbdev
together is often severly broken, or is it ?

That said, i am not aware of the last kernel politics regarding this, so
please excuse me if i may have tripped into something best laid dormant.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Mon, 12 Mar 2001, Sven LUTHER wrote:
> On Sat, Mar 10, 2001 at 01:56:07AM -0800, James Simmons wrote:
> > >> Using a image blitter you can translate that data from normal RAM to
> > >> the video card memory. The nice thing about a image blitter is you can
> > >> do depth translations (mono to depth X).
> > >
> > >Yes, that was killed my current (test) implementation : 16 colors
> > >mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)
> > 
> > I agree with you about the PCI bus. Slow to go over. I want to maximize
> > fbcon as much as possible. I'm working on the removal of the
> > console_spinlock so we can use DMA. This will greatly speed up fbcon. I
> 
> Err, ...
> 
> so this would mean using the drm/dri stuff for doing DMA ?
> 
> what about cards that don't have drm support yet ?
> 
> Or will we just mess up things if we want to run simoultanous with
> X+Accelerated OpenGL ? 
> 
> Will this enable us to do accelerated Mesa on fbdev ?

    [...]

> Textures is only one of the way of doing this. I guess games oriented 3dfx HW
> will only have textures, and not dedicated 2d font mapping stuff, like bitmap
> expansion or direct glyph writing ?

Before we go to far into this discussion, all we want is a (fast) text console
implementation. That means
  - rectangle copy
  - rectangle fill
  - monochrome expansion for text drawing
  - pixmap drawing for penguin

No OpenGL, mesa, DRM, DRI, textures, ...!

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] Is a FontCache worth implementing ?

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

On Sat, Mar 10, 2001 at 02:02:10AM -0800, James Simmons wrote:
> 
> > That's a more generalized _clear + _clear_margins ?
> 
> Yes. Also you can use different ROP with rectfill. Right now XOR and COPY
> are supported. XOR is used for fbcon_recv.
> 
> > better _bmove ? (if only I could get _that_ one to work
> > reliably)
> 
> Yep.
> 
> > > The last function is fb_imageblit
> > > which transfers data from host memory to screen memory.
> >
> > Thats seems new to me (I only know 2.2 and 2.4, as I only grep'ped
> > through Ruby). Could be useful...
> 
> Yes it is a ruby thing.
> 
> >I calculated that for small fonts, just sending the font data may  require
> >less register writes than seting up a blit). This is naturally not true
> >for bigger fonts (like 32x32 fonts, but do we use that ?)
> 
> Well if we want to draw the penguin (80x80) then yes. Image draw and
> except any size image. This is a strenght. We don't have to say you can
> only use 8,16,32 fonts. You can use any size. This is much more powerful.

I think we should differentiate between pattern expansion fills and image
writes (as said before). Also some card offer both a limited size pattern fill
(mostly 32x32 i guess), but also a more generic patterned rendering, where
anykind of bitmap can be expanded. (well a rectangular area of anysize). This
would be faster by a factor of (depth of framebuffer) that using image writed
for monochrome fonts.

Friendly,

Svne Luther

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Sat, Mar 10, 2001 at 01:56:07AM -0800, James Simmons wrote:
> 
> >> Using a image blitter you can translate that data from normal RAM to
> >> the video card memory. The nice thing about a image blitter is you can
> >> do depth translations (mono to depth X).
> >
> >Yes, that was killed my current (test) implementation : 16 colors
> >mean 16 copies of each glyph. Yuck (8 Mb for 512 glyhs, 16x16 32bpp)
> 
> I agree with you about the PCI bus. Slow to go over. I want to maximize
> fbcon as much as possible. I'm working on the removal of the
> console_spinlock so we can use DMA. This will greatly speed up fbcon. I

Err, ...

so this would mean using the drm/dri stuff for doing DMA ?

what about cards that don't have drm support yet ?

Or will we just mess up things if we want to run simoultanous with
X+Accelerated OpenGL ? 

Will this enable us to do accelerated Mesa on fbdev ?

> need to rename that function. The goal is to draw some image. It depends on
> the hardware how you approach it. I like to see AGP used by fbcon to do
> the transfering of font images to the console. You can even make them
> textures if you want. In fact I was thinking of doing that for the voodoo

Textures is only one of the way of doing this. I guess games oriented 3dfx HW
will only have textures, and not dedicated 2d font mapping stuff, like bitmap
expansion or direct glyph writing ?

> 1 card. It has 4 megs for the framebuffer, 4 megs for register space and 4
> megs for texture space. So I could place font data in the texture space.
> The big thing I like is the hardware translation from whatever to the
> current depth. Some hardware has this seperate. I leave up to the driver
> programmer how to approach this problem.

But notice that textures can be expensive to use, if other means are easily
available, which are handled only in the fb access units.

Friendly,

Sven Luther

Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Sat, Mar 10, 2001 at 01:45:12AM -0800, James Simmons wrote:
> 
> >Well, but mostly the expensive part of it is passing from the system
> >memory to the card memory, where the bus is limiting us.
> 
> I know. That is why I'm pushing this fbcon to accel-con move.
> 
> >but you could use this 64 glyphs as a cache, or something such, uploading
> >only the most used chars or something such.
> >
> >That said, other cards can use standard FB memory for font cache, and
> >then either do a blit or a pattern expansion to the screen.
> 
> True. You could do this for cards that have the avaliable memory. If fbcon
> is running at a resolution that occupies the entire memory then you are in
> trouble. You can do many fancy tricks. I leave it up to the driver writer
> to be fancy. The goal is to draw some image. Keep in mind I wanted to also
> want to have the function draw the penguin. It is very miss leading the
> name of the function. It should be drawimage instead. Also for cards that
> lack this function a software emulated drawimage has to be done. Could
> people post all the possible ways a "fontcache" could work. I see
> imagedraw is going to the touchy one.

Like said before, what X is doing is :

  we have blit accel, fill accel, mono8x8 pattern fills, ColorExpand Fills,
  WriteImage and WriteBitmap. (well there are more, but these are supported by
  the glint driver).

Well, in fbdev, we already support the first two, isn't it ? for emptying
screen and scrolling, and you do a wrtieimage or something like it for drawing
fonts, but that's it.

When drawing fonts, you copy the color info to the framebuffer, but mostly
each font is one color only, so you send the same color info to each position,
err that would be the same color to each lit pixel, and the background color
to the background. It is much more efficient to set the foreground/background
color to use and then write bitmaps that will be color expanded to it, either
trough a font cache or directly.

you could then provide a write image function, but this would only be used for
writing images (like the penguin logo) or maybe colored fonts (if or when
those exists).

That said, you have to be aware, that on most hardware that have a bypass unit
(err direct framebuffer access, that is) if you don't do fancy things (like
blending and logic opps) then the direct framebuffer access may be faster than
the image write, since you have to pass the data trough the bus anyway, and it
will either be written directly to the FB, or go trough the graphic core, in
which case, you have to send additional info for the graphic core to be
configured right.

> >What about pattern fills ? Where you provide a bitmap, and the accel
> >engine copies this bitmap, putting 1 color for the 1s and another (or
> >transparent) for 0s.
> 
> Same thing. The goal of the function is to draw some image. How it is
> implemented is up to the driver. Another way to do it is make textures of
> fonts and using texture mapping to draw the characters. I seen something
> like this used for a X server before. The windowing was done with the z
> buffer which was used to act like hardware window IDs. Each window then
> was textured mapped with whatever the program was trying to display. The
> texture map changed when needed. X term wa steh trickiest. Alot of little
> texture maps but it still was fast.

Err, no, you want to use the same function to do two different things :

What i would propose, but then i only know well the glint family of chips is
the following :

  * you have a function for setting the fore/background.

  * you have a function for writing bitmap to the offscreen memory.

  * you have a function for write expanding bitmaps to fore/background color
    directly from bitmap data you provide the chip.

  * you have one for doing color expansion from the offscreen memory.

Driver would provide both, or either one of them, or none, and provide a flag
telling the rest of it which one to use. Maybe be we could use a flag also to
set the relative expense of using each method, so the upper layer can choose
which one to use, depending of the font size or something such.

and writing data would be (in the direct case) :

  * set the font color. (maybe 2 register writes, one for each color).

  * while the font color does not change, just repeat :

    - expand one char at a time (usually chips can do upto 32x32 chars or
      somethign such, other may be limited to 8x8 one).

      The cost of this would be 1 32bit register per 32pixels, or 1 register
      write per line of font. You could even combine various 8 or 16 width
      fonts in one if your hardware don't support automatic
      padding/compression.

If you use font caching, you need to know what font are in the cache (using a
bitmap) if not all are, and jsut send the few register command to draw them,
or if it is not present, upload it, and then do the expansion.

This makes much more sense than a image write function that will maybe only be
used for the penguin, and may be done faster using the direct framebuffer
access, if yo don't do fancy stuff (which may not be supported anyway by the
fbdev, or used in the common layer, userland apps may do this kind of things
though.)

As for the planar hardware, i guess this is similar to just writing to one
plane, or only writing to the planes that are needed by the color selected. I
guess it is faster when using only as much colors as there are planes ?

Ok, that's all i had to say about this, but iam not really that familiar with
fbdev, and this may have been done already, or thought off and discarded. If
such is the case, plase excuse me of taking your time this way ...

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Sun, Mar 11, 2001 at 09:15:43PM +0100, Geert Uytterhoeven wrote:
> On Sat, 10 Mar 2001, James Simmons wrote:
> > True. You could do this for cards that have the avaliable memory. If fbcon
> > is running at a resolution that occupies the entire memory then you are in
> > trouble. You can do many fancy tricks. I leave it up to the driver writer
> > to be fancy. The goal is to draw some image. Keep in mind I wanted to also
> > want to have the function draw the penguin. It is very miss leading the
> > name of the function. It should be drawimage instead. Also for cards that
> > lack this function a software emulated drawimage has to be done. Could
> > people post all the possible ways a "fontcache" could work. I see
> > imagedraw is going to the touchy one.
> > 
> > >What about pattern fills ? Where you provide a bitmap, and the accel
> > >engine copies this bitmap, putting 1 color for the 1s and another (or
> > >transparent) for 0s.
> > 
> > Same thing. The goal of the function is to draw some image. How it is
> > implemented is up to the driver. Another way to do it is make textures of
> > fonts and using texture mapping to draw the characters. I seen something
> > like this used for a X server before. The windowing was done with the z
> > buffer which was used to act like hardware window IDs. Each window then
> > was textured mapped with whatever the program was trying to display. The
> > texture map changed when needed. X term wa steh trickiest. Alot of little
> > texture maps but it still was fast.
> 
> With a font cache you store all fonts in an off-screen area of graphics memory,
> and let the graphics acceleration engine do monochrome-to-color expansion for
> each individual character.
> 
> For systems that don't have hardware acceleration for monochrome-to-color
> expansion and that have bitplanes (the Amiga comes to mind :-), it's much
> faster to not draw individual characters at the monochrome-to-color expansion
> level, but to prepare a bitmap for a bunch of characters and let that expand by
> software (using 32-bit accesses instead of 8-bit accesses for individual
> characters).
> 
> So here we have a trade-off: do we want to draw individual character bitmaps
> (possibly hardware accelerated), or do we glue individual characters together
> and draw the composite bitmap?

Why not provide both, and have the driver tell the rest of the stuff which way
he prefers to do it via a flag or somethign such ?

This way we can best support a wider array of hardware kind.

(but then i may be influenced by my Xfree86 experience, and don't have the
long range fbdev vision in mind a lot right now ...)

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worthimplementing ?

[Romain D. <do...@ir...>]

Geert Uytterhoeven wrote:

> So here we have a trade-off: do we want to draw individual character bitmaps
> (possibly hardware accelerated), or do we glue individual characters together
> and draw the composite bitmap?

There's hardware that accelerate Glyph stuff, it might be useful to 
provide a way to use that (the pm3 does, even if I don't know how
to use it) - I don't think that would be easy with concatenated
strings.

Just my .02 euros.

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth implementing ?

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

On Sat, 10 Mar 2001, James Simmons wrote:
> >I calculated that for small fonts, just sending the font data may  require
> >less register writes than seting up a blit). This is naturally not true
> >for bigger fonts (like 32x32 fonts, but do we use that ?)
> 
> Well if we want to draw the penguin (80x80) then yes. Image draw and
> except any size image. This is a strenght. We don't have to say you can
> only use 8,16,32 fonts. You can use any size. This is much more powerful.

Note that I prefer to have limitations on size and position. Do you really want
to code the `generic' case for bitplanes? Limiting sizes and positions to
multiple of 8 helps a lot here to keep the code simple. And you don't really
need more for a text console.

For modern cards with packed pixels this doesn't matter that much, especially
in a mode with 32 bits per pixel :-)

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: [linux-fbdev] Is a FontCache worth implementing ?

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

On Sat, 10 Mar 2001, James Simmons wrote:
> True. You could do this for cards that have the avaliable memory. If fbcon
> is running at a resolution that occupies the entire memory then you are in
> trouble. You can do many fancy tricks. I leave it up to the driver writer
> to be fancy. The goal is to draw some image. Keep in mind I wanted to also
> want to have the function draw the penguin. It is very miss leading the
> name of the function. It should be drawimage instead. Also for cards that
> lack this function a software emulated drawimage has to be done. Could
> people post all the possible ways a "fontcache" could work. I see
> imagedraw is going to the touchy one.
> 
> >What about pattern fills ? Where you provide a bitmap, and the accel
> >engine copies this bitmap, putting 1 color for the 1s and another (or
> >transparent) for 0s.
> 
> Same thing. The goal of the function is to draw some image. How it is
> implemented is up to the driver. Another way to do it is make textures of
> fonts and using texture mapping to draw the characters. I seen something
> like this used for a X server before. The windowing was done with the z
> buffer which was used to act like hardware window IDs. Each window then
> was textured mapped with whatever the program was trying to display. The
> texture map changed when needed. X term wa steh trickiest. Alot of little
> texture maps but it still was fast.

With a font cache you store all fonts in an off-screen area of graphics memory,
and let the graphics acceleration engine do monochrome-to-color expansion for
each individual character.

For systems that don't have hardware acceleration for monochrome-to-color
expansion and that have bitplanes (the Amiga comes to mind :-), it's much
faster to not draw individual characters at the monochrome-to-color expansion
level, but to prepare a bitmap for a bunch of characters and let that expand by
software (using 32-bit accesses instead of 8-bit accesses for individual
characters).

So here we have a trade-off: do we want to draw individual character bitmaps
(possibly hardware accelerated), or do we glue individual characters together
and draw the composite bitmap?

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

fbdev cursor management

[Andrew M. <an...@uo...>]

Guys,

I've been taking a look at the cursor flashing code,
from the point of view of how it's affected by the
recent enabling of interrupts across the console code.

Pretty much all of the cursor-blink stuff is racy,
and has always been racy on SMP.  Enabling the
interrupts has made it racy on UP as well.

It all happens in timer handlers and interrupt handlers,
with no protection against mainline code accessing the
hardware simultaneously.  As far as I can see, the
races will be harmless - the worst they can do is to
leave some snailtrails on the screen, which will soon
scroll away. So unless someone feels strongly about it,
or can pick a problem which I've missed I'd propose that
we leave it as it is for now.

vgacon looks OK.


Some things which I'd propose for future work:

- Collapse all the various per-driver cursor flashing
  routines into a single place - manage the timer from
  drivers/video/fbcon.c and from there, call into the
  driver layer if requested.

- The cursor flash code should do the actual flash stuff
  from within process context, not interrupt context.  This
  way, it can do acquire_console_sem() to serialise
  everything properly.

  The only way we have of doing this at present is to call
  schedule_task() from within the timer handler.  This works
  fine, but it complicates the device close and module unload
  problem somewhat.  del_timer_sync + flush_scheduled_tasks
  will be needed in the right places.

  There are lots of places in the kernel which would benefit
  from a process-context timer callback mechanism - ethernet
  drivers in particular.  So this is a piece of infrastructure
  which we should develop for 2.5.  It'll be just fine for
  use in das blinkencursor code.

- With rivafb, I note that fbcon_vbl_handler() is being
  called at 50 Hz, and it doesn't actually *do* anything.
  All the work is being done by riva_cursor_timer_handler().
  Seems a little inefficient?

- riva_cursor_timer_handler() is being called at 100Hz,
  which is also more costly than it needs to be.  Also,
  it does this:

	rinfo->cursor->timer->expires = jiffies + (HZ / 100);

  so if the system has HZ < 100, the machine locks
  up - run_timer_list() never returns.  Minor point, but
  it's another argument in favour of using, say, HZ/10.

-