RE: [Linuxconsole-dev] Welcome!!!

[James A S. <jsi...@ac...>]

> > 1: What do we need?
> > 	* Better multiheading,
> 
> Each head should have it's own console.  Is this already being worked on
> now?

Note really. The current implementation is we have 32 consoles and we map
a x amount to one fbdev head. Then a Y amount to another fbdev head etc.
If you insmod a fbdev driver you can use con2fb to map a console or group
of consoles to this new fbdev driver.

> > 	* Cleaner and more abstract [virtual] console representation,
> 
> I like the idea of moving /dev/fbx to /dev/fb/fbx/,fbx+1/... and each head
> having it's own VTs.  

I do like the idea of having VT pools to each head. This way these VTs
keep out of each others way. It should be (using devfs) 

/dev/head0/vc/1
/dev/head0/vc/2

...
/dev/head1/vc/1
/dev/head1/vc/2

The only thing is figureing out which head we are on. Thus we need a
/dev/vc/0 that tells us that. 

> I don't think this will be easily backward compatible
> and are there possible race conditions with each head having it's own VTs?

No. Even less since we don't have to locks for two different heads trying
to execute the same code. With each VT pool only one VT is active at a
time. 

> > 	* fbcon backwards compatibility,

I'm working on that now with the new fbdev API.

> > 	* /dev/gfx integration,
> > 	* Abstract input devices and event flow graphing,
> > 	* ...others...
> 
> How does this fit in with DRI (I'm unable to find decent documentation)?
> Are gfx and DRI trying to do the same thing?

The input stuff as already been tempted by Vojtech. GFX and DRI should
have nothing to do with the console system. They should only make sure the
person is on the local console to allow access. No remote rendering. As a
side note DRI is aimed at lower end hardware. GFX is aimed at more modern
and higher level hardware. DRI is far to limited in design to work on SGI
hardware. SGI hardware isn't like PC hardware where you program a few
register and draw a triangle. Its composed of ~50 APIC which allow it to
have a very deep parrallel graphics pipeline. You can't even just mmap the
MMIO regions on a SGI workstation. Some of memory space is cached and some
is uncacheable. SGI graphics hardware often uses both types of memory.
Thus you need to use a ioctl call to mmap a region. Enough on that.

> > 2: What does Linus want?
> 
> Beer?

Ha Ha!

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net