Menu
▾
▴
linuxconsole-dev
|
From: Brad D. <Br...@NE...> - 2000-03-01 22:34:06
|
> -----Original Message----- > From: Jon M. Taylor [mailto:ta...@ec...] > > Well, I don't think that I can help with this too much - my web > design skills are pretty bad. Looka t > http://libggi3d.sourceforge.net to > see what I am capable of > |->. Rockin! :) > I think that we have three major areas of concern which > will drive > the design of this project: > > 1: What do we need? > * Better multiheading, Each head should have it's own console. Is this already being worked on now? > * 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 don't think this will be easily backward compatible and are there possible race conditions with each head having it's own VTs? > * fbcon backwards compatibility, > * /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? > 2: What does Linus want? Beer? > 3: What will Linus accept into 2.5.x? > > EvStacks was a _really_ good design, but I guss it was > too complex > and ambitious for Linus. Therefore, we really need to know > where Linus > stands on the issues before we do any significant amount of > design work > this time around. I'm slowly still looking over EvStacks... No opinions, yet. Thanks, Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: Petr V. <VAN...@vc...> - 2000-03-02 16:47:08
|
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...
|
|
From: Jon M. T. <ta...@ec...> - 2000-03-02 21:44:43
|
On Thu, 2 Mar 2000, Petr Vandrovec wrote: > 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. Right, that should definitely be possible. A console is just another type of possible output device, which should be mappable/bindable to a head context just like any other output device (framebuffer, serial port, network pipe, etc). > 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... Well, I do not think that designing the console system only to handle the simplest cases is very wise. If we design a flexible enough system, we will not have to go back and redesign it when someone wants to run e.g. three braille readers and no monitors |->. > > > 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. The special association between framebuffer devices and consoles should be removed IMHO. Both TTYs and framebuffer devices should be treated as just some types of input and output devices, and the only thing special about them is that they can be bound together to produce this type of device we call a console, along with a keyboard or serial port devices. I think that this would simplify things a lot. > > > > * fbcon backwards compatibility, > > I'm working on that now with the new fbdev API. > 'New fbdev API' does not look like backward compatibility stuff. devfs isn't backwards compatible either, unless you use devfsd. We could provide 'consoled' if we needed to, which would allow us to keep ~100% backwards compatibility and also give us much more design freedom. These are the type of issues I would really like Linus' opinion on.... > > > > * 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 ...). This is exactly what GGI has been preaching for years now, and the design of KGI and LibGGI is build around this concept. It doesn't make sense for the kernel to have to know all the little details of different types of graphics hardware, or input devices, or all of the possible interactions between them. It is just too complex and changes too rapidly. The kernel should define some quite abstract systems for defining input devices, output devices, messaging systems, and binding systems for pulling it all together. This keeps the complexity out of the kernel core, allows maximum flexibility of driver design and user interface structure, and actually makes things _simpler_ for the kernel coders since everything in the non-driver kernel code is kept nice and abstract. > From what > I see graphics engines are way too different to put all emulation into > kernel Yes. The drivers must be able to talk to and listen from userspace in very finely-tuned and hardware-specific ways, in order to keep down kernel bloat and allow for maximum optimization potential. There is no way to do this properly if the kernel APIs have to care about the little details of the hardware capabilities and interfaces. This is why input devices must be abstracted as EvStacks and Voichek's unified input devices work have done, and why display hardware must be virtualized at a quite abstract level (buffermap/command FIFO/resource lock) as KGI does. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed |
|
From: James S. <jsi...@ac...> - 2000-03-05 03:56:38
|
> Right, that should definitely be possible. A console is just > another type of possible output device, which should be mappable/bindable > to a head context just like any other output device (framebuffer, serial > port, network pipe, etc). I have no problem of creatings a VT per head. But this moving a VT around from head to head is a nightmare. If a app wants to use a VT thats on anoteh head just look to see if its in use then grab it. > > 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. > > The special association between framebuffer devices and consoles > should be removed IMHO. And it is. The console code is being moved up and out to fbcon.c which really is apart of the console system. I hope to see the same from Vojtechs input system. > Both TTYs and framebuffer devices should be > treated as just some types of input and output devices, and the only thing > special about them is that they can be bound together to produce this type > of device we call a console, along with a keyboard or serial port devices. > I think that this would simplify things a lot. Thats right. This can be seen in the new fbdev coming up over the horizon. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: James S. <jsi...@ac...> - 2000-03-05 03:26:52
|
> but I do not see reason why I cannot move VC from one head to another. Why? > 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... Withe fbdev in theory you can up to 256 displays. 64 isn't going to cut it. Also how do we split the 64 VC between 9 fbdev/keyboards. This is a odd number which we have to write special code for. > > I'm working on that now with the new fbdev API. > 'New fbdev API' does not look like backward compatibility stuff. Okay. Almost. > 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)). Something is wrong. We agree about DRI. Don't feel bad. Most kernel developers that have sent them email seems to disappear into a black hole. So far I'm the only one they responded to. That's because they don't like me since i point out their design flaws. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Jon M. T. <ta...@ec...> - 2000-03-01 23:49:03
|
On Wed, 1 Mar 2000, Brad Douglas wrote: > > -----Original Message----- > > From: Jon M. Taylor [mailto:ta...@ec...] > > > > I think that we have three major areas of concern which > > will drive > > the design of this project: > > > > 1: What do we need? > > * Better multiheading, > > Each head should have it's own console. Is this already being worked on > now? Yes. EvStacks maps a "scroller" (/dev/tty) onto a VT, connects some event sources/sinks to the VT, and presto you have a console. James and the other console developers appear to be thinking along similar lines. > > * 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. Careful, a "head" is really just the set of all input and output devices, and their associated event handling 'map', whcih are being used by one person. A binding, basically. A "console" in the traditional UNIX sense is a keyboard and a TTY. A head could consist of a VT102 terminal, or a standard PC keyboard + mouse + monitor + joystick, or even extreme cases like two monitors, a braille touchpad on a serial port, a USB joystick and keyboard, and no /dev/tty at all. Heads and consoles are often the same thing, but sometimes they will be quite different. > I don't think this will be easily backward compatible > and are there possible race conditions with each head having it's own VTs? Yes, this could be an issue. Right now I advocate head == VT, but for multi-monitor and such things this could get real ugly real fast |->. Watch the kernel remap a dozen different widely varying types of input and output devices back and forth every time you switch VCs! Drown in races! Throw spinlocks all over the place! Get into remote event handling and watch your network latency become your user interface latency! Etc etc etc. Of course we will probably want to be able to do most or all of this type of stuff, but Linus may balk at adding such complexity to the kernel, at least all in one go |->. IMHO, this is an issue for Linus to decide. > > * fbcon backwards compatibility, > > * /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? More or less. It would be very cool if we could design this new console system such that it could easily support and plug into /dev/gfx, DRI, KGI, fbdev, or any other potential kernel graphics (and input device) driver framework(s). That way we have a lot fewer issues to have religious wars over |->. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed |
|
From: James A S. <jsi...@ac...> - 2000-03-02 16:56:00
|
> Yes. EvStacks maps a "scroller" (/dev/tty) onto a VT, connects > some event sources/sinks to the VT, and presto you have a console. James > and the other console developers appear to be thinking along similar > lines. Yes. The move is to have each fbdev driver unaware of the console system. Fbcon is the interface from fbdev to the console system. > Careful, a "head" is really just the set of all input and output > devices, and their associated event handling 'map', which are being used > by one person. A binding, basically. A "console" in the traditional UNIX > sense is a keyboard and a TTY. A head could consist of a VT102 terminal, > or a standard PC keyboard + mouse + monitor + joystick, or even extreme > cases like two monitors, a braille touchpad on a serial port, a USB > joystick and keyboard, and no /dev/tty at all. Heads and consoles are > often the same thing, but sometimes they will be quite different. Very true. Consider a workstation with several sound cards. Each employee wants to listen to his own stuff. You have to make sure it goes to the right person. This has to be done. > Yes, this could be an issue. Right now I advocate head == VT, but > for multi-monitor and such things this could get real ugly real fast |->. > Watch the kernel remap a dozen different widely varying types of input and > output devices back and forth every time you switch VCs! Drown in races! > Throw spinlocks all over the place! Get into remote event handling and > watch your network latency become your user interface latency! Etc etc > etc. Of course we will probably want to be able to do most or all of this > type of stuff, but Linus may balk at adding such complexity to the kernel, > at least all in one go |->. IMHO, this is an issue for Linus to decide. KISS. See my other post about what a tty is to linus. > > How does this fit in with DRI (I'm unable to find decent documentation)? > > Are gfx and DRI trying to do the same thing? > > More or less. It would be very cool if we could design this new > console system such that it could easily support and plug into /dev/gfx, > DRI, KGI, fbdev, or any other potential kernel graphics (and input device) > driver framework(s). Removing the consoel system from hardware drivers is the way to go IMHO. |
|
From: Jon M. T. <ta...@ec...> - 2000-03-02 22:03:34
|
On Thu, 2 Mar 2000, James A Simmons wrote: > > Careful, a "head" is really just the set of all input and output > > devices, and their associated event handling 'map', which are being used > > by one person. A binding, basically. A "console" in the traditional UNIX > > sense is a keyboard and a TTY. A head could consist of a VT102 terminal, > > or a standard PC keyboard + mouse + monitor + joystick, or even extreme > > cases like two monitors, a braille touchpad on a serial port, a USB > > joystick and keyboard, and no /dev/tty at all. Heads and consoles are > > often the same thing, but sometimes they will be quite different. > > Very true. Consider a workstation with several sound cards. Each employee > wants to listen to his own stuff. You have to make sure it goes to the > right person. This has to be done. Right, and this is easy if you decide not to treat any particular I/O hardware or abstraction any differently from any other. You have event and data sources from input devices (keyboard, mouse, joystick, remote network event sources, dummy devices, etc) and output devices (framebuffer, TTY console, /dev/dsp, remote network event sinks, etc). Event "packets" are generated by event sources, flow to event sinks according to simple rulesets, and are handled by the event sinks. As with TCP networking, the kernel is basically a traffic cop. If you do this, suddenly the kernel does not have to deal with a lot of issues that it does now. The kernel does not need to care about anything but the proper routing of abstract events according to internal tables, just as it now does not have to care about what is inside the TCP packets (well sort of, you know what I mean). It just handles them properly and lets the userspace applications figure out what they _mean_. Likewise, if you define a "head" as a binding of input devices and output devices with some rules about where the events are routed, the kernel does not have to care about the nature of the individual devices which are bound into the head. Whether the head is a VT102 terminal on a serial port or a very complex multihead+remote setup as has been described before does not matter _at all_ to the kernel. > > Yes, this could be an issue. Right now I advocate head == VT, but > > for multi-monitor and such things this could get real ugly real fast |->. > > Watch the kernel remap a dozen different widely varying types of input and > > output devices back and forth every time you switch VCs! Drown in races! > > Throw spinlocks all over the place! Get into remote event handling and > > watch your network latency become your user interface latency! Etc etc > > etc. Of course we will probably want to be able to do most or all of this > > type of stuff, but Linus may balk at adding such complexity to the kernel, > > at least all in one go |->. IMHO, this is an issue for Linus to decide. > > KISS. See my other post about what a tty is to linus. Well, if Linus were to allow an abstracted system like the one outlined above, it would certainly be _different_ from what we have now. But would it be more complex? I say no! I think it would be quite a bit simpler conceptually, actually. But we'll see what Linus is willing to accept, I guess. > > > How does this fit in with DRI (I'm unable to find decent documentation)? > > > Are gfx and DRI trying to do the same thing? > > > > More or less. It would be very cool if we could design this new > > console system such that it could easily support and plug into /dev/gfx, > > DRI, KGI, fbdev, or any other potential kernel graphics (and input device) > > driver framework(s). > > Removing the consoel system from hardware drivers is the way to go IMHO. Yes. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed |
|
From: James A S. <jsi...@ac...> - 2000-03-02 15:52:53
|
> > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X