Page 1 of 1
vbe2.0 linear framebuffer in the land of paged memory...
Posted: Sun Aug 24, 2003 2:39 pm
by distantvoices
HO HO HO ... says the hogfather...
I ask for some suggestions: How in heavens name shall I map the framebuffer into every process' adress space? Have a location in the process structure (bool frame_buffer_mapped) and map the region into the adress space as soon as the process is activated - and the frame buffer location is known? I am definitely not happy having to map something at the very beginning of paging as framebuffer location. (is it possible to assign the video card a framebuffer location?
the second: On my laptop, my kernel craps out. on any pc, it runs fine and smooth and sweet, even the vm86 process is jumpy and happy. Not so on the laptop: Many problems, and it doesn't even has hundreds of legs (rincewind of course wouldn't be afraid...)
Why?
Re:vbe2.0 linear framebuffer in the land of paged memory...
Posted: Sun Aug 24, 2003 10:08 pm
by K.J.
As for the first, it sounds like you want each and every program to have direct access to the video memory. You could map the memory into every process via copying part of a memory map, or perhaps a better idea would be to create a simple little driver that handles the memory, and processes just send info to it(draw a line, draw a pixel, put some text, etc) to draw. This not only means you won't have to copy part of a memory map, but that each program won't need it's own library of video functions.
K.J.
Re:vbe2.0 linear framebuffer in the land of paged memory...
Posted: Mon Aug 25, 2003 5:03 am
by Pype.Clicker
if what you want to effectively have is a video area for each process in which it can read and write at will and then apply the changes to the on-screen image, you can give each process a non-video (or in-video but offscreen) buffer and then bitblt modified pages on-screen at refresh requests.
Giving process a 'real' access to video memory tends to mean that there'll be a non-0 risk that display is corrupted by a single misbehaved application.
Of course, if you want the *kernel* to access video memory from any process, just map the physical memory of your framebuffer in each process with supervisor priviledges (i.e. impossible to read/write from user mode).
A special case of screen splitting that allow several process to access vram directly is the horizontal split, provided that you split on an integer amount of the page size (works fine with 1024x768x32 : one line==one page :p ). You could for instance have a "full screen" program but still keeping the control of the menubar by making the lines of the menubar unavailable to the fullscreen prog.
Re:vbe2.0 linear framebuffer in the land of paged memory...
Posted: Mon Aug 25, 2003 6:45 am
by Perica
..
Re:vbe2.0 linear framebuffer in the land of paged memory...
Posted: Mon Aug 25, 2003 7:09 am
by Pype.Clicker
answering this goes beyond my knowledge of PCI programming, but iirc, PCI enforce that memory regions are 2**N and are aligned on 2**N boundaries.
The question remains open in case of multi-screen video memory, but i would say that if you can select the on-screen offset, nothing should prevent you from stating you don't care about video memory between "frame_buffer" and "align(0xfff,frame_buffer)" ...
Re:vbe2.0 linear framebuffer in the land of paged memory...
Posted: Mon Aug 25, 2003 1:52 pm
by distantvoices
hm. I Have a Video driver which is responsible for handling screenthings (and keyboard things in the meantime til i come up with a better design). This video driver is executed in the kernel land of paging - and since each of my processes has an own page directory - what is not mapped in its adress space it can't do anything - so no display.
No process has possibilitiy to access devices directly in my kernel.
thanks for your replys.