my opinion about VGA devices

my opinion about VGA devices

[Tomas Carnecky]

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+

Re: my opinion about VGA devices

[Oliver Neukum]

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

Re: my opinion about VGA devices

[Tomas Carnecky]

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

Re: my opinion about VGA devices

[Richard B. Johnson]

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.

Re: my opinion about VGA devices

[Tomas Carnecky]

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

Re: my opinion about VGA devices

[Richard B. Johnson]

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.

Re: my opinion about VGA devices

[Tomas Carnecky]

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

Re: my opinion about VGA devices

[Matthew Garrett]

Tomas Carnecky <tom@dbservice.com> 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 | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: my opinion about VGA devices

[Tomas carnecky]

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

Re: my opinion about VGA devices

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: my opinion about VGA devices

[Oliver Neukum]

> 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

Re: my opinion about VGA devices

[Kendall Bennett]

Tomas Carnecky <tom@dbservice.com> 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! ~

Re: my opinion about VGA devices

[Helge Hafting]

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

my opinion about VGA devices

[Tomas Carnecky]

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+

Re: my opinion about VGA devices

[Blizbor]

Tomas Carnecky wrote:

> Well... that's it.. any comments? I'm sure you have.. :)

I can't see clearly what about multiple graphic devices ?
I.e. two headed cards and more than one graphic card instaled.
Let say - four PCI cards, which isn't nonsense. Incoming PCI Express
will again allow for that.
What about multiple text consoles or multiple X displays (in one box).

Regards,
Blizbor.