RE: [Linuxconsole-dev] Welcome!!!

[Petr V. <VAN...@vc...>]

On  2 Mar 00 at 10:49, James A Simmons wrote:
> > > 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
                                                     64...
> a x amount to one fbdev head. Then a Y amount to another fbdev head etc.
> > >     * 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 do not see, what this bring to normal user or to kernel code. I can
understand that we may want to have per-keyboard mapping from
1..24 -> global VC number, but I do not see reason why I cannot move
VC from one head to another. Do not forget that only minority of users
will run boxes in dangerous environment where you want strictly splitted
head0 user/resources/... from head1 user/resources. In most applications
you just have two keyboards and two monitors. And you want to
select two of your 64 VCs to be visible/controllable at one time...
> > 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. 
You should not lock VT pool, but one VT. And for console switch, you must
obtain lock on current VT, future VT and, - if we'll write it that way -
on framebuffer. But locking current VT can lock fb implicitly.
> > >     * fbcon backwards compatibility,
> I'm working on that now with the new fbdev API.
'New fbdev API' does not look like backward compatibility stuff.
> > >     * 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?
> 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.
More I think about this, more I believe that we should split problems
on per-driver basis to userspace and kernel, and create userspace library
providing an industry interface (OpenGL(, DirectX) or ...). From what
I see graphics engines are way too different to put all emulation into
kernel (in other way, I do not believe in DRI future, unless it is more
powerfull than I think (I tried to get some info about that company
and their products after press release from Jan 12 that PI will write
Matrox drivers for Linux, but I failed... maybe I choosed wrong email)).
                                                Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...