Thread: Documentation

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

I'm looking for all documentation about the Linux Console Subsystem. I think
it's a lot of code and not easy to browse. Are there some diagrams/graphics?

Thank you,
Christian.

Early days

http://members.westnet.com.au/vanzeeland/Linux/configure_X.htm

comments suggestions, content submissions welcome...

J

Updated.
http://members.westnet.com.au/vanzeeland/Linux/configure_X.htm
Comments, suggestions, content submissions welcome.

J

--- James van Zeeland <ja...@dv...> wrote:

> Updated.
>
http://members.westnet.com.au/vanzeeland/Linux/configure_X.htm
> Comments, suggestions, content submissions welcome.

Good start. I still favor some sort of symptom table
in docs. To wit: recent postings about blank screens.
I realize this is multi-dimensional, server, driver,
distrib, faketty, ruby, etc. Maybe difficult to do.

BTW, if you would like help let me know.

Hugo.

__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Sounds like a good idea to me. Certainly I think it's necessary to cover
the whole scope of multi-console configurations. I suspect it will take
a while before the more abstract configs are documented, but I'd rather
see something comprehensive than something that leaves users wondering
what to do because they're using such-and-such distribution etc, or
spending days looking at a common and easily fixable issue.

So a troubleshooting table?

Happy to recieve tidbits from other users. How are you configured? Some
distro's probably have different quirks ; for example I will document
building X from .srpm packages but that's only good for Redhat/Fedora
users

If you are using multi-console configurations, feel free to email me
with whatever you feel will help - alternative display manager
configurations, distribution specific differences, successful configs
using framebuffers and dual-head cards etc etc.

Open for submissions; I will continue by covering patching and building
X for a Fedora install, including the vt options Ubuntu users were
talking about that got evdev implementation stable, if they're necessary
for FC; faketty stopped my planned evdev migration in it's tracks...

Certainly an evdev implementation document would be helpful.

J

On Thu, 2005-09-29 at 01:04, Hugo Vanwoerkom wrote:
> --- James van Zeeland <ja...@dv...> wrote:
> 
> > Updated.
> >
> http://members.westnet.com.au/vanzeeland/Linux/configure_X.htm
> > Comments, suggestions, content submissions welcome.
> 
> 
> Good start. I still favor some sort of symptom table
> in docs. To wit: recent postings about blank screens.
> I realize this is multi-dimensional, server, driver,
> distrib, faketty, ruby, etc. Maybe difficult to do.
> 
> BTW, if you would like help let me know.
> 
> Hugo.
> 
> 
> 
> 
> 
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail - PC Magazine Editors' Choice 2005 
> http://mail.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

--- James van Zeeland <ja...@dv...> wrote:

> Sounds like a good idea to me. Certainly I think
> it's necessary to cover
> the whole scope of multi-console configurations. I
> suspect it will take
> a while before the more abstract configs are
> documented, but I'd rather
> see something comprehensive than something that
> leaves users wondering
> what to do because they're using such-and-such
> distribution etc, or
> spending days looking at a common and easily fixable
> issue.
> 
> So a troubleshooting table?
> 
> 

If we could agree on what is needed to make such a
table. E.g.

Distro:  Debian Stable
Kernel:  2.6.13-ck6
X:       XFree86 4.3.0.dfsg.1-8 
Patched: Isolatedevice patch is incorporated in Stable
Driver:  NVIDIA-Linux-x86-1.0-7167-pkg1.run
AGP:     TNT2 - VT7
PCI:     MX-440 - VT51
Kbds:    2xPS/2 IBM Model M
Mice:    2xUSB A4Tech WOP-35PU
Multi:   Faketty
dm:      Gdm

__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

James van Zeeland escreveu:
> 
> Certainly an evdev implementation document would be helpful.
> 
We have one at
http://www.c3sl.ufpr.br/multiterminal/howto-en.php

Greetings,
Daniel

On Fri, 14 Apr 2000, Christian Helmuth wrote:

> 
> Hi all,
> 
> I'm looking for all documentation about the Linux Console Subsystem. I think
> it's a lot of code and not easy to browse. Are there some diagrams/graphics?

Well the console system is slowly being changed. Its a mess right now and
we are planning to simplify it to a great deal. Once a stable clear
design comes out we will post documenetation. We already have documentation 
for sub systems that are used to created the virtual terminal. We can 
answer any questions you have. 

  Okay, thanks for your offer to help me.

  First I will describe in short what I want to do. In our DROPS-Project 
<http://os.inf.tu-dresden.de/drops/> we still have no Console-Subsystem or any
Xserver-like Microkernel-Server, so it is my task to write one ;)

  In parallel to other "real" microkernel applications or device driver
servers a time-sharing component - a modified linux in user mode is running. 
It is obvious that Linux has to do some console output and keyboard input. But
this devices (keyboard, vga (framebuffer), maybe mouse) are now managed by my
CON component, so Linux has to talk my IPC protocol.

  The way is to exchange the low level driver for stubs/proxies. The problem
is to identify the Linux component where to do so. So I just want an overview
of the console system (diagrams) cause I'm not so used egt all info from the
Sourcecode. 

  I want to use an low level driver protocol for console specific input/output
similar to that in "Thin Client Architectures" - so it will be a graphical
console. IMHO it should be possible to write an fbdev for the graphics stuff
and to extract the whole keyboard from the Linux source code if I find the
point to start.

  In future it should be possible to run a Xserver in the time-sharing
component (Linux) using the XF68_FBDev server because of the low level
approach - the scientific point will be: Is the performance acceptable?

  So far from me, so what do you think? ;-)

Ciao,
Christian.