nanogui: Thread: Images resolution

Hi,

Is there anything I can do, to improve the resolution of an
image. ? I am using the "bios VGA" driver, and the image of
the "car" on the microwindows demo sucks big time. I guess
that must be some color/resolution thing that is not been
configured correctly.

Rosimildo.


Thanks,
Rosimildo

______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: Is there anything I can do, to improve the resolution of an
: image. ? I am using the "bios VGA" driver, and the image of
: the "car" on the microwindows demo sucks big time. I guess
: that must be some color/resolution thing that is not been
: configured correctly.

I'm not sure if your problem is pixel resolution or color resolution.
The car will look fine at 640x480, but you've got to be running
a 256 color palette mode, or a truecolor mode that supports
at least about 250 colors, or the car's image will degrade.

As I think about it, you're probably running RTEMS Microwindows,
which uses the hardware scr_bios.c driver.  This driver _doesn't_
implement the setpalette() driver function, but instead runs in
the VGA default 16 color mode.  So all your colors are ugly.
The reason this works at all is that your driver returns ncolors=16,
and the first 16 colors of the 256 color palette basically match
the std VGA colors, so the Microwindows color-reduction
algorithm basically maps image colors to the right values.

The fix is somewhat hard: the std VGA runs in max 640x480x16
colors, without special programming.  The extended programming
depends on the chipset.  We may need grab some libraries
like GRX or SVGA and write special chipset-specific drivers
to get the 256 color modes.  What we really need is the GRX 
package ported to RTEMS or DOS.

Regards,

Greg

"Greg Haerr" wrote:
 > : Is there anything I can do, to improve the resolution of an
 > : image. ? I am using the "bios VGA" driver, and the image of
 > : the "car" on the microwindows demo sucks big time. I guess
 > : that must be some color/resolution thing that is not been
 > : configured correctly.
 > 
 > I'm not sure if your problem is pixel resolution or color resolution.
 > The car will look fine at 640x480, but you've got to be running
 > a 256 color palette mode, or a truecolor mode that supports
 > at least about 250 colors, or the car's image will degrade.
 > 
 > As I think about it, you're probably running RTEMS Microwindows,
 > which uses the hardware scr_bios.c driver.  This driver _doesn't_
 > implement the setpalette() driver function, but instead runs in
 > the VGA default 16 color mode.  So all your colors are ugly.
 > The reason this works at all is that your driver returns ncolors=16,
 > and the first 16 colors of the 256 color palette basically match
 > the std VGA colors, so the Microwindows color-reduction
 > algorithm basically maps image colors to the right values.
 > 
 > The fix is somewhat hard: the std VGA runs in max 640x480x16
 > colors, without special programming.  The extended programming
 > depends on the chipset.  We may need grab some libraries
 > like GRX or SVGA and write special chipset-specific drivers
 > to get the 256 color modes.  What we really need is the GRX 
 > package ported to RTEMS or DOS.
 > 

You right. It must be color resolution. Somehow I knew that
it would not be easy. :-).

I'll try to messy around with GRX, do you have a point ?.
Unfortunately, my knowledge of graphics/chipsets is 
pretty limited.

BTW, I liked the new "build structure" that you guys
came up with. I hope to get RTEMS compiling again. :-).


Rosimildo.









______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

"Greg Haerr" wrote:
 > 
 > As I think about it, you're probably running RTEMS Microwindows,
 > which uses the hardware scr_bios.c driver.  This driver _doesn't_
 > implement the setpalette() driver function, but instead runs in
 > the VGA default 16 color mode.  So all your colors are ugly.
 > The reason this works at all is that your driver returns ncolors=16,
 > and the first 16 colors of the 256 color palette basically match
 > the std VGA colors, so the Microwindows color-reduction
 > algorithm basically maps image colors to the right values.
 > 
 > The fix is somewhat hard: the std VGA runs in max 640x480x16
 > colors, without special programming.  The extended programming
 > depends on the chipset.  We may need grab some libraries
 > like GRX or SVGA and write special chipset-specific drivers
 > to get the 256 color modes.  What we really need is the GRX 
 > package ported to RTEMS or DOS.
 > 

Greg,

I have looked at:

 + Linux SVGA
 + GRX

graphics library last night. 

They're somewhat large, but possible of being ported to RTEMS. 
If anybody with more "graphics" experience than me, 
could post some pros and cons of each library, I would appreciated.

I've got the impression that the Linux SVGA would be easier to port.

I am looking for the strenghts and weaknesses of each one.

Rosimildo.













______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: I have looked at:
: 
:  + Linux SVGA
:  + GRX
: 
: graphics library last night. 
: 
: They're somewhat large, but possible of being ported to RTEMS. 
: If anybody with more "graphics" experience than me, 
: could post some pros and cons of each library, I would appreciated.
: 
: I've got the impression that the Linux SVGA would be easier to port.

The GRX library runs on top of DOS, which is closer to the hardware.
The SVGAlib library is based mostly as a user mode app, and probably
requires mmap(), right?

Greg

"Greg Haerr" wrote:
 > : I have looked at:
 > : 
 > :  + Linux SVGA
 > :  + GRX
 > : 
 > : graphics library last night. 
 > : 
 > : They're somewhat large, but possible of being ported to RTEMS. 
 > : If anybody with more "graphics" experience than me, 
 > : could post some pros and cons of each library, I would appreciated.
 > : 
 > : I've got the impression that the Linux SVGA would be easier to port.
 > 
 > The GRX library runs on top of DOS, which is closer to the hardware.
 > The SVGAlib library is based mostly as a user mode app, and probably
 > requires mmap(), right?
 > 
 > Greg
 
Yes, but it is easy to "emulate" this call. IIRC, RTEMS already 
supports it. RTEMS being a POSIX based RTOS "match" better with
Linux code. 

I was just wondering about the benefits of porting either one in the
long run. 

  + which one has large development community
  + availability of drivers
  + applications


How about Linux Frame Buffer ( FB ) ?
Is there any advantage of it over SVGA ?

Rosimildo.












______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

Rosimildo daSilva wrote:
> 
> "Greg Haerr" wrote:
>  > : I have looked at:
>  > :
>  > :  + Linux SVGA
>  > :  + GRX
>  > :
>  > : graphics library last night.
>  > :
>  > : They're somewhat large, but possible of being ported to RTEMS.
>  > : If anybody with more "graphics" experience than me,
>  > : could post some pros and cons of each library, I would appreciated.
>  > :
>  > : I've got the impression that the Linux SVGA would be easier to port.
>  >
>  > The GRX library runs on top of DOS, which is closer to the hardware.
>  > The SVGAlib library is based mostly as a user mode app, and probably
>  > requires mmap(), right?
>  >
>  > Greg
> 
> Yes, but it is easy to "emulate" this call. IIRC, RTEMS already
> supports it. RTEMS being a POSIX based RTOS "match" better with
> Linux code.
> 

I do not think POSIX is something which extends to this level. RTEMS
also have other API's which people use and need to be supported.

RTEMS does not have an mmap call. Are you going to add an mmap call ?

> I was just wondering about the benefits of porting either one in the
> long run.
> 
>   + which one has large development community
>   + availability of drivers
>   + applications
> 
> How about Linux Frame Buffer ( FB ) ?
> Is there any advantage of it over SVGA ?
> 

Please consider Linux code very carefully. Code which is GPL cannot be
included in RTEMS.

Is it possible to have the RTEMS parts which are specific to the PC
Board Support Package (BSP) defined under RTEMS_PC rather than just
RTEMS ?

-- 
 Chris Johns, ####@####.####

Chris Johns wrote:
 > Rosimildo daSilva wrote:
 > > 
 > > "Greg Haerr" wrote:
 > >  > : I have looked at:
 > >  > :
 > >  > :  + Linux SVGA
 > >  > :  + GRX
 > >  > :
 > >  > : graphics library last night.
 > >  > :
 > >  > : They're somewhat large, but possible of being ported to RTEMS.
 > >  > : If anybody with more "graphics" experience than me,
 > >  > : could post some pros and cons of each library, I would appreciated.
 > >  > :
 > >  > : I've got the impression that the Linux SVGA would be easier to port.
 > >  >
 > >  > The GRX library runs on top of DOS, which is closer to the hardware.
 > >  > The SVGAlib library is based mostly as a user mode app, and probably
 > >  > requires mmap(), right?
 > >  >
 > >  > Greg
 > > 
 > > Yes, but it is easy to "emulate" this call. IIRC, RTEMS already
 > > supports it. RTEMS being a POSIX based RTOS "match" better with
 > > Linux code.
 > > 
 > 
 > I do not think POSIX is something which extends to this level. RTEMS
 > also have other API's which people use and need to be supported.
 > 
 > RTEMS does not have an mmap call. Are you going to add an mmap call ?
 > 

Not at this point. Unless we as community feel that there is
need for such a call.

At this point I am trying to edudate myself about the possibilities
that we have out there. 


 > > I was just wondering about the benefits of porting either one in the
 > > long run.
 > > 
 > >   + which one has large development community
 > >   + availability of drivers
 > >   + applications
 > > 
 > > How about Linux Frame Buffer ( FB ) ?
 > > Is there any advantage of it over SVGA ?
 > > 
 > 
 > Please consider Linux code very carefully. Code which is GPL cannot be
 > included in RTEMS.

Thanks for the advise.

 > 
 > Is it possible to have the RTEMS parts which are specific to the PC
 > Board Support Package (BSP) defined under RTEMS_PC rather than just
 > RTEMS ?

Absolutely. Please advise how you'd think it should be,
and I'll try to adjust for *our* needs.

Chris,

I know you contribute a lot for the RTEMS community,
So, are you using MicroWindows with RTEMS, or you did not
have a chance to try it out. ?

Rosimildo.




______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

Rosimildo daSilva wrote:
> 
> Not at this point. Unless we as community feel that there is
> need for such a call.
> 
> At this point I am trying to edudate myself about the possibilities
> that we have out there.
> 

My, very limited, understanding is VM is needed. VM support has been
talked about, how-ever my feeling is other issues are needed in RTEMS
first. Others how-ever might not agree.

> 
> Absolutely. Please advise how you'd think it should be,
> and I'll try to adjust for *our* needs.
> 

I will take this off-line so we can resolve it. It was your post on the
RTEMS lists that got me interested, so thanks.

> 
> I know you contribute a lot for the RTEMS community,
> So, are you using MicroWindows with RTEMS, or you did not
> have a chance to try it out. ?
> 

I have an embedded Linux project underway at the moment. This is using
the FB driver code in Linux. I have code in the pipeline for full
support of user registered fd's for select, as well as a basic C++ frame
work. They need more testing before releasing.

Our plans are for the system to be ported to RTEMS. The hardware is
still to be decided. The embedded nature of MicroWindows is a great
feature.

-- 
 Chris Johns, ####@####.####

: How about Linux Frame Buffer ( FB ) ?
: Is there any advantage of it over SVGA ?

Heck yes!  That's what Microwindows and Nano-X are all about!

The fb drivers allow simple cool code to be written that can draw
directly on the display surface.  This display surface is still linear
even in the smaller Linux PDAs.  SVGAlib is a library that handles
all the horrors (non-linear aspects) of the VGA cards, and programs
that use it can't touch the screen directly.

Greg