Results 1 to 7 of 7
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Apr 2008
what control the output to the monitor?
So anyway, when an application wants to display some text or a picture in a window, does X tell the kernel that this text / picture should be drawn? Or does X directly control the drivers of the hardware telling it what to do? From what I've understood, I would think the former is correct.. However, I want to confirm this.
If so, when I open up a virtual terminal (not a terminal emulator...but by using Ctrl + Alt + Fn ) is the text there drawn by the kernel (by using the drivers)?
The kernel and X cooperate. Or maybe better to say they coexist.
It is indeed not alway easy to tell who is responsible for what. And there is work undergoing transferring responsibilities from X to the kernel (Kernel Based Modesetting).
But the current situation is this:
The Xserver receives draw requests from the (userspace) client application.
"Draw a blue rectangle in the window $ID at position $XYHW."
The XServer may be the local workstation or it may be some other computer across the network.
The responsible XServer has some driver modules loaded in. For example a simple unaccelerated VESA driver or the RADEON driver for ATI accelerator cards.
When loaded, the graphics driver told the XServer "If you want me to draw a rectangle, call this vesa_draw_rectangle function."
So the XServer does just that.
The driver in turn knows how to talk to the graphics adapter hardware. It writes specific sequences of bytes to the hardware. For Vesa it would write a block of numbers directly to the framebuffer memory, which forms the picture you see on the screen. But this is slow and therefore, for RADEON, it invokes commands on the GPU on the graphics card to do this (faster).
But not all drivers can talk to the hardware at the same time. There has to be some sort of access control. This is where the kernel comes in. It delegates the commands of the driver to the actual hardware in an orderly queue.
So you see its quite an interplay.
And it gets worse if DRI and GLX enter the field
The above is the situation for the graphics system X11 (aka Ctrl + Alt + F7).
The console driver does not need the XWindow system. All X and the driver has to do is to step aside correctly, restoring the state it found when it was started.
Linux has some built in drivers that know how to do the text mode. More precisely, there are two cases:
a) The Linux framebuffer device. This is a simple graphics mode. The text is created from pixels and therefore pretty slow. On the upside, you can make arbitrarily looking fonts and even display images (like the penguin at boot).
b) The pure text mode. In this mode you tell the graphics card which characters are to be displayed. As you don't have to build your own fonts, this mode is pretty fast and easy to use, but less flexible.
- Join Date
- Apr 2008
I must say... that's a great post.
However, I have some questions..
If X is what calls the drivers, how can linux show text on the screen when Xserver it not running?
When you were explaining the text mode, you said " Linux has some built in drivers that know how to do the text mode." Does that mean that the kernel (cos it's the core of linux) knows how to draw text on the screen? This is related to my first question.. .
The X11 drivers need access to the hardware which is provided by the kernel.
But the drivers in Linux for the console do not depend on the X11 drivers.
The kernel can do it completely on its own.
(Linux is the kernel, btw. The operating system is a combination of unix-like userspace applications (GNU project) and the kernel, therefore better referred to as GNU/Linux in order to avoid mix-ups.)
But you wouldn't need anything other than the kernel Linux for just displaying text. No XServer nor a shell interpreter. Note how there appears text on the screen as early as the kernel bootup, this is long before X gets loaded.
Here you can see the text mode driver for two common display adapters in Linux.
Setting of cursor position, putting characters etc.
Last edited by GNU-Fan; 12-20-2009 at 05:51 PM.
- Join Date
- Apr 2008
I though all drivers were accessed by the kernel. In other words, I though that when an application wanted something done, it would send a message to the kernel which would in turn figure out what the hardware needs to do and call certain functions in the drivers to make the underlying hardware do what is required.
Now, in the part of your post I quoted, when you say "X11 drivers" do you mean that there are hardware drivers which can be accessed directly by the X11?
Here's a small diagram of what I'm thinking of..
Is the red arrow the path that you are suggesting?
PS (thanks again for a very good post.)
It is hard to explain, I guess. Your red path still needs the "approval" from the kernel to reach the hardware, but is mostly free in what the content of the data stream is.
The problem is that we have to differ between ordinary X11 video drivers, KBM and DRI.
The first needs to have the fewest model specific code in the kernel, the third needs quite a lot (I roughly estimate for DRI 70% in the XDriver+Mesa and 30% in Linux for a given graphic card model, just to give you an idea).
Let's take an specific example for the ordinary X11 driver model, which does not rely much on the kernel (so it can run on FreeBSD, NetBSD, ... as well).
Assume we want to disable the video signal of a VGA compatible graphics adapter (as a cheap screen/power saver).
To do so, we have to set the 5th bit of the "Clocking Mode Register (Index 01h)".
VGA/SVGA Video Programming--Sequencer Registers
This is achieved by writing one byte (01h) to hardware port "3C4h" and another byte to the hardware port 3C5h.
Putting bytes to hardware ports is considered privileged access to the hardware. An root userspace application, like XOrg, would use the system function outb(2): port I/O - Linux man page to do this.
So the knowledge what bytes have to be written to the ports resides in the ordinary X11 driver. But what outb actually does is kernel's responsibility again.
But again, its a bit hard to explain who does what, as with KBM process is undergoing to move more responsibility to the kernel right now.
The best way is maybe to play around a bit with the actual graphics driver code you use.
- Join Date
- Apr 2008
I think I'll leave it at that.. Thanks for your help..