vt.c direct screen buffer access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  Hello,

  I have a couple of questions about the console layer.   Specifically, I'm
a little confused in regards to how it maintains the frame buffer for each
virtual console in vt.c.  It seems to me that vc_screenbuf is an internal
representation of the active frame buffer.  On a VGA system, this just
points into VRAM and vt.c is actually directly modifying VGA memory in a 
number of places via scr_writew.  So I guess it is just a happy coincidence
that the screenbuf format and VGA's text mode format are the same, and as
a result vt.c directly modifies VGA vram with scr_writew in a few places.
On other types of displays, presumably screenbuf just points somewhere in
normal RAM which is then rendered by the low-level console driver into
something that the hardware will understand.

  Is this right? Is this why vgacon doesn't need to implement putc? Is this
done as a speed hack to avoid having to copy bytes around unnecessarily, or
is it just how things evolved? I.E. would there be a big downside to moving
the framebuffer out of VGA VRAM if it became necessary to implement a few
features I'm thinking about? I would think not since fbcon already has a 
lot more overhead than that to put text on the screen.  The idea of vt.c
writing directly to VGA VRAM seems a little bit ugly, so I just wanted to
make sure I was understanding everything correctly.  

  Thanks,
  Steve.

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux