nanogui: More...Porting to a custom video device
Subject:
Re: [nanogui] More...Porting to a custom video device
From:
tomasz motylewski ####@####.####
Date:
29 May 2001 12:53:27 -0000
Message-Id: <Pine.LNX.4.21.0105291420070.14639-100000@mailserver.intern.bfad.de>
> > microwindows that just dumps the display to a block of ram and then have a
> > daemon running that snags that block of ram and shovel it to the device....
>
> I would just shove it out to the device. As long as you have the palette
> correctly set, Microwindows will deliver the screen data in 1 bpp format, so
> in theory, you could just shove it out on the line and go. No need even to
> have another process running, unless you are worried about spending too much
> time pumping data out in in the driver.
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?
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?
And speaking about nice kernel interfaces - what about vgaplan4.{c,h}? Why VGA
planes were not abstracted in framebuffer kernel driver?
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.
Best regards,
--
Tomasz Motylewski
BFAD GmbH & Co. KG
