nanogui: More...Porting to a custom video device
Subject:
Re: [nanogui] More...Porting to a custom video device
From:
Jordan Crouse ####@####.####
Date:
29 May 2001 14:34:18 -0000
Message-Id: <01052908315900.03705@cosmic>
> Sorry for my ignorance but I would like to ask what actually happens if I
> use virtual frame buffer and draw just a short line on it. My guess is that
> since the framebuffer driver has no means to determine what was changed, it
> has to send the whole image to the graphic display again?
That depends on how the system is set up. In most of the CRT based systems i
have worked with (PCI or AGP based), the card has enough memory and
intellegence to provide a complete window of video memory that the kernel can
read/write to. Then the internal card hardware would handle the video sync.
I think it is a little bit more complex for flat screens, but once again, all
of the cards I have worked with have been fairly new, so they could handle
most of the pain and suffering.
> In my opinion framebufers are OK, if the actual physical memory of graphic
> card is mapped. If not, then something has to keep the memory and display
> in sync and this can be very costly. Am I right?
You are correct. Remember this only applies to a standard PCI/AGP video
card. When you start dealing with devices like the LCD, then there are alot
of other factors at play.
> And speaking about nice kernel interfaces - what about vgaplan4.{c,h}? Why
> VGA planes were not abstracted in framebuffer kernel driver?
Ugh. Why do VGA planes when you can just go linear?
> I have a card that is VESA 1.2, but not 2.0 so it can not be called from
> Linux. Also its framebuffer can not be fitted into 64 KB. So what remains -
> mapping 64KB out of available 512 KB directly and using page fault handler
> to switch to the other planes? I think it is really easier to implement
> get/set pixel, and simple draw line and blit routines than to worry about
> managing virtual framebuffer.
Does your video card have attached memory? There is nothing that says that
you must use the standard 64K window, in fact, most modern kernel framebuffer
drivers don't (except for VESA).
Even if you don't have attached memory, your video card should provide a way
for you to switch planes, and not have to worry about something painful like
a page fault handler. It is always best to use the card to its full
advantage (thats why its there, right?)
Also, you need to remember that routines like get/set pixel and lines are not
the kernel responsibility. The kernel can only map memory and read/write
from it. Any upper level drawing must be the domain of the graphics engine
(thus, Microwindows).
Blit is a little different, becuase the kernel has an abstraction for those
boards that provide hardware blit.
Jordan
