Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio
From: James Simmons on 29 Jul 2010 11:20

> On Sat, Jul 24, 2010 at 16:43, Florian Tobias Schandinat
> <FlorianSchandinat(a)gmx.de> wrote:
> > Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
> >> Moreover I wanted something that COULD be used as a console but not
> >> necessarily, that is
> >> something that could run happily in the presence of a normal monitor
> >> as well. It seems to me, but I may be
> >> wrong, that through the standard console system only the current
> >> visible console is actually updated
> >> while other consoles are just "software" updated. An external LCD
> >> would therefore be updated
> >> only when you "switch" to it, so it would not be possible to use it to
> >> display diagnostics.
> >
> > True, that's a general problem one has when multiple framebuffers exist.
> > Therefore I'd be very happy if someone could come up with a general solution.
>
> Fixing that was (one of the) goal of the linux-console project. James?

Yeap. That was one of the goals. Plus a bunch others.

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)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
>
From: James Simmons on 29 Jul 2010 12:00

> <geert(a)linux-m68k.org> wrote:
> > On Sat, Jul 24, 2010 at 16:43, Florian Tobias Schandinat
> > <FlorianSchandinat(a)gmx.de> wrote:
> >> Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
> >>> Moreover I wanted something that COULD be used as a console but not
> >>> necessarily, that is
> >>> something that could run happily in the presence of a normal monitor
> >>> as well. It seems to me, but I may be
> >>> wrong, that through the standard console system only the current
> >>> visible console is actually updated
> >>> while other consoles are just "software" updated. An external LCD
> >>> would therefore be updated
> >>> only when you "switch" to it, so it would not be possible to use it to
> >>> display diagnostics.
> >>
> >> True, that's a general problem one has when multiple framebuffers exist.
> >> Therefore I'd be very happy if someone could come up with a general solution.
> >
> > Fixing that was (one of the) goal of the linux-console project. James?
>
> Hmmm, the linux-console project seems to be dead. There are no file
> releases after nearly ten
> years and the CVS is three years old.

We never did file releases. Mostly people just checked out cvs
and then built and tested out the kernel. At first it was a massive
project which covered several areas. That tree was used as a staging
ground for the input api and the new fbdev api. We even for a time had had
the serial api that you find drivers/serial. All of that has been made
main stream :-) Then we saw graphics cards all becoming agp and mother
boards with multiple apg slots where extremely rare. So interest in the
project died off. Now with usb and pcie plus graphics cards with multiple
crtcs its is becoming possible again.
Recently I have been looking at and working on the DRI mode setting api
since it covers the bulk of the graphics cards out there for the PC market which
are pcie which means the possiblity of multiple graphics cards in
parrallel. You are not the only one looking at this solution.

> Implementing this in the standard Linux terminal emulation
> would require
> a rewrite of most of the code, which I personally would do only if
> there is some interest from
> the community in improving the standard Linux console, and I don't
> think it is the case
> looking at the age of the Linux console project. So I decided to keep
> it separate.
> But never say never! In the future the two consoles could merge in a
> single one. ;)

Hum. Only in the last year have I started to see a interest in this area
again. A few months ago someone else was discussing with me the
limitations of the linux console system. I have a few drm changes I like
to push first for the next merge widow. Perhaps if Andrew Morton is
willing to merge the my linuxconsole git tree into his -mm branch for wide
area testing then I can start the linux console stuff up again. Currently
my console git tree has no commits. Its just a raw tree. BTW yes it is
alot of work to cleanup the console system.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Simmons on 29 Jul 2010 12:50

> > was born. Implementing this in the standard Linux terminal emulation
> > would require
> > a rewrite of most of the code, which I personally would do only if
> > there is some interest from
> > the community in improving the standard Linux console
>
> There is a great deal of interest. Most of the console (as in
> framebuffer) activity moved to the 3D direct rendering world some time
> ago.

Really. I didn't expect the console to be of much interest.

> Let's start at the beginning. What console layer things need fixing to
> make the LCD Linux project able to use them ?
>
> Multiple displays live at once is an obvious one - the 3D graphics folks
> also want some of that too.

Okay you asked for it.

1) To do multiple displays will require the console tool updates.

2) Kill the big ugly console lock. One lock for not only multiple
VTs but even multiple types of consoles is horrible. I seen on
embedded board using the framebuffer device take the console
lock thus block the serial port.

3) Invert the VT layer. Currently the console/printk driver is on top of
the tty layer. It would be nice to be able to only use a very light
weight vt printk without the VT tty on top for embedded platforms.

4) Seperate out the VT emulation layer. Related to 3.

5) Multiple independent VT support. Which brings up the question what
should the mapping of VCs to a VT look like.

6) A nice scrollback buffer on the VT layer level instead of the hacks we
have in fbcon and vgacon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 29 Jul 2010 14:00
> 3) Invert the VT layer. Currently the console/printk driver is on top of
> the tty layer. It would be nice to be able to only use a very light
> weight vt printk without the VT tty on top for embedded platforms.

No. printk hits console drivers why may or may not be frame buffer
interfaces. Has done for a very long time. Keith Packard has also been
doing stuff with crash time oops displays etc over an X display.

> 4) Seperate out the VT emulation layer. Related to 3.

Separate from what ?

> 5) Multiple independent VT support. Which brings up the question what
> should the mapping of VCs to a VT look like.

I would suggest we borrow the X idea and each VC is

int display; /* Display it is on (for console flipping) */
struct something *vt; /* VT which it is displaying */
int x,y,w,h; /* Window onto vt */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Simmons on 29 Jul 2010 14:40

> > 3) Invert the VT layer. Currently the console/printk driver is on top of
> > the tty layer. It would be nice to be able to only use a very light
> > weight vt printk without the VT tty on top for embedded platforms.
>
> No. printk hits console drivers why may or may not be frame buffer
> interfaces. Has done for a very long time. Keith Packard has also been
> doing stuff with crash time oops displays etc over an X display.

Correct. What I mean is have the ability to just register the console
driver but not the tty driver.

> > 4) Seperate out the VT emulation layer. Related to 3.
>
> Separate from what ?

We can still have a basic tty layer without the control characters, think
do_con_trol in vt.c, junk compiled into the kernel. Make it a options for
userland to do the vt100 emulation.

> > 5) Multiple independent VT support. Which brings up the question what
> > should the mapping of VCs to a VT look like.
>
> I would suggest we borrow the X idea and each VC is
>
> int display; /* Display it is on (for console flipping) */
> struct something *vt; /* VT which it is displaying */
> int x,y,w,h; /* Window onto vt */

/dev/tty[0-16] -> VT display 0
/dev/tty[17-31] -> VT display 1

etc.

At least that is how I handled it several years ago.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio