Choosing the correct framebuffer configuration

Choosing the correct framebuffer configuration

[Jon Smirl]

If I understand things correctly the framebuffer config is supposed to
be controlled by the transp/red/blue/green fields of fb_var_screeninfo
during check_var. These fields are then combined to compute the
bits_per_pixel.

radeonfb is working from the other direction, it starts with bpp and
then computes ARGB. This looks wrong to me.

Radeonfb supports these four configs controlled by setting BPP:
DST_8BPP = 8BPP indexed
DST_15BPP = ARGB1555
DST_16BPP = RGB565
DST_32BPP = ARGB8888

The chips actually allow nine configs (maybe more when I get a look at
the R300 doc). It is ambiguous to set these configs based on BPP since
there are multiple configs for various BPP. These configs should
instead be set with the transp/red/blue/green fields.

4bpp Index = /4
8bpp Index = /8
16bpp aRGB 1555 = 1/5/5/5
16bpp RGB 565 = /5/6/5
16bpp aRGB 4444 = 4/4/4/4
16bpp aIndex 88 = 8/8
24bpp RGB 888 = /8/8/8
32bpp aRGB 8888 = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10

What is the best way to fix this? The interesting hidden config is 30b color.

I can hack it in by using ARGB if BPP is zero and the old scheme if BPP is set.

Do other fbdev drivers have this problem?

BTW, Xserver is limited to six of the nine configs.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Petr Vandrovec]

Jon Smirl wrote:
> If I understand things correctly the framebuffer config is supposed to
> be controlled by the transp/red/blue/green fields of fb_var_screeninfo
> during check_var. These fields are then combined to compute the
> bits_per_pixel.
> 
> radeonfb is working from the other direction, it starts with bpp and
> then computes ARGB. This looks wrong to me.

It is correct thing to do if you support only one format per depth.

> Radeonfb supports these four configs controlled by setting BPP:
> DST_8BPP = 8BPP indexed
> DST_15BPP = ARGB1555
> DST_16BPP = RGB565
> DST_32BPP = ARGB8888
> 
> The chips actually allow nine configs (maybe more when I get a look at
> the R300 doc). It is ambiguous to set these configs based on BPP since
> there are multiple configs for various BPP. These configs should
> instead be set with the transp/red/blue/green fields.
> 

If you support all of them, I would do:

> 4bpp Index = /4

Use this if bpp==4, ignore rgba.

> 8bpp Index = /8

Use this if bpp==8, ignore rgba.

> 16bpp aRGB 1555 = 1/5/5/5

Use this if bpp==16 and green.length == 5.  For backward compatibility 
you can support bpp=15 with any rgba...

> 16bpp RGB 565 = /5/6/5

Use this if bpp==16 and it is not 1/5/5/5 or 4/4/4/4.

> 16bpp aRGB 4444 = 4/4/4/4

Use this if bpp==16 and green.length == 4.

> 16bpp aIndex 88 = 8/8

I'm afraid that with this format you run out of luck.  I do not think 
infrastructure is able to support this.  API does not have separate 
entry for Index position/width in pseudocolor, and rgb fileds are used 
for reporting DAC width in pseudocolor mode.  Maybe use this when 
nonstd==1 ?  Choosing this format when green.length==8 might trigger 
when 8/24/32bpp videomode is switched to 16bpp by fbset without rgba 
option, so it is probably not good idea to use green.length==8 to select 
this videomode.

> 24bpp RGB 888 = /8/8/8

bpp == 24, any rgba.

> 32bpp aRGB 8888 = 8/8/8/8

bpp == 24, green.length != 10.

> 32bpp aRGB 2:10:10:10 = 2/10/10/10

bpp == 32, green.length == 10.

> What is the best way to fix this? The interesting hidden config is 30b color.
> 
> I can hack it in by using ARGB if BPP is zero and the old scheme if BPP is set.

Apps should be setting both bpp and preferred rgba.  Apps which use 
garbage rgba (f.e. they ask for 32bit 1:5:5:5 when they are switching 
framebuffer from depth == 15 to depth == 32) should get "best" suitable 
format, which I tried to express above by green.length tests (*).  Upon 
successful mode set rgba must be updated with choosen hardware 
configuration.
								Petr

(*) Maybe you could ignore rgba when sum of rgba lengths does not equal 
to bpp.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Geert Uytterhoeven]

On Fri, 5 Aug 2005, Jon Smirl wrote:
> The chips actually allow nine configs (maybe more when I get a look at
> the R300 doc). It is ambiguous to set these configs based on BPP since
> there are multiple configs for various BPP. These configs should
> instead be set with the transp/red/blue/green fields.
> 
> 4bpp Index = /4
> 8bpp Index = /8
> 16bpp aRGB 1555 = 1/5/5/5
> 16bpp RGB 565 = /5/6/5
> 16bpp aRGB 4444 = 4/4/4/4
> 16bpp aIndex 88 = 8/8
> 24bpp RGB 888 = /8/8/8
> 32bpp aRGB 8888 = 8/8/8/8
> 32bpp aRGB 2:10:10:10 = 2/10/10/10
> 
> What is the best way to fix this?

Just follow the FBIOPUT_VSCREENINFO rules:
  - If a value doesn't fit, round it up.
  - If rounding is impossible, return an error.

So if a user asks for e.g. bpp 16, transp.length = 1,
{red,green,blue}.length = 0, you can give him 1555 if your hardware supports
it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
(w.r.t. rounding). But you must not give him 565, since this implies you
rounded down transp.length.

> The interesting hidden config is 30b color.

Piece of cake!

    bpp = 32
    transp.length = 2, {red,green,blue}.length = 10

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Antonino A. Daplas]

Jon Smirl wrote:
> If I understand things correctly the framebuffer config is supposed to
> be controlled by the transp/red/blue/green fields of fb_var_screeninfo
> during check_var. These fields are then combined to compute the
> bits_per_pixel.
> 
> radeonfb is working from the other direction, it starts with bpp and
> then computes ARGB. This looks wrong to me.
> 

> 16bpp aIndex 88 = 8/8

Set argb.length = 8, rgb.offset = 0, t.offset = 8.
The transp.offset differentiates ARGB8 from A8_RGB8.

Tony 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Jon Smirl]

On 8/7/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, 5 Aug 2005, Jon Smirl wrote:
> > The chips actually allow nine configs (maybe more when I get a look at
> > the R300 doc). It is ambiguous to set these configs based on BPP since
> > there are multiple configs for various BPP. These configs should
> > instead be set with the transp/red/blue/green fields.
> >
> > 4bpp Index = /4
> > 8bpp Index = /8
> > 16bpp aRGB 1555 = 1/5/5/5
> > 16bpp RGB 565 = /5/6/5
> > 16bpp aRGB 4444 = 4/4/4/4
> > 16bpp aIndex 88 = 8/8
> > 24bpp RGB 888 = /8/8/8
> > 32bpp aRGB 8888 = 8/8/8/8
> > 32bpp aRGB 2:10:10:10 = 2/10/10/10
> >
> > What is the best way to fix this?
> 
> Just follow the FBIOPUT_VSCREENINFO rules:
>   - If a value doesn't fit, round it up.
>   - If rounding is impossible, return an error.
> 
> So if a user asks for e.g. bpp 16, transp.length = 1,
> {red,green,blue}.length = 0, you can give him 1555 if your hardware supports
> it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
> (w.r.t. rounding). But you must not give him 565, since this implies you
> rounded down transp.length.
> 
> > The interesting hidden config is 30b color.
> 
> Piece of cake!
> 
>     bpp = 32
>     transp.length = 2, {red,green,blue}.length = 10

The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.

Is this a general problem? Do a lot of drivers look at bpp and then
overwrite rgbt? If so I can look at putting better fixup code in base
fbdev and then remove the code that converts from bpp to rgbt in the
various drivers.

The basic problem is what happens if bpp and rgbt are set in
conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
should win? I think the config should always be controlled by rgbt and
bpp is read only and computed from rgbt. But fixing everything to work
that way may break some apps. radeonfb is definitely not working in
this manner.

Best fix would be for the core fbdev to zero out bpp before handing it
to check_par. That would force the chip drivers to compute it from
rgbt. Some of the chip drivers will probably need their code adjusted.
This may also break some apps since they are not setting rgbt.

So I guess the fallback position is leave this driver dependent. So
for the radeonfb case if you set bpp it will work like it always has.
I'll then fix radeonfb to look at rgbt if bpp = 0. rgbt with bpp=0
will then be able to select the other configs.

It would also be nice to build a string with the list of legal configs
into each driver. For radeon the string would contain: /4, /8,
1/5/5/5, /5/6/5, 4/4/4/4, 8/8, /8/8/8, 8/8/8/8, 2/10/10/10. This would
let me display the list of legal configs in sysfs.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Michel Dänzer]

On Sun, 2005-08-07 at 11:33 -0400, Jon Smirl wrote:
> On 8/7/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, 5 Aug 2005, Jon Smirl wrote:
> > > The chips actually allow nine configs (maybe more when I get a look at
> > > the R300 doc). It is ambiguous to set these configs based on BPP since
> > > there are multiple configs for various BPP. These configs should
> > > instead be set with the transp/red/blue/green fields.
> > >
> > > 4bpp Index = /4
> > > 8bpp Index = /8
> > > 16bpp aRGB 1555 = 1/5/5/5
> > > 16bpp RGB 565 = /5/6/5
> > > 16bpp aRGB 4444 = 4/4/4/4
> > > 16bpp aIndex 88 = 8/8
> > > 24bpp RGB 888 = /8/8/8
> > > 32bpp aRGB 8888 = 8/8/8/8
> > > 32bpp aRGB 2:10:10:10 = 2/10/10/10
> > >
> > > What is the best way to fix this?
> > 
> > Just follow the FBIOPUT_VSCREENINFO rules:
> >   - If a value doesn't fit, round it up.
> >   - If rounding is impossible, return an error.
> > 
> > So if a user asks for e.g. bpp 16, transp.length = 1,
> > {red,green,blue}.length = 0, you can give him 1555 if your hardware supports
> > it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
> > (w.r.t. rounding). But you must not give him 565, since this implies you
> > rounded down transp.length.
> > 
> > > The interesting hidden config is 30b color.
> > 
> > Piece of cake!
> > 
> >     bpp = 32
> >     transp.length = 2, {red,green,blue}.length = 10
> 
> The problem is that the radeonfb driver sees bpp = 32 and then sets
> rgbt = 8/8/8/8. It stomps rgbt without looking at it.

Looks like a radeonfb bug.


> The basic problem is what happens if bpp and rgbt are set in
> conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
> should win?

Read what you quoted from Geert above.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Benjamin Herrenschmidt]

> > The problem is that the radeonfb driver sees bpp = 32 and then sets
> > rgbt = 8/8/8/8. It stomps rgbt without looking at it.
> 
> Looks like a radeonfb bug.

It's not a bug :) radeonfb doesn't support anything but that format for
now. If you want to do something else, implement it :)
> 
> > The basic problem is what happens if bpp and rgbt are set in
> > conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
> > should win?
> 
> Read what you quoted from Geert above.
> 
> 



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Jon Smirl]

On 8/7/05, Michel Dänzer <michel@daenzer.net> wrote:
> On Sun, 2005-08-07 at 11:33 -0400, Jon Smirl wrote:
> > On 8/7/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Fri, 5 Aug 2005, Jon Smirl wrote:
> > > > The chips actually allow nine configs (maybe more when I get a look at
> > > > the R300 doc). It is ambiguous to set these configs based on BPP since
> > > > there are multiple configs for various BPP. These configs should
> > > > instead be set with the transp/red/blue/green fields.
> > > >
> > > > 4bpp Index = /4
> > > > 8bpp Index = /8
> > > > 16bpp aRGB 1555 = 1/5/5/5
> > > > 16bpp RGB 565 = /5/6/5
> > > > 16bpp aRGB 4444 = 4/4/4/4
> > > > 16bpp aIndex 88 = 8/8
> > > > 24bpp RGB 888 = /8/8/8
> > > > 32bpp aRGB 8888 = 8/8/8/8
> > > > 32bpp aRGB 2:10:10:10 = 2/10/10/10
> > > >
> > > > What is the best way to fix this?
> > >
> > > Just follow the FBIOPUT_VSCREENINFO rules:
> > >   - If a value doesn't fit, round it up.
> > >   - If rounding is impossible, return an error.
> > >
> > > So if a user asks for e.g. bpp 16, transp.length = 1,
> > > {red,green,blue}.length = 0, you can give him 1555 if your hardware supports
> > > it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
> > > (w.r.t. rounding). But you must not give him 565, since this implies you
> > > rounded down transp.length.
> > >
> > > > The interesting hidden config is 30b color.
> > >
> > > Piece of cake!
> > >
> > >     bpp = 32
> > >     transp.length = 2, {red,green,blue}.length = 10
> >
> > The problem is that the radeonfb driver sees bpp = 32 and then sets
> > rgbt = 8/8/8/8. It stomps rgbt without looking at it.
> 
> Looks like a radeonfb bug.
> 
> 
> > The basic problem is what happens if bpp and rgbt are set in
> > conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
> > should win?
> 
> Read what you quoted from Geert above.

I'm just verifying everything before changing things. Sometimes there
are disagreements on what rules we should be following.

So from Geert's rules 16bpp doesn't fit with 8/8/8/8 so round it up to
32bpp. Are we sure that is what applications are expecting to happen?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Michel Dänzer]

On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
> > > The problem is that the radeonfb driver sees bpp = 32 and then sets
> > > rgbt = 8/8/8/8. It stomps rgbt without looking at it.
> > 
> > Looks like a radeonfb bug.
> 
> It's not a bug :) radeonfb doesn't support anything but that format for
> now.

According to Geert's rules, it should fail instead of rounding down
r/g/b.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Jon Smirl]

On 8/7/05, Michel Dänzer <michel@daenzer.net> wrote:
> On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
> > > > The problem is that the radeonfb driver sees bpp = 32 and then sets
> > > > rgbt = 8/8/8/8. It stomps rgbt without looking at it.
> > >
> > > Looks like a radeonfb bug.
> >
> > It's not a bug :) radeonfb doesn't support anything but that format for
> > now.
> 
> According to Geert's rules, it should fail instead of rounding down
> r/g/b.

One problem with these rules is that it makes it hard to determine
what is the best config available. I can't just set in 255BPP and then
let it tell me the best available config.

What config should I get if everything is zero, BPP and rgbt?
According to the rules this is an error, should it instead return the
best config?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Geert Uytterhoeven]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1534 bytes --]

On Sun, 7 Aug 2005, Jon Smirl wrote:
> On 8/7/05, Michel Dänzer <michel@daenzer.net> wrote:
> > On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
> > > > > The problem is that the radeonfb driver sees bpp = 32 and then sets
> > > > > rgbt = 8/8/8/8. It stomps rgbt without looking at it.
> > > >
> > > > Looks like a radeonfb bug.
> > >
> > > It's not a bug :) radeonfb doesn't support anything but that format for
> > > now.
> > 
> > According to Geert's rules, it should fail instead of rounding down
> > r/g/b.

They are not really `my' rules, just the original fbdev rules from 1994.

> One problem with these rules is that it makes it hard to determine
> what is the best config available. I can't just set in 255BPP and then
> let it tell me the best available config.

Indeed. But you can more-or-less scan for modes.

> What config should I get if everything is zero, BPP and rgbt?
> According to the rules this is an error, should it instead return the
> best config?

It's not an error, since you can round up from 0.

It depends on your hardware.

Monochrome or pseudocolor 1 bpp, if the hardware supports it.
Or 32 bpp ARGB8888, if that's all the hardware does.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Choosing the correct framebuffer configuration

[Michel Dänzer]

On Sun, 2005-08-07 at 12:53 -0400, Jon Smirl wrote: 
> On 8/7/05, Michel Dänzer <michel@daenzer.net> wrote:
> > On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
> > > > > The problem is that the radeonfb driver sees bpp = 32 and then sets
> > > > > rgbt = 8/8/8/8. It stomps rgbt without looking at it.
> > > >
> > > > Looks like a radeonfb bug.
> > >
> > > It's not a bug :) radeonfb doesn't support anything but that format for
> > > now.
> > 
> > According to Geert's rules, it should fail instead of rounding down
> > r/g/b.
> 
> One problem with these rules is that it makes it hard to determine
> what is the best config available. I can't just set in 255BPP and then
> let it tell me the best available config.

If an app doesn't know its _minimum_ requirements, I doubt it wants 16
bits per component. If an app really needs the 'best' (how is that
defined?) config, it can try setting the best it supports and then lower
the requirements until it hits something that the driver supports.

> What config should I get if everything is zero, BPP and rgbt?
> According to the rules this is an error, 

I haven't seen such a rule, where is it?

> should it instead return the best config?

That sounds to me like the app doesn't care, so the driver can return
whatever it pleases.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Choosing the correct framebuffer configuration

[Antonino A. Daplas]

Jon Smirl wrote:
> On 8/7/05, Michel Dänzer <michel@daenzer.net> wrote:
>> On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
>>>>> The problem is that the radeonfb driver sees bpp = 32 and then sets
>>>>> rgbt = 8/8/8/8. It stomps rgbt without looking at it.
>>>> Looks like a radeonfb bug.
>>> It's not a bug :) radeonfb doesn't support anything but that format for
>>> now.
>> According to Geert's rules, it should fail instead of rounding down
>> r/g/b.
> 
> One problem with these rules is that it makes it hard to determine
> what is the best config available. I can't just set in 255BPP and then
> let it tell me the best available config.
> 
> What config should I get if everything is zero, BPP and rgbt?
> According to the rules this is an error, should it instead return the
> best config?
> 

Rule is you can round-up but not round-down.

If bpp = 255, error.
If bpp = 0, return the nearest config ie, bpp8, argb8.

Also, drivers look at bpp first. Then it only looks at argb if there are
more than one format per bpp.  That's what most user apps expect.


Tony



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf