Menu
▾
▴
linuxconsole-dev
|
From: Brad D. <Br...@NE...> - 2000-03-09 04:55:55
|
> -----Original Message----- > From: Brad Midgley [mailto:br...@tu...] > > I'd like to do a writeup with diagrams for the new console > system like I > did before, including the terminology we all agree on. (Head, console, > tty, etc.) Have we all agreed on what we call things? For > example, is a > crt an example of a head or is a head the collection of > multiple displays > and input devices used by a single person? First, I'd like to thank you for your last writeup. As I understand it (and have been corrected on), a head is a collection of input and output devices grouped around a single "display" (I can't think of a better word). I believe a console would be the currently selected head. That reminds me... Can there be only ONE console? In a multi-head environment, does each head have a console, or does the primary have the only console? Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: Brad D. <br...@ne...> - 2000-03-09 17:04:47
|
-----Original Message----- From: James Simmons <jsi...@ac...> > >> That reminds me... Can there be only ONE console? In a multi-head >> environment, does each head have a console, or does the primary have the >> only console? > >A console can be many things. It can be also a serial console like a real >vt100 plugged into your serial port. It can also be a virtual device built >from a keyboard and a video display. A head is a bit more flexiable. It's >a collect of input and output devices. A head is equal to a active VT >normally. If you ave more than one head than you have more than one >active VT. What I like to see is a raw interface to hardware devices >(/dev/fb,/dev/input, /dev/dsp) such a a userland app can grab them to >expand what a head is. This keeps the VT code simple and yet allows a >userland app great power. Of course you have to manage things so people >don't grab things that already belong to someone else. I guess a head could simply be defined as "A head is equal to an active VT". The definition of a head is implied by VT. My question didn't get answered, tho... Or maybe I'm using the wrong definition of console: Can there be two active consoles at the same time (in the instance of multi-head)? When I ask this, I'm thinking of say, kernel message output to console. Thanks, Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@ac...> - 2000-03-11 03:06:17
|
> I guess a head could simply be defined as "A head is equal to an active VT". > The definition of a head is implied by VT. No. More than one VT can be on a head. I like the idea of VT pools per head. Why do I call it pools. Because I like to think of it expandable and shrinkable. Right now their is 32 VTs. With a multihead system you would have number of heads * 32 VTs. This can get quite expensive. So you would start with one VT and if you VT switch grow a new VT. So teh VT pool grows. Only one VT can be active per head. > My question didn't get answered, tho... Or maybe I'm using the wrong > definition of console: Can there be two active consoles at the same time > (in the instance of multi-head)? When I ask this, I'm thinking of say, > kernel message output to console. I have though about that but have no answer. In a multihead system where should printk go to. Any suggestion anyone ? "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Steffen S. <s.s...@ph...> - 2000-03-13 08:44:02
|
James Simmons wrote: > > My question didn't get answered, tho... Or maybe I'm using the wrong > > definition of console: Can there be two active consoles at the same time > > (in the instance of multi-head)? When I ask this, I'm thinking of say, > > kernel message output to console. > > I have though about that but have no answer. In a multihead system where > should printk go to. Any suggestion anyone ? KGI currently takes the <int console_printk_console> to send kernel messages to. There can be functions implemented to alter this variable, so that e.g. that VT-switches on the 'system console focus' make kernel messages appear on the currently active one. However, this is a policy decision. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
From: James S. <jsi...@ac...> - 2000-03-16 03:17:06
|
> > I have though about that but have no answer. In a multihead system where > > should printk go to. Any suggestion anyone ? > > KGI currently takes the <int console_printk_console> to send kernel > messages > to. There can be functions implemented to alter this variable, > so that e.g. that VT-switches on the 'system console focus' make > kernel messages appear on the currently active one. > However, this is a policy decision. It should be displayed on every active console. I haven't thought about the details yet. I like to get multihead woking first. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Brad D. <Br...@NE...> - 2000-03-11 03:54:47
|
> -----Original Message----- > From: James Simmons [mailto:jsi...@ac...] > > > I guess a head could simply be defined as "A head is equal > to an active VT". > > The definition of a head is implied by VT. > > No. More than one VT can be on a head. I like the idea of VT > pools per > head. Why do I call it pools. Because I like to think of it > expandable > and shrinkable. Right now their is 32 VTs. With a multihead > system you > would have number of heads * 32 VTs. This can get quite > expensive. So you > would start with one VT and if you VT switch grow a new VT. > So teh VT pool > grows. Only one VT can be active per head. Yes, you're right. At it's core, a head can have (theoretcally) an unlimited number of VTs, but there will always be at least one. That's why I chose the wording I did. Perhaps it is too vague. > > My question didn't get answered, tho... Or maybe I'm using > the wrong > > definition of console: Can there be two active consoles at > the same time > > (in the instance of multi-head)? When I ask this, I'm > thinking of say, > > kernel message output to console. > > I have though about that but have no answer. In a multihead > system where > should printk go to. Any suggestion anyone ? At the present, I suggest a master/slave[x] designation somewhere in fbdev and have data destined for the console spew onto the master. I'll talk with Petr and ask for his input and experiences. I'll move further discussion of this thread to linux-fbdev, since it's really a fbdev issue. Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@ac...> - 2000-03-11 04:00:01
|
> > should printk go to. Any suggestion anyone ? > > At the present, I suggest a master/slave[x] designation somewhere in fbdev > and have data destined for the console spew onto the master. I'll talk with > Petr and ask for his input and experiences. I'll move further discussion of > this thread to linux-fbdev, since it's really a fbdev issue. Not really. What about the ability to send kernel output to the printer. Yes 2.3.X does have such ability. What about a system with a serial console and regular VT. Yes some PC motherboards are now starting to support serial consoles. The ia64 machines have both I believe. Which one do we send it to then. "Look it's a text editor, no it's a OS, no it's 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-11 04:01:55
|
One other thing. I will be moving my contining fbdev api changes to this tree. This way I can send all the changes right away to linus when 2.5.X comes out. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Brad M. <br...@tu...> - 2000-03-11 06:13:34
|
> At the present, I suggest a master/slave[x] designation somewhere in fbdev > and have data destined for the console spew onto the master. I'll talk with another thing people want to see is mirroring to two monitors (eg on a laptop with an external projector connected). it makes the most sense to have the kernel doing it (rather than, say, trying to hack X to drive two different framebuffers with the same image) Brad Turbolinux Frontier Group br...@tu... | http://www.turbolinux.com/~brad/ |
|
From: James S. <jsi...@ac...> - 2000-03-11 14:46:06
|
On Fri, 10 Mar 2000, Brad Midgley wrote: > > At the present, I suggest a master/slave[x] designation somewhere in fbdev > > and have data destined for the console spew onto the master. I'll talk with > > another thing people want to see is mirroring to two monitors (eg on a > laptop with an external projector connected). it makes the most sense to > have the kernel doing it (rather than, say, trying to hack X to drive two > different framebuffers with the same image) Have the kernel handle this would be messy. Have a api that allows a userland app to piece it together would be cleaner and easier to manage. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Brad D. <Br...@NE...> - 2000-03-11 16:15:24
|
> -----Original Message----- > From: James Simmons [mailto:jsi...@ac...] > > On Fri, 10 Mar 2000, Brad Midgley wrote: > > > another thing people want to see is mirroring to two > monitors (eg on a > > laptop with an external projector connected). it makes the > most sense to > > have the kernel doing it (rather than, say, trying to hack > X to drive two > > different framebuffers with the same image) > > Have the kernel handle this would be messy. Have a api that allows a > userland app to piece it together would be cleaner and easier > to manage. This should be handled by the low level driver. Not all cards support this (generally, only laptops do). I know with the ATI cards, it's a matter of flipping a register and doing some fixup. The same also applies with TV out. We could maybe add a new option to fbset to allow setting this. Thanks, Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: Brad D. <Br...@NE...> - 2000-03-23 03:15:14
|
> -----Original Message----- > From: James Simmons [mailto:jsi...@ac...] > > Not really. What about the ability to send kernel output to the printer. > Yes 2.3.X does have such ability. What about a system with a serial > console and regular VT. Yes some PC motherboards are now starting > to support serial consoles. The ia64 machines have both I believe. Which > one do we send it to then. FYI, I briefly looked into the issue of multiple kernel "consoles" in regard to multi-head. It does not appear to be an issue... There can only be one kernel console -- And it can be easily moved from device to device in userland (a program already exists). Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@ac...> - 2000-03-23 03:43:35
|
On Wed, 22 Mar 2000, Brad Douglas wrote: > > -----Original Message----- > > From: James Simmons [mailto:jsi...@ac...] > > > > Not really. What about the ability to send kernel output to the printer. > > Yes 2.3.X does have such ability. What about a system with a serial > > console and regular VT. Yes some PC motherboards are now starting > > to support serial consoles. The ia64 machines have both I believe. Which > > one do we send it to then. > > FYI, I briefly looked into the issue of multiple kernel "consoles" in > regard to multi-head. It does not appear to be an issue... There can > only be one kernel console -- And it can be easily moved from device to > device in userland (a program already exists). Yuck. I want to have all my video cards and keybaords boot up as fully functional consoles. Their are problems with con2fb. The biggest is no locking on SMP machines. With seperate VT pools on each display then life will be much easier. |
|
From: Brad D. <Br...@NE...> - 2000-03-23 03:47:34
|
> -----Original Message----- > From: James Simmons [mailto:jsi...@ac...] > > On Wed, 22 Mar 2000, Brad Douglas wrote: > > > > -----Original Message----- > > > From: James Simmons [mailto:jsi...@ac...] > > > > > > Not really. What about the ability to send kernel output to the printer. > > > Yes 2.3.X does have such ability. What about a system with a serial > > > console and regular VT. Yes some PC motherboards are now starting > > > to support serial consoles. The ia64 machines have both I believe. Which > > > one do we send it to then. > > > > FYI, I briefly looked into the issue of multiple kernel "consoles" in > > regard to multi-head. It does not appear to be an issue... There can > > only be one kernel console -- And it can be easily moved from device to > > device in userland (a program already exists). > > Yuck. I want to have all my video cards and keybaords boot up as fully > functional consoles. Their are problems with con2fb. The biggest is no > locking on SMP machines. With seperate VT pools on each display then > life will be much easier. You misunderstood me. I was referring to the console that gets kernel printk() output. This really doesn't have anything to do with VTs. Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@ac...> - 2000-03-23 04:25:56
|
> > Yuck. I want to have all my video cards and keybaords boot up as fully > > functional consoles. Their are problems with con2fb. The biggest is no > > locking on SMP machines. With seperate VT pools on each display then > > life will be much easier. > > You misunderstood me. I was referring to the console that gets kernel > printk() output. This really doesn't have anything to do with VTs. Oops. It makes sense to do it this way. Any opinions here ? "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Steffen S. <s.s...@ph...> - 2000-03-24 12:07:11
|
James Simmons wrote: > > > > Yuck. I want to have all my video cards and keybaords boot up as fully > > > functional consoles. Their are problems with con2fb. The biggest is no > > > locking on SMP machines. With seperate VT pools on each display then > > > life will be much easier. > > > > You misunderstood me. I was referring to the console that gets kernel > > printk() output. This really doesn't have anything to do with VTs. > > Oops. It makes sense to do it this way. Any opinions here ? As I wrote before, this is in my opinion the only reasonable soulution. There should be exactly one console that gets the printk messages if no klogd is running. If you want to have it on all consoles, run klogd and syslogd and have them spread the word on all consoles. Steffen PS: Think of what would happen in a multi-display environment if you would allow for any number of consoles getting printk() output from the in-kernel console_printk driver. Multihead is difficult enough so one should not complicate things more than neccessary. _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
From: James S. <jsi...@ac...> - 2000-03-25 03:25:43
|
> > > You misunderstood me. I was referring to the console that gets kernel > > > printk() output. This really doesn't have anything to do with VTs. > > > > Oops. It makes sense to do it this way. Any opinions here ? > > As I wrote before, this is in my opinion the only reasonable soulution. > There should be exactly one console that gets the printk messages > if no klogd is running. If you want to have it on all consoles, run klogd > and syslogd and have them spread the word on all consoles. > > Steffen > > PS: Think of what would happen in a multi-display environment if you > would allow for any number of consoles getting printk() output from > the in-kernel console_printk driver. Multihead is difficult enough > so one should not complicate things more than neccessary. Okay so this settles this. |
|
From: James S. <jsi...@ac...> - 2000-03-09 16:13:27
|
> As I understand it (and have been corrected on), a head is a collection of > input and output devices grouped around a single "display" (I can't think of > a better word). I believe a console would be the currently selected head. > > That reminds me... Can there be only ONE console? In a multi-head > environment, does each head have a console, or does the primary have the > only console? A console can be many things. It can be also a serial console like a real vt100 plugged into your serial port. It can also be a virtual device built from a keyboard and a video display. A head is a bit more flexiable. It's a collect of input and output devices. A head is equal to a active VT normally. If you ave more than one head than you have more than one active VT. What I like to see is a raw interface to hardware devices (/dev/fb,/dev/input, /dev/dsp) such a a userland app can grab them to expand what a head is. This keeps the VT code simple and yet allows a userland app great power. Of course you have to manage things so people don't grab things that already belong to someone else. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Jim P. <ji...@ag...> - 2000-03-09 20:33:52
|
James Simmons wrote:
> A console can be many things. It can be also a serial console like a real
> vt100 plugged into your serial port. It can also be a virtual device built
> from a keyboard and a video display. A head is a bit more flexiable. It's
> a collect of input and output devices. A head is equal to a active VT
> normally. If you ave more than one head than you have more than one
> active VT. What I like to see is a raw interface to hardware devices
> (/dev/fb,/dev/input, /dev/dsp) such a a userland app can grab them to
> expand what a head is. This keeps the VT code simple and yet allows a
> userland app great power. Of course you have to manage things so people
> don't grab things that already belong to someone else.
If I suggest a concrete example, can you tell me which are heads and which
are consoles ? This is hypothetical example, that I think may be possible,
if I understand correctly what is being suggested.
Let's say we have two desks back-to-back, a machine on the floor, with two
video cards, and two monitors, two keyboards, two mice plugged in. Two
people use that one machine, independently, running console-programs on
several screens (switched with Alt-Fn), and also running X-Windows and
X-Windows apps. Physically we have two independent `stations' (by which I'm
meaning seat-desk-keyboard-monitor). Are these two `heads' ? Or are they
two `consoles', with multiple `heads' being switched between with (Ctrl-)
Alt-F?.
Let's say we add a VT100 terminal on the next desk on a serial cable. Is
this another `console', or `head', or both ? Or is just one of these three
`stations' really considered to be the official `console' of the system ?
Things seem to get much more confusing if we think of someone with one
keyboard/mouse and two monitors, with some hot-keys to switch the stream of
input events between one monitor or the other (between the applications
visibly running on those monitors). But this could be seen as a kind of
emulation of the two `stations' above - somehow an emulation of two
keyboards/mice through just one.
Or is this too inflexible a viewpoint ? You may want your two monitors to
work in cooperation, perhaps moving apps from one monitor to the other, or
even having X-Windows spanning two monitors. To me this bunch of hardware
counts as one `station', but does it count as multiple `heads' or multiple
`consoles' as well ? Confusing.
Any thoughts ?
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim@aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
|
|
From: James S. <jsi...@ac...> - 2000-03-11 03:54:00
|
> If I suggest a concrete example, can you tell me which are heads and which > are consoles ? This is hypothetical example, that I think may be possible, > if I understand correctly what is being suggested. > > Let's say we have two desks back-to-back, a machine on the floor, with two > video cards, and two monitors, two keyboards, two mice plugged in. Two > people use that one machine, independently, running console-programs on > several screens (switched with Alt-Fn), and also running X-Windows and > X-Windows apps. Physically we have two independent `stations' (by which I'm > meaning seat-desk-keyboard-monitor). Are these two `heads' ? Or are they > two `consoles', with multiple `heads' being switched between with (Ctrl-) > Alt-F?. Okay. We have some confussion. A console is a device thats composed of a keyboard type of device and some video output. This can be a real console like a serial console. It can be a virtual terminal, meaning a fake or emulated serial console, thats made of a pc keyboard and a video card with monitor. To see different examples of different types of consoles look at the console_init function in tty_io.c. What you described above is a system with two ACTIVE consoles and several inactive consoles depending on how many different VTs both people are logged into. Say person one is logged into 3 different VTs and person 2 is logged in 5. Thus we have 6 ((5+3)-2 active) inactive console. A head is a bit different since its just a collect of input and output devices working together. In this example we have 2 heads. Let me give you a example of another type of a head. Imagine you work at a engineering company working on a CAD project. Now a team wants to work on this project. Say we have a multiheaded system with 8 keyboards and 8 fbdev devices so in essence we have 8 seperate active consoles. It would be ideal of each video output showed the same thing but each person at each console could modify that image on the screen. So each worker can alter in project in real time with respect to each other. So when the app would start you would open each /dev/fb and accept input from each keyboard/mouse from where each employee is sitting. So this is one head a app created that's composed of a several fbdev and input devices. Now in this case all the fbdev drivers show the same image. Now if really want to get fancy you could have it so each fbdev is a part of a big desktop. Imagine a projection on a wall made from a several fbdev images pieced together and the inputs be hooked to it. Each empolyee can look at the wall and you would see several cursors flying around doing abunch of things each independent of each other. Like one empolyee closing some window and another moving one. Consider a class of students with a teacher. Now their is only one computer with a bunch of keyboards and a bunch of video outputs devices. The teacher has one console go to his/her desk and the other consoles go to the students. Now the teacher wants to give a presentation. So the teacher wants what he/she has on her console displayed on all the students consoles. Now we don't want the students fooling around with the presentation so they are in essence locked out. The app the teacher starts grabs all their video outputs but not their keyboards. Here we have a head that composed of several video outputs and one keyboard. Of course you can create more than one head by say you doing both thing above at the same time. > Let's say we add a VT100 terminal on the next desk on a serial cable. Is > this another `console', or `head', or both ? Or is just one of these three > `stations' really considered to be the official `console' of the system ? All 3 would be a active console of the system. > Things seem to get much more confusing if we think of someone with one > keyboard/mouse and two monitors, with some hot-keys to switch the stream of > input events between one monitor or the other (between the applications > visibly running on those monitors). But this could be seen as a kind of > emulation of the two `stations' above - somehow an emulation of two > keyboards/mice through just one. Here you have one console (one keyboard/one monitor) and one floating monitor that free for a app to grab. Userland builds the head. The app could grab the keyboard and the two monitors. In this case this means any input is sent to both video outputs devices. > Or is this too inflexible a viewpoint ? You may want your two monitors to > work in cooperation, perhaps moving apps from one monitor to the other, or > even having X-Windows spanning two monitors. To me this bunch of hardware > counts as one `station', but does it count as multiple `heads' or multiple > `consoles' as well ? Confusing. See above. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Jim P. <ji...@ag...> - 2000-03-11 09:31:56
|
I'm clear about consoles - each of /dev/tty[1-6] and X-Windows in my example
is a separate console, only one of which is displayed at any one time.
I'm also clear about heads in sense of a bunch of hardware all somehow in
use together, by one person.
In your CAD example, those 8 keyboard/screen combinations could in fact be 8
heads, if used independently (one person checking his mail, the next
editing, whatever).
However, for your big everyone-work-on-the-same-screen example, they count
as just one head, right, that has 8 users ?
Clear I think.
When I was thinking about one keyboard and two monitors, I was thinking of
two independent consoles being displayed on the two monitors. If we have
hot-keys to switch the keyboard from one monitor to the other, then
effectively we have an emulation of two heads, since these two consoles are
independent. It's like constantly plugging the keyboard into one port or
the other, or having a switch-box in the line to switch between the two
ports.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim@aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
|
|
From: James S. <jsi...@ac...> - 2000-03-11 14:47:58
|
On Sat, 11 Mar 2000, Jim Peters wrote: > I'm clear about consoles - each of /dev/tty[1-6] and X-Windows in my example > is a separate console, only one of which is displayed at any one time. > > I'm also clear about heads in sense of a bunch of hardware all somehow in > use together, by one person. > > In your CAD example, those 8 keyboard/screen combinations could in fact be 8 > heads, if used independently (one person checking his mail, the next > editing, whatever). > > However, for your big everyone-work-on-the-same-screen example, they count > as just one head, right, that has 8 users ? > > Clear I think. You got it :) > When I was thinking about one keyboard and two monitors, I was thinking of > two independent consoles being displayed on the two monitors. If we have > hot-keys to switch the keyboard from one monitor to the other, then > effectively we have an emulation of two heads, since these two consoles are > independent. It's like constantly plugging the keyboard into one port or > the other, or having a switch-box in the line to switch between the two > ports. I rather see one head form from the one keyboard and one monitor. The other video display sort of hanges out their waiting for some userland app to grab it. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
×
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