Hi folks,
I've followed the discussion about the console code restructuring and
framebuffer devices (Generic VESA framebuffer driver and Video card
BOOT) and I'd like to present here my opinion.
That's how I think the device drivers should look like:
A graphics device driver consists of two parts, a kernel module and a
user-space library which are together the 'driver'. Only the user-space
library knows how to operate the device so there is no access to the
graphics device from the kernel.
The kernel module creates a character device which can be opened by any
application with the appropriate rights. The kernel module also
registeres the device to the kernel so the kernel knows which graphics
cards are present and their basic information (vendor, name etc.).
Since the kernel has no access to the device, no messages or text can be
displayed from the kernel, which I think is quite bad during
startup/boot, that's why the kernel module also provides a function for
displaying text. However, you don't want the kernel to draw text
messages to the display while you play doom3 :) , that's why this
drawing can be disabled (by init or somewhere in the early userspace
initialization).
An application which want's to use the device opens the character device
and gets the name of the user-space library (user-space driver part) and
loads it. The library has a set of functions (API) which can be used to
access the device. BTW, the user-space library API is OpenGL.
How the kernel and user-space driver part communicate is up to them (or
the programmer). There are no restrictions what to put into user-space
or kernel-space, may the device driver writer decide this. And there are
only two interfaces: one in the kernel (text drawing) and one in the
user-space (OpenGL), nothing between. So the driver can be optimized for
each specific chip, because each chip is different and is meant to be
accessed differently.
I don't like the framebuffer devices or even the DRI drivers because:
most applications use a 'high-level' API for rendering (OpenGL). These
'high-level commands' are translated to 'intermediate commands'
(framebuffer/DRI ioctl calls etc.) before being send to the card as
'low-level commands'. Why this intermediate layer?
Even if the high-level and intermediate commands are similar and you
don't loose much doing the translation (DRI), it is one too much. When
working with music you try to encode/decode your song as few times as
possible. because you loose quality each time (and it takes time). The
same applies to graphics commands, even if you might not loose quality
(I hope), but it is just unnecessary.
Maybe you have noticed that I haven't used 'VGA' even once, that's
because I don't think in terms 'VGA device'. I think in terms 'graphics
device' that's a device which can be used to display 'stuff' on a screen
and I don't care about how it is done, whether using VGA or the card is
in 3D mode and is accessed differently (preferably VGA isn't used at all
for graphics access). The VGA specific problems should be solved on a
lower level, I have the impression that the VGA peoblems are among the
biggest in the world when reading this list. By lower level I mean that
if a driver uses VGA to access the device, it should coordinate with
other VGA devices using a small block in the kernel but it should not be
any major part of the kernel.
I think this would make the suspend/resume/access/switching etc problems
much easier to solve since the kernel module could tell the library to
stop drawing/accessing mmap'ed memory etc. (or if the OpenGL rendering
is done in the kernel module it could just discard the render commands).
Since the user has no direct access to mmap'ed memory and other critical
sections of the device, the driver can implement proper power managment
for suspend/resume etc.
Well... that's it.. any comments? I'm sure you have.. :)
--
wereHamster a.k.a. Tom Carnecky Emmen, Switzerland
(GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M
?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+
Am Mittwoch, 20. Oktober 2004 00:10 schrieb Tomas Carnecky:
> I think this would make the suspend/resume/access/switching etc problems
> much easier to solve since the kernel module could tell the library to
> stop drawing/accessing mmap'ed memory etc. (or if the OpenGL rendering
> is done in the kernel module it could just discard the render commands).
> Since the user has no direct access to mmap'ed memory and other critical
> sections of the device, the driver can implement proper power managment
> for suspend/resume etc.
>
> Well... that's it.. any comments? I'm sure you have.. :)
You are making damn sure that there will be no useful bug reports
about problems with resuming from S3.
Regards
Oliver
Oliver Neukum wrote:
> Am Mittwoch, 20. Oktober 2004 00:10 schrieb Tomas Carnecky:
>
>>I think this would make the suspend/resume/access/switching etc problems
>>much easier to solve since the kernel module could tell the library to
>>stop drawing/accessing mmap'ed memory etc. (or if the OpenGL rendering
>>is done in the kernel module it could just discard the render commands).
>>Since the user has no direct access to mmap'ed memory and other critical
>>sections of the device, the driver can implement proper power managment
>>for suspend/resume etc.
>>
>>Well... that's it.. any comments? I'm sure you have.. :)
>
>
> You are making damn sure that there will be no useful bug reports
> about problems with resuming from S3.
>
I guess that you are talking about the fact that displaying text
messages would be possible only after the first device driver has
initialized and registered with the kernel.
You could do the printing in two stages: at the begining the same way as
in the current kernel, but as soon as the first driver is registered,
the kernel switches to the function provided by the driver.
Something like this:
void print_message(...)
{
if (no_module_registered) {
use_print_function_provided_by_the_kernel();
} else {
if (!printing_disabled) {
use_print_function_provided_by_the_driver_module();
} else {
/* printing disabled by the userspace, we are not
* allowed to touch the hardware */
}
}
}
tom
On Wed, 20 Oct 2004, Tomas Carnecky wrote:
> Oliver Neukum wrote:
>> Am Mittwoch, 20. Oktober 2004 00:10 schrieb Tomas Carnecky:
>>
>>> I think this would make the suspend/resume/access/switching etc problems
>>> much easier to solve since the kernel module could tell the library to
>>> stop drawing/accessing mmap'ed memory etc. (or if the OpenGL rendering is
>>> done in the kernel module it could just discard the render commands).
>>> Since the user has no direct access to mmap'ed memory and other critical
>>> sections of the device, the driver can implement proper power managment
>>> for suspend/resume etc.
>>>
>>> Well... that's it.. any comments? I'm sure you have.. :)
>>
>>
>> You are making damn sure that there will be no useful bug reports
>> about problems with resuming from S3.
>>
>
> I guess that you are talking about the fact that displaying text messages
> would be possible only after the first device driver has initialized and
> registered with the kernel.
>
> You could do the printing in two stages: at the begining the same way as in
> the current kernel, but as soon as the first driver is registered, the kernel
> switches to the function provided by the driver.
>
> Something like this:
>
> void print_message(...)
> {
> if (no_module_registered) {
> use_print_function_provided_by_the_kernel();
> } else {
> if (!printing_disabled) {
> use_print_function_provided_by_the_driver_module();
> } else {
> /* printing disabled by the userspace, we are not
> * allowed to touch the hardware */
> }
> }
> }
>
> tom
On ix86 machines, regardless of whatever code initialized the
hardware, if the screen-card is not put into graphics mode,
anybody can write characters and attributes at 0xb8000 directly
to the screen. Even user-mode code can mmap() that area and write
to it. So, the key seems to be to get out of graphics mode
before suspend, and go back later after resume.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
On Wed, 20 Oct 2004, Tomas Carnecky wrote:
> Richard B. Johnson wrote:
>
>> On ix86 machines, regardless of whatever code initialized the
>> hardware, if the screen-card is not put into graphics mode,
>> anybody can write characters and attributes at 0xb8000 directly
>> to the screen. Even user-mode code can mmap() that area and write
>> to it. So, the key seems to be to get out of graphics mode
>> before suspend, and go back later after resume.
>
> Why do you let user-mode programs access the hardware directly?
> You don't do this with network devices (there you have syscalls), you don't
> do this with sound devices (alsa).
Any root process can mmap() any of the memory-mapped hardware
including network devices. This isn't normally done because
handling interrupts from such hardware isn't very efficient
in user-mode, and redistributing data meant for another
process would be a nightmare. However, it can be done.
> IMO it makes a proper power managment implementation impossible.
>
Wrong. The 'normal' user can't do such I/O, root can. See iopl(), which
sets the I/O privilege level. This has nothing to do with power-
management.
> You can say that there are two different drivers for screen-cards in the
> kernel. One is the VGA which enables the card during early boot time to
> display the first text messages and the other is fb/DRI or even an nvidia/ati
> kernel module which is enabled later on.
Doesn't require two drivers.
> Last time I've tried a LiveCD distro I've seen a nice boot console with
> background picture, high resolution (1024x768) and nice small font. That
> means that the framebuffer driver had to be initialized at that time. I don't
> have framebuffer drivers compiled into my kernel so I don't know at which
> point these are initialized, but it must be at a quite early point in the
> boot process.
Even Fedora, which boots in a 'graphical' mode, really boots standard
text-mode until 'init' gets control. They just hide the console output
by setting the grub command-line parameter, "quiet".
The kernel messages are still available using `dmesg`. If you want
to eliminate any possibility of losing kernel messages because
the kernel failed to get up all the way, just use /dev/ttyS0 as
your console during boot.
> When looking at the output of dmesg I can see that the first thing that is
> initialized are the CPU's, ACPI, IRQ's and then the PCI bus is scanned. Did
> anyones machine crash during these steps? I don't think a healthy box will
> crash here. And at this point you can initialize your graphics card driver
> like it is done in the LiveCD distro.
>
> tom
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
Richard B. Johnson wrote:
>> Why do you let user-mode programs access the hardware directly?
>> You don't do this with network devices (there you have syscalls), you
>> don't do this with sound devices (alsa).
>
>
> Any root process can mmap() any of the memory-mapped hardware
> including network devices. This isn't normally done because
> handling interrupts from such hardware isn't very efficient
> in user-mode, and redistributing data meant for another
> process would be a nightmare. However, it can be done.
>
>> IMO it makes a proper power managment implementation impossible.
>>
>
> Wrong. The 'normal' user can't do such I/O, root can. See iopl(), which
> sets the I/O privilege level. This has nothing to do with power-
> management.
Power managment should be done in the kernel, that's why there is sysfs
and the kobjects. But it can't be done properly if some process from
user-mode (even root processes) do access the hardware directly.
Power managment isn't the only reason why it shouldn't be done, but also
everything related to the device managment etc. There should always be a
driver between a process and the hardware as a protection.
>
>> Last time I've tried a LiveCD distro I've seen a nice boot console
>> with background picture, high resolution (1024x768) and nice small
>> font. That means that the framebuffer driver had to be initialized at
>> that time. I don't have framebuffer drivers compiled into my kernel so
>> I don't know at which point these are initialized, but it must be at a
>> quite early point in the boot process.
>
>
> Even Fedora, which boots in a 'graphical' mode, really boots standard
> text-mode until 'init' gets control. They just hide the console output
> by setting the grub command-line parameter, "quiet".
>
> The kernel messages are still available using `dmesg`. If you want
> to eliminate any possibility of losing kernel messages because
> the kernel failed to get up all the way, just use /dev/ttyS0 as
> your console during boot.
Well... that's why I don't understand why we should keep the VGA code in
the kernel. It's very unlikely that the kernel crashes before a graphics
driver can be initialized (if you do this as soon as possible) unless
you have a bad CPU etc.
tom
Tomas Carnecky <[email protected]> wrote:
> Well... that's why I don't understand why we should keep the VGA code in
> the kernel. It's very unlikely that the kernel crashes before a graphics
> driver can be initialized (if you do this as soon as possible) unless
> you have a bad CPU etc.
At the moment, it /is/ quite likely that the kernel crashes before a
graphics driver can be initialised if you're trying to resume from ACPI
S3.
--
Matthew Garrett | [email protected]
> I guess that you are talking about the fact that displaying text
> messages would be possible only after the first device driver has
> initialized and registered with the kernel.
No, the kernel cannot print at all.
> You could do the printing in two stages: at the begining the same way as
> in the current kernel, but as soon as the first driver is registered,
> the kernel switches to the function provided by the driver.
The current kernel can print only if the video chipset is initialised
to a certain degree, which usually the firmware or the boot loader
provide for.
Regards
Oliver
Tomas Carnecky <[email protected]> wrote:
> I don't like the framebuffer devices or even the DRI drivers
> because: most applications use a 'high-level' API for rendering
> (OpenGL). These 'high-level commands' are translated to
> 'intermediate commands' (framebuffer/DRI ioctl calls etc.) before
> being send to the card as 'low-level commands'. Why this
> intermediate layer?
I am not sure what you are trying to propose here, but really you should
go back and read up on how graphics device drivers work, more
specifically DRI. If you do that, it will be clear that DRI drivers are
the internal 'meat' implementation for OpenGL on Linux. DRI is not an
intermediate layer that can be eliminated at the swish of your hand and
instantly get more performance! OpenGL drivers on Linux using DRI build
up packets of 3D commands to be send to the hardware in *user mode* into
DMA buffers. Then a command is sent to the kernel driver to start sending
the data to the hardware using DMA. The overhead of the ioctl's to the
/kernel to start the DMA packets is not very high (although IMHO this
could all be moved into user space also, but that is a different story).
As for the framebuffer console, it exists purely to get high resolution
text consoles working with basic graphics capabilities. It was never
intended to be a complete graphics environment, but just the console that
can be used in graphics modes. The original versions of the framebuffer
console code were developed not for x86 machines but for non-x86 machines
that did not have any VGA capabilities at all (ie: Mac's). For Linux to
work on such machines, the console needed to be able to output text in
graphics modes since that is what the machines booted in. Once this was
done for non-x86 boxes, it was realised this would be a 'cool' feature
for x86 machines for two reasons. 1 - you get a nice high resolution text
console, way better than VGA text mode and, 2 - you can display the cool
penguin logo ;-)
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
Richard B. Johnson wrote:
> On ix86 machines, regardless of whatever code initialized the
> hardware, if the screen-card is not put into graphics mode,
> anybody can write characters and attributes at 0xb8000 directly
> to the screen. Even user-mode code can mmap() that area and write
> to it. So, the key seems to be to get out of graphics mode
> before suspend, and go back later after resume.
Why do you let user-mode programs access the hardware directly?
You don't do this with network devices (there you have syscalls), you
don't do this with sound devices (alsa).
IMO it makes a proper power managment implementation impossible.
You can say that there are two different drivers for screen-cards in the
kernel. One is the VGA which enables the card during early boot time to
display the first text messages and the other is fb/DRI or even an
nvidia/ati kernel module which is enabled later on.
Last time I've tried a LiveCD distro I've seen a nice boot console with
background picture, high resolution (1024x768) and nice small font. That
means that the framebuffer driver had to be initialized at that time. I
don't have framebuffer drivers compiled into my kernel so I don't know
at which point these are initialized, but it must be at a quite early
point in the boot process.
When looking at the output of dmesg I can see that the first thing that
is initialized are the CPU's, ACPI, IRQ's and then the PCI bus is
scanned. Did anyones machine crash during these steps? I don't think a
healthy box will crash here. And at this point you can initialize your
graphics card driver like it is done in the LiveCD distro.
tom
On Wed, Oct 20, 2004 at 10:27:08AM -0700, Kendall Bennett wrote:
[...]
> As for the framebuffer console, it exists purely to get high resolution
> text consoles working with basic graphics capabilities. It was never
> intended to be a complete graphics environment, but just the console that
> can be used in graphics modes. The original versions of the framebuffer
> console code were developed not for x86 machines but for non-x86 machines
> that did not have any VGA capabilities at all (ie: Mac's). For Linux to
> work on such machines, the console needed to be able to output text in
> graphics modes since that is what the machines booted in. Once this was
> done for non-x86 boxes, it was realised this would be a 'cool' feature
> for x86 machines for two reasons. 1 - you get a nice high resolution text
> console, way better than VGA text mode and, 2 - you can display the cool
> penguin logo ;-)
And last but not least - you can have several such framebuffers in a
single machine, possibly for multi-user purposes. VGA
wants to be the only one of its kind . . .
Helge Hafting
Blizbor wrote:
> Tomas Carnecky wrote:
>
>> Richard B. Johnson wrote:
>>
>>>> Why do you let user-mode programs access the hardware directly?
>>>> You don't do this with network devices (there you have syscalls),
>>>> you don't do this with sound devices (alsa).
>>>
>>>
>>>
>>>
>>> Any root process can mmap() any of the memory-mapped hardware
>>> including network devices. This isn't normally done because
>>> handling interrupts from such hardware isn't very efficient
>>> in user-mode, and redistributing data meant for another
>>> process would be a nightmare. However, it can be done.
>>>
>>>> IMO it makes a proper power managment implementation impossible.
>>>>
>>>
>>> Wrong. The 'normal' user can't do such I/O, root can. See iopl(), which
>>> sets the I/O privilege level. This has nothing to do with power-
>>> management.
>>
>>
>>
>> Power managment should be done in the kernel, that's why there is
>> sysfs and the kobjects. But it can't be done properly if some process
>> from user-mode (even root processes) do access the hardware directly.
>> Power managment isn't the only reason why it shouldn't be done, but
>> also everything related to the device managment etc. There should
>> always be a driver between a process and the hardware as a protection.
>>
>>>
>>>> Last time I've tried a LiveCD distro I've seen a nice boot console
>>>> with background picture, high resolution (1024x768) and nice small
>>>> font. That means that the framebuffer driver had to be initialized
>>>> at that time. I don't have framebuffer drivers compiled into my
>>>> kernel so I don't know at which point these are initialized, but it
>>>> must be at a quite early point in the boot process.
>>>
>>>
>>>
>>>
>>> Even Fedora, which boots in a 'graphical' mode, really boots standard
>>> text-mode until 'init' gets control. They just hide the console output
>>> by setting the grub command-line parameter, "quiet".
>>>
>>> The kernel messages are still available using `dmesg`. If you want
>>> to eliminate any possibility of losing kernel messages because
>>> the kernel failed to get up all the way, just use /dev/ttyS0 as
>>> your console during boot.
>>
>>
>>
>> Well... that's why I don't understand why we should keep the VGA code
>> in the kernel. It's very unlikely that the kernel crashes before a
>> graphics driver can be initialized (if you do this as soon as
>> possible) unless you have a bad CPU etc.
>>
> I think you're wrong.
> This is not a good idea. In such important (should I say 'critical' ?)
> software like kernel
> there is no room to developers 'probability sense'. If exists
> hypotethical situation that
> something will go wrong it should be taken into account and a software
> way to handle it
> must exist.
I don't think there is any way you can handle a crash at that stage,
either the kernel starts successfully or not.
>
> 1. What if kernel crashes during graphics driver initialisation ?
Developers can have a serial console attached to the computer and get
the info from there and any other user don't really care, I don't think
that the office workers in the Munich government would care about it and
send a bug report to the LKML.
> 2. What if you move HD to another box with totally diferrent graphics
> device ?
You could have two drivers compiled in, one very small and simple (VGA)
for the case that you'll change the computer and a boot parameter to
change them. But usually people compile a new kernel before putting the
HD into a new box so I don't see this as a a stong argument.
> 3. What if the kernel DO crash before graph.dev. initialisation ? How
> many hours you will spend diagnosing ?
Not even a minute, I'd switch to a driver version that worked before.
And maybe report that the new version doesn't work.
>
> 4. What if before or during graphisc driver initialisation a kind of
> delayed error in other device will occur ?
Not if you initialize the graph.dev. before any other device, as soon as
possible, just after the bus(PCI etc.) initialization.
tom
On Wed, 20 Oct 2004, Tomas Carnecky wrote:
> Last time I've tried a LiveCD distro I've seen a nice boot console with
> background picture, high resolution (1024x768) and nice small font. That means
> that the framebuffer driver had to be initialized at that time. I don't have
> framebuffer drivers compiled into my kernel so I don't know at which point
> these are initialized, but it must be at a quite early point in the boot
> process.
I guess that was vesafb (check /proc/fb). In that case the BIOS initialized the
graphics card to 1024x768 just before the Linux kernel was started.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds