On Fri, 25 Feb 2000, Petr Vandrovec wrote:
>> something like SVGAtextmode which informs the kernel how to
>> change to the modes that will be used, and then tells the kernel
>> what mode each VC is supposed to be in.
>> Do you see anything I'm missing in the above? I think it is
>> possible, but I'm not 100% sure. I'd like other people's
>> feedback.
>
>How do you tell to kernel how to switch pixclock? It is done by non-vga
>registers...
No idea. Remember, I'm new to this. ;o) SVGAtextmode has the
answers to that though. It is just a matter at looking how it
does it, and seeing if it is feasible to put a solution in kernel
that is very lightweight (non-bloat).
>> Ok, can anyone tell me where to get the vgafb code? If it does
>> what I'm looking for, I'd be glad to have something to start
>> with.
>
>Look into linux-2.1.125 package... I believe that it was in...
Will do. Thanks.
>> Is this really true? Could I not have a userland interface which
>> a special app could tell the kernel these things at runtime? If
>> it is impossible, I'd like to know why, or is it just really
>> complex?
>
>Through non-VGA registers only. And you must change it when you change
>pixclock. And if every console has different size, you must change
>pixclock...
So the kernel would have to change mode regs, and pixclock
simultaneously is what you're saying, and the pixclock varies
from card to card how it is done? Then I guess that the driver
would have to know about different cards after all. I'll have to
look into it and learn how it is done and see if I can come up
with a solution...
>> >fbset passes complete videomode information to kernel. But kernel
>> >has to pass it to hardware - and for this it must know about
>> >hardware. Standard VGA is only standard VGA. Face to it.
>> Hmm. So a userland app would have to know what video card you
>> have. This could be done with autodetection, or by the user
>> picking a card. I don't see this a problem because you need to
>> do the same for X, or for any other OS out there anyways. Once
>> the card is known by a userland app, it can inform the kernel of
>> this somehow no? I mean not with what we have now, but we could
>> extend the kernel in this manner no?
>
>Type of card is not interesting. How to program such beast is interesting
>thing...
So it isn't a matter of telling the kernel "write this number to
this port" then? I assume that is what you mean. If it isn't
that simple, then I guess I'll have to look at the code to
understand the deeper problem myself..
>> >(borrow from vga16fb or matroxfb) and which programs palette (vga16fb).
>> >Only thing you have to add is pixclock programming code for unusual
>> >dotclocks.
>> Ok, then it does sound feasible. The dotclock code can be stolen
>> from SVGATextMode, as long as it is GPL I guess. At least it can
>> provide me with an idea of the details necessary.
>
>Yes. But it is not up to date with latest hardware.
Right, but that doesn't mean that it can't be useful for current
hardware. New hardware details can be added as the info is made
available. People using hardware for which the driver doesn't
know how to set the pixclock, can't have modes which the pixclock
needs to be changed. They'll have to do without thats all.
I don't see it as a problem. I'd certainly add support for
anything that someone could send me the info for.
>> Just point me to the vgafb code, and I'll have a look-see. That
>> is from the 2.1.x era correct?
>I have to go to to train station and left Prague just now, unfortunately.
>If you will not find it before Monday, ask me again and I dig through
>my archives.
Allright, will do. Thanks again for your help!
Take care,
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocateSuspicious Anagram #4: Word: PRESIDENT CLINTON OF THE USA Anagram: TO COPULATE HE FINDS INTERNS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:13 EST