nanogui: Running document -- RTEMS framebuffer interface specification


Previous by date: 11 Feb 2000 18:16:57 -0000 Re: Running document -- RTEMS framebuffer interface specification, Frank W. Miller
Next by date: 11 Feb 2000 18:16:57 -0000 Microwindows 0.87 released, Greg Haerr
Previous in thread: 11 Feb 2000 18:16:57 -0000 Re: Running document -- RTEMS framebuffer interface specification, Frank W. Miller
Next in thread:

Subject: RE: Running document -- RTEMS framebuffer interface specificatio n
From: Greg Haerr ####@####.####
Date: 11 Feb 2000 18:16:57 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB055105@SYS.CenSoft.COM>

Was just thinking a bit now about the framebuffer concept in general.
:So, in Linux, the video memory is mapped into the process 
:address apce?  What
:about protection?  The user process can clobber any part of the
:frame buffer in addition to working with the part its responsible
:for.  This might be ok if the application is being granted the entire
:screen, like for  a game or something.  For a windowing system, its not
:as appealing.  Roadrunner/pk is going to have the same problem 
:as Linux.


No.  In linux, the video memory isn't mapped into the process
address space by default.

Instead, the /dev/fb0 fd is opened.  An ioctl get's the size of the
framebuffer.  Then, the mmap() system call is executed on that
fd to map the framebuffer for the specified size into the process
address space.

Ros' current design returns a valid user mode pointer to the 
video ram.  I suggested adding another entry point to allow
the operating system to map a separate physical address
into user mode, for operating systems that support
separate address mappings for kernel/user.

Greg

Previous by date: 11 Feb 2000 18:16:57 -0000 Re: Running document -- RTEMS framebuffer interface specification, Frank W. Miller
Next by date: 11 Feb 2000 18:16:57 -0000 Microwindows 0.87 released, Greg Haerr
Previous in thread: 11 Feb 2000 18:16:57 -0000 Re: Running document -- RTEMS framebuffer interface specification, Frank W. Miller
Next in thread:


Powered by ezmlm-browse 0.20.