nanogui: Running document -- RTEMS framebuffer interface specification
Subject:
Re: Running document -- RTEMS framebuffer interface specification
From:
Rosimildo daSilva ####@####.####
Date:
11 Feb 2000 15:43:31 -0000
Message-Id: <200002111532.HAA17783@www2.xoommail.com>
"Greg Haerr" wrote:
> : I have compiled the code of our interface, and wrote a "skeleton"
> : driver for RTEMS ( it actually compiles ) along with the MicroWindows
> : glue ( Micro FrameBuffer ) discussed in the past few weeks.
> : Before I finalize the tests, and package it as a "patch", I would
> : appreacite any feedback. I have added the sources as links in the
> : document on the link below.
>
> I have looked over all your source and it looks great. You will
> of course have to link in ega_hwinit and ega_hwterm into the kernel...
>
First, thanks.
Yes. That's the plan. I'll move this routines to the kernel.
> Your code also assumes that there is the same address space between
> kernel and user modes for the framebuffer. I don't know if that's the best
> idea or not. But I guess you will always pass this address in
> fbinfo.smem_start?
>
Yes, the physucal address is passed. This would work ok with RTEMS today.
Peharps, we should have another function to map the address to user
space, and the for RTEMS it just just returns the same pointer.
Signature:
int ufb_map_fb_buffer( void **usr_addr, void *physical_addr, size_t size )
{
#if __rtems__
*usr_addr = physical_addr;
return 0;
#else
/* do whatever for your kernel, paharps call mmap() */
return 0;
#endif
}
Regarding the integration with Microwindows code, there is a preprocessor
flag FRAMEBUFFER used in some modules. Now we need to diferenciate the
"linux framebuffer" from ours "micro framebuffer" or peharps "embedded
framebuffer". Any ideas how we should do this ?
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
