Very Computer

Is it possible to get direct hardware access to the VGA card? Probably I don't
need direct hardware access but rather I need to read and write directly into
the gfx memory. Any ideas how I could achieve this when X is running? I don't
mind when windows are overwritten in the course because they could be
refreshed and I would want to save the content anyway.

I was looking into the console code from the kernel. From that I noticed a
function take_over_console. Is this how X does take over the console and how
it is handled?

--
Gerhard Gruber

Fr jedes menschliche Problem gibt es immer eine einfache L?sung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)

With or without X? If without, you could try svgalib (or maybe framebuffer support,
but I dont know much about that). If with X, DGA is just for that.

Quote:> I was looking into the console code from the kernel. From that I noticed a
> function take_over_console. Is this how X does take over the console and how
> it is handled?

If you know the physical address of video memory, you can mmap() /dev/mem.
But it's better to use DGA.

On 26 Jun 2003 17:32:03 GMT wrote Tuukka Toivonen

Quote:>With or without X? If without, you could try svgalib (or maybe framebuffer support,
>but I dont know much about that). If with X, DGA is just for that.

It depends. But I think I would like to take over the console screen in case
it is run on a text console. This already works for the module. When X is
running I would like to detect this and use the already existing display for
drawing. What exactly is DGA?

Quote:>If you know the physical address of video memory, you can mmap() /dev/mem.
>But it's better to use DGA.

This would be from a kernel module. But it should be possible there as well.

--
Gerhard Gruber

Fr jedes menschliche Problem gibt es immer eine einfache L?sung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)

man dga:
dga(1)                                                     dga(1)

NAME
       dga - test program for the XFree86-DGA extension

Quote:> This would be from a kernel module. But it should be possible there as well.

Well then probably you can't use DGA. You must find out the framebuffer
physical address and access that. You should find plenty of material
from net about accessing memory-mapped devices, although if the same card
is shared with other drivers (eg. X server) it may give problems.

On 26 Jun 2003 18:47:49 GMT wrote Tuukka Toivonen

Quote:>Well then probably you can't use DGA. You must find out the framebuffer
>physical address and access that. You should find plenty of material
>from net about accessing memory-mapped devices, although if the same card
>is shared with other drivers (eg. X server) it may give problems.

As long as I inside the module this shouldn't be a problem, right? Ignoring
SMP for now. :)

I just looked into the VESA BIOS specification and there it seems is a
function to save/restore the current state, which would be exactly what I
need, but I guess I can't use VESA BIOS calls within a linux module, right?
Or is there some interface for that? I have tried google but I haven't found
something helpfull for that.

--
Gerhard Gruber

Fr jedes menschliche Problem gibt es immer eine einfache L?sung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)

Maybe you can. For example, apm and some other kernel code seems to be able
to use BIOS calls too. I don't know how. And I wouldn't trust BIOS anyway.

On 27 Jun 2003 14:50:10 GMT wrote Tuukka Toivonen

Quote:>Maybe you can. For example, apm and some other kernel code seems to be able
>to use BIOS calls too. I don't know how. And I wouldn't trust BIOS anyway.

My problem is that I don'know how to retrieve the current VGA state and how to
restore it. I don't want to end up supporting hundreds of different video
cards. So going for VESA BIOS seems a more or less portable way probably. The
problem is that BIOS doesn't support multitasking and reentrancy so this could
be a bit of a problem. Also I'm not sure if the BIOS has the correct data
available when the BIOS was not used to set the mode. Well, I can test this
with a little program and see how it works. I'll take a look into APM code.
Thanks.

--
Gerhard Gruber

Fr jedes menschliche Problem gibt es immer eine einfache L?sung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)

Quote:> Is it possible to get direct hardware access to the VGA card?
> Probably I don't need direct hardware access but rather I need to
> read and write directly into the gfx memory. Any ideas how I could
> achieve this when X is running? I don't mind when windows are
> overwritten in the course because they could be refreshed and I
> would want to save the content anyway.

> I was looking into the console code from the kernel. From that I
> noticed a function take_over_console. Is this how X does take over
> the console and how it is handled?

Have you considered the possibility that it would be simpler to open a
connection to the X server and submit some X requests?

Doing this via direct hardware access sounds like it will be horribly
non-portable, and fragile in too many ways to readily recount.
Particularly when there's the possibility that any number of "graphic
system managers" might or might not be involved.

Why is it that you think you need direct hardware/memory access?
--

http://www.ntlug.org/~cbbrowne/x.html
"Oh, I've seen  copies [of Linux Journal] around  the terminal room at
The Labs."  -- Dennis Ritchie

comp.os.linux.development.system with

Quote:>Why is it that you think you need direct hardware/memory access?

Because this is a kernel level de*. So I want to call only as much
functions as absolutely needed.

--
Gerhard Gruber

Fr jedes menschliche Problem gibt es immer eine einfache L?sung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)

<shakes head in amazement>

If you are debugging something, any messing with VESA is the last thing you
want.  Use serial console and be done with that...

[Chris sits back, for a moment, stunned...]

And you think embedding a graphical de* in the kernel is a _good_
idea???

Did you consider the possibility that maybe that's a HORRIBLE idea,
instead, as it would introduce three previously-absent classes of
bugs:

 -> The ones you introduce as a result of your de* being
    painfully complex;

 -> The ones that result from any shortcomings in the implementations
    of the video cards;

 -> The ones that result from any shortcomings in the perfection of
    your understanding of how the video cards function.

Let's put it this way: The existing developers working on the kernel
have never felt any need to resort to this sort of thing.  They have
generally denigrated the thought of putting any extensive "graphical"
functionality into the kernel.

And remarkably enough, the results of THEIR efforts is an OS kernel
that is sufficiently good that SCO representatives have been on public
record that they consider it impossible that it could have gotten so
robust without stealing code from SCO.

The notion that an inside-the-kernel graphical de* would help in
this seems simply ridiculous.

- The amount of work required would be enormous, and parts of it would
  be obsoleted the next time NVidia or ATI or whomever else come out
  with a new graphics chipset.

- The quantity of code and memory allocation that would get forced
  into the kernel would be atrocious.  You'd have a kernel 8MB,
  _compressed_, that won't run without having at least 128MB of RAM
  around.

- This wouldn't remove bugs; it would _add_ a staggering number of
  them.

I didn't think there was any Linux idea more preposterous than porting
it to C++; I now stand corrected.  There _is_ something more
preposterous than that.
--

http://www.veryComputer.com/
There are two kinds of fool; One who says "This is old and therefore
bad," and one who says "This is new and therefore better."
-- John Brunner

comp.os.linux.development.system with

Quote:>And you think embedding a graphical de* in the kernel is a _good_
>idea???

It's a module so you don't have to have it in the kernel embedded.

Quote:>Did you consider the possibility that maybe that's a HORRIBLE idea,

No. Not yet. :) Another issue is that I also want to have an interface for
user mode debugging. I know there is GDB but I really don't like it. Though
there are some GUIs for it which help make it more usable I still don't really
like it.
Considering that SoftICE on Windows does quite well and is regarded as one of
the best de*s I think it would be great to have a similar tool for linux.

Quote:> -> The ones you introduce as a result of your de* being
>    painfully complex;

It doesn't have to be painfully complex. But that depends on how I actually
have to implement it. BTW: This de* has been around for several years now
(http://www.veryComputer.com/) and it works. The only thing is that it doesn't
work with X so I wanted to fix that.

Quote:> -> The ones that result from any shortcomings in the implementations
>    of the video cards;

AFAIK I only need access to video memory. Everything else could be done inside
my code. It's not as if I need some fancy graphics or such.

Quote:> -> The ones that result from any shortcomings in the perfection of
>    your understanding of how the video cards function.

That's what have to be fixed. But every program has bugs in the beginning. If
it is longer around and propely maintained they will be fixed.

Quote:>Let's put it this way: The existing developers working on the kernel
>have never felt any need to resort to this sort of thing.  They have

I guess there are many more people who want to have some decent de*
around.

Quote:>generally denigrated the thought of putting any extensive "graphical"
>functionality into the kernel.

That's why they put framebuffer support in the kernel, right? :)

Quote:>And remarkably enough, the results of THEIR efforts is an OS kernel
>that is sufficiently good that SCO representatives have been on public
>record that they consider it impossible that it could have gotten so
>robust without stealing code from SCO.

So what? I don't know what SCO has got to do with my de*? Apparently
there was a time without a decent kernel de* for Windows as well. People
also wrote great software at that time, but that doesn't mean that nobody will
appreciate it when there are better tools around.

Quote:>The notion that an inside-the-kernel graphical de* would help in
>this seems simply ridiculous.

Then you don't have to use it. If you don't like it, why bother?

Quote:>- The amount of work required would be enormous, and parts of it would
>  be obsoleted the next time NVidia or ATI or whomever else come out
>  with a new graphics chipset.

That's why I try to find an approach that is working as much as independently
of any special brand as possible. I don't like to have to support hundreds of
video cards and fix it every time a new one is around.

Quote:>- The quantity of code and memory allocation that would get forced
>  into the kernel would be atrocious.  You'd have a kernel 8MB,
>  _compressed_, that won't run without having at least 128MB of RAM
>  around.

Obviously a kernel de* has no use of being put directly into the kernel.
You load it on demand as a module because you surely don't want to have it
around all the time. Currently the module is about 200Kb big. Of course you
have to save the current display but it this is nowhere near 8MB what you are
talking of. And the code shouldn't expand that much to gain such a big size
either.

Quote:>I didn't think there was any Linux idea more preposterous than porting
>it to C++; I now stand corrected.  There _is_ something more
>preposterous than that.

Thanks. :) Funny thing is that it is already done. I don't have to do it. I
just want to maintain it and improve it.

--
Gerhard Gruber

Fr jedes menschliche Problem gibt es immer eine einfache L?sung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)