lkml.org 
[lkml]   [2000]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux console driver maintainer?
On Fri, 25 Feb 2000, James A Simmons wrote:

>> >Linus orginally wrote it. It has been modified but it really hasn't
>> >changed much. When 2.5.X comes out this will change. Several people will
>> >be working on the new console system.
>>
>> Who? I'd like to see their code/ideas, etc.. Perhaps test out
>> existing effort...
>
>http://www.suse.cz/development/input
>
>This is mostly the input side of it developed by Vojtech. I have been
>working on the fbdev side. His patch has some multiheaded support to it.
>After 2.4.X is out we will join forces to find a complete solution :)

Great! I'm definitely interested in seeing this too.

>> >Use the framebuffer console. It allows for such things. As for the issue
>> >of VT switching this works but a better way to handle this is being worked
>> >on.
>>
>> The fb console is very slow, at least for me, and it causes many
>> apps on my system to not work anymore - like VMware,
>> etc... There are other issues with it for me right now too.
>
>The latency issue. The problem is alot of fbdev drivers do everything
>pixel by pixel. This is very slow. I have been working on a patch that
>makes a standard way for fbdev drivers to take advantage of the accel
>engine to preform accel functions.

Well, I'm sure that the framebuffer will get worked out in
time... My only, and I stress _only_ here goal - to satisfy my
personal itch - is to have the _TEXT_MODE_ hardware utilized in a
more powerful way.

I am interested in fb devices too, but not at the expense of
dumping perfectly good text mode hardware that is underutilized.


>> I'd also like to have a separate scrollback buffer on each
>> console, and perhaps be able to configure what consoles have
>> scrollback, which don't and how big they are all at runtime, and
>> independant of any textmode changes that occur during runtime.
>
>We are aware that only one scrollback buffer exist for all fbdev drivers.
>This does need to be fixed.

Correct me if I'm wrong... fbdev consists of only graphical
devices, and not text mode hardware? I just want to get it
straight because a lot of people are telling me about fbdev and
I'm not entirely clear on it. None of the links people have sent
me mention anything at all about text mode, only graphical fb
consoles. Again, I think graphical console is a cool thing, but
my personal area of concern here is the actual VGA text
console. I want to snazzy it up a bit, and have it remain as
compatible as possible at the same time.

>> I've looked at the code and vc_resize() in console.c appears to
>> resize every single VC simultaneously. I'd like to make it not
>> do that, but I assume it does for a good reason. Anyone care to
>> explain why? If no great reason exists, I'd like to hack it up
>> to work just for me... I don't want to shoot myself in the foot
>> though in the mean time.
>
>See other post.

Will do! Looks like there are a lot of people wanting to
contribute to a better console here!

Take care!
TTYL


--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate

Suspicious 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.071 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site