Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hello everyone,
I would like to study the low level graphic drivers of the kernel, where the cursor is controlled and where it puts each and every character on the screen and moves the cursor one character forward.
Kernel doesn't have graphics and windows, but it shows a screen and command line. where does it control all this. which fonts does it use? what are font size limitations? where are the font files?
I am not into programming new graphics. I want to hack around with the linux kernel a bit. I found many articles about programming high level graphics.
If you can send me some links to related tutorials and how tos would be great.
Thanks in advance.
Nickew
Last edited by Nickew; 05-31-2011 at 07:30 PM.
Reason: I learned more about kernel and I corrected my question.
Graphics of the sort you are referring to is generally done in the X server. The X server is a layer between the graphic kernel driver, which doesn't know about characters and cursors, and userspace applications. The lowest level drivers are the glue layer between the X server and the graphics hardware. Usually, as I understand it, the driver exposes a block of memory which maps to screen pixels according to the spacial and color resolution in use. There is also the framebuffer interface supported by most drivers, which has a VESA standardized interface to which you can interface with userspace applications. There is also an X server driver which can use the framebuffer as its access to the video hardware.
As I understand it, there is precious little for hacking in graphics drivers, as the driver are not always open source. The Xorg sources should be fully open for your perusal and scrutiny.
Thanks Rod, I understand a bit more and I have changed my questions !
Can you give me more tips, thanks again.
Quote:
Originally Posted by theNbomr
Graphics of the sort you are referring to is generally done in the X server. The X server is a layer between the graphic kernel driver, which doesn't know about characters and cursors, and userspace applications. The lowest level drivers are the glue layer between the X server and the graphics hardware. Usually, as I understand it, the driver exposes a block of memory which maps to screen pixels according to the spacial and color resolution in use. There is also the framebuffer interface supported by most drivers, which has a VESA standardized interface to which you can interface with userspace applications. There is also an X server driver which can use the framebuffer as its access to the video hardware.
As I understand it, there is precious little for hacking in graphics drivers, as the driver are not always open source. The Xorg sources should be fully open for your perusal and scrutiny.
Do you mean that you are interested in non-graphical video; ie. text-mode? That is mostly done in the video hardware. The video hardware has a standard text mode that is the default on boot, and is used by the BIOS and other low-level code to put text and text-mode attributes such as foreground and background color & emphasis to a matrix of character cells on the screen. It can be accessed through standard BIOS calls, and also by writing directly to an area of real-mode memory that maps character cells in the row/column arrangement. The font used is built into the video BIOS of the video card, and is referred to as a character generator. In text-mode, the graphics card also controls the cursor position, as well as providing some control over the shape, color and blinking attributes.
Manipulating the text-mode screen was a very common practice in the days of MS-DOS when full access to the machine hardware was possible, and was required to achieve the best performance of application software. In Linux, there is very very little purpose for using such direct access to the hardware.
--- rod.
Thanks for the explanations. Now, if I make changes to the graphic driver or the BIOS, like changing the direction, will that also effect the Xwindows graphics.
There are programs for MS-Windows which flip the screen upside down (how can I do the same in Linux)?
Quote:
Originally Posted by theNbomr
Do you mean that you are interested in non-graphical video; ie. text-mode? That is mostly done in the video hardware. The video hardware has a standard text mode that is the default on boot, and is used by the BIOS and other low-level code to put text and text-mode attributes such as foreground and background color & emphasis to a matrix of character cells on the screen. It can be accessed through standard BIOS calls, and also by writing directly to an area of real-mode memory that maps character cells in the row/column arrangement. The font used is built into the video BIOS of the video card, and is referred to as a character generator. In text-mode, the graphics card also controls the cursor position, as well as providing some control over the shape, color and blinking attributes.
Manipulating the text-mode screen was a very common practice in the days of MS-DOS when full access to the machine hardware was possible, and was required to achieve the best performance of application software. In Linux, there is very very little purpose for using such direct access to the hardware.
--- rod.
The BIOS will not affect the X server, and is mostly immutable, anyway. I'm not sure what you mean by 'changing the direction' (change orientation?). There is an X module 'randr' which is used to do resize and rotate operations. I don't know if it can be used to flip the server on either horizontal or vertical planes.
I know that graphics all work based on a memory map. so there is a memory section either shared on the RAM or the dedicated RAM of the graphic card which has all the pixels on the screen.
How can access that RAM to change the directions?
I need to modify either the way it writes to the mamory or when it reads it to the screen. If I can access and control that memory then I got half of what I want.
The other half is where are the fonts (on BIOS, on Graphic BIOS, ...), I need add and make changes there as well.
Thanks a million for your help.
PS: If you show me data sheets, tutorials or similars, I will gladly read them.
Do you want to do this using X? If so, you would have to go through some X server API calls (as I mentioned previously, there is the standard randr extension that provides this functionality). The kernel driver for each make/model of video card will probably expose some standard interface that X servers use to gain access to the video card functions. I'm sorry that I can't explain any of the details of this. I don't think you will be able to access video memory in any way that will be coordinated with the X server unless you actually use the X server to do the work.
Fonts are stored in files on disk, and interpreted by the X server at runtime. X client applications tell the X server what fonts they want to use, and the X server uses a font server (xfs) to fetch them. For a normal desktop setting, the font server is built in to the local X server is running. Optionally, you can have a network font server, where fonts are downloaded to the X server from a remote host. You can see what fonts are available to the currently used X server (as indicated by $DISPLAY) with the xlsfonts tool. The font server loads fonts from disk using a somewhat complex system of pre-processing and configuration that includes provision for font-name aliasing, compression and naming conventions. Configuration of X fonts is a tricky subject and is too big to explain in this forum (a cop-out, because I've never been able to fully understand it. :-) ). Google is your friend on this subject.
As I said earlier, there is also a basic bitmap font embedded in the video BIOS ROM which defines a font that is used only in text mode. This is not used by X, and is not normally available in any sense by userspace Linux applications.
--- rod.
Are you telling me that I don't need to learn vedio device driver development to access the memory map and make effects there?
Are you saying that it can be done at Xserver level as well.
Does the Xserver has something similar to memeory map or it writes directly to the memory of the graphic card using some vedio driver functionality?
Thanks
I am saying that you can access video memory either through the X server or directly through the interface exposed by the driver. Not both concurrently. It is fairly unusual to program directly at the X level these days (it tends to be wrapped in higher level APIs like Qt, GTK, Motif, etc) but I'm sure there is a way to access the X server using a bitmap oriented paradigm. This will not work well (probably not at all) in the way you seem to want on a system that has an X-based desktop or window manager already running.
To get a better base-level understanding of X, and how it fits into to the picture, you should do a bit of reading. A good starting point would be On-line X programming tutorials.
Your whole line of questions seem to hover around the divisions between the various layers that are involved in rendering graphics on a computer monitor in a typical desktop Linux architecture. One breakdown of this layered approach would be, from lowest level to highest level:
Hardware
Kernel driver
X server
Other wrapper (Qt, GTK, GL, Motif, etc)
The upshot of this layered approach is that for the most part, if you use any lower level layer to generate graphics, it will almost certainly be in conflict with the layers above. The flow of control of the video subsystem is intended to start at one top level layer. You cannot have an X server controlling the video subsystem, and then inject your own functionality at some lower level in any coordinated way. Working your way up the stack will provide progressively easier and more standardized ways to accomplish rendering of graphics on the screen. The price that you pay for that is that you surrender exclusive control to the layer providing the service.
I think I go for the kernel driver. The question is, " can I change the orientation and the direction (flipping upside down or even rotating the screen at this level?"
I have the feeling that it should probably using an interface provided by the hardware layer and give the characters' bitmaps and doesn't bother if the screen is upside down, am I right? if yes, then again I have to learn the driver of the hardware? right?
If you are going to be using a kernel driver to set the orientation of the screen, your driver will have to be responsible for all of what is on the screen, so your driver can put it in whatever orientation you choose.
Yes, you will need to learn all of the details of operation for each type of hardware you want to create a driver for.
--- rod.
I don't want to write a new kernel driver. I want to use what is availabe and modify very little so that everything stays intact in terms of compatibility with the over all system and to other high level programs.
so, I would like to know, what functionalities kernel uses form the lower level hardware and what does kernel offer to higher levels? and where are the codes related to this in the kernel source code?
I don't want to write a new kernel driver. I want to use what is availabe and modify very little so that everything stays intact in terms of compatibility with the over all system and to other high level programs.
Strategically, that makes sense. In practice, I can't see it working without modifying X as well.
Quote:
so, I would like to know, what functionalities kernel uses form the lower level hardware and what does kernel offer to higher levels? and where are the codes related to this in the kernel source code?
The best way to determine how to access the hardware is to dig into the code. It is in
linux-x.x.x/drivers/video/...
Drivers are by definition hardware dependent, so there really isn't a single correct answer.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.