linuxconsole-dev Mailing List for Linux Console Project (Page 148)

>    Okay I was hoping for more response or ideas. Their seems to be much
> confusion on what a head is and how to handle it properly in Linux. The
> confusion comes out of not knowing what we really need done and what
> things like a head are. It's hard to think of it off the top of your head.  
> I have thought about it and realized the wway to look at it is from a
> historical view point.

Sorry, had Stuff To Do(TM).


>   So you can see that in the days of mainframes multihead was done with
> ttys and their didn't exist the extra devices like their is today. So now
> we have migrated from a terminal to a head. What is the difference? Well a
> head can be though of as a extenstion of a terminal or better yet a
> terminal is a subset of a head. So a head is a place where a person can
> sit down and interface with a machine. The person experiences the
> virtual computer. The computer seems to belong to just him or her. You
> have a bunch of input devices that can manipulated by a single user and
> have a effect on what he/she experiences (usually a video screen). A
> terminal can now be one of these devices alongside other devices such as
> joysticks. Now that we know what a head is the next question is what makes
> a device belong to a head? A device belonging to a head means that data
> goes from the devices attached to that head to be displayed on a device
> attached to that head. In plain english what you do doesn't end up on
> someone elses head. You don't move someone else cursor or display your
> text on their screen. Now we have different types of devices that can be
> attached to a head. A input device or a output device or a device that
> does both. A input device would be a mouse. A output device would be a
> video card or a sound card. A device that does both would be a serial or
> video terminal. Also a device can behave as different types of devices. A
> sound card for example. You might want to have different sound card belong
> to different heads or you might have one sound card and have that piped
> into the entire office. So these are things to think about when it comes
> to the design of this new system.  

Also devices are often virtual now, not physical. For example an xterm is
the equivalent of a display in the old sense, with window focus allocating
one physical keyboard to the virtual keyboard inputs of the different
terminals.

We need to fix the console permissions model, because there are strange
controls on what you can do depending whether you are logged in on a
physical console.

I would also like to see network transparency: I would like for example to
be able to create a head using a keyboard on one machine and a display on
another (yes, so my working environment is particularly odd, but why not).
Hey, why not have a mouse somewhere else again... Moving input devices
should be quite easy with a single event queue model, though again there
are security issues (hey, just imagine someone hacks your box and you
see them actually type rm -rf /).

Justin

Hi everyone!!!

   Okay I was hoping for more response or ideas. Their seems to be much
confusion on what a head is and how to handle it properly in Linux. The
confusion comes out of not knowing what we really need done and what
things like a head are. It's hard to think of it off the top of your head.  
I have thought about it and realized the wway to look at it is from a
historical view point.

  Before the day of the PCs the computer industry was dominiated by
mainframes. They where huge massive machines that filled up a room.
Most often people didn't actually work in these rooms but in
seperate locations. People needed a way to access them. So something
called a tty was developed. A device that had a keybaord and a text
display built together. Many of devices where attached to the mainframes.
This allowed many employees to work at the same time on these mainframes.
So in essence we had the first multiheaded systems. Each tty became know
as a terminal. 
  Then the PC entered the market and as you know ended up pushing the
mainframes into a smaller market. The PC had a different design goal. It 
was a machine designed to be used by a single person. No one else could
attach themselves to you machine. Then companies needed these PC to talk
to each other but yet retain the local machine idea. A attempt to retain 
the old mainframe way of doing things. So you seen local networkes emerge
in offices. As time went on PCs now have shifted the design goal. They
now are becoming more multimedia oriented. So now you seen the developement 
of things like joysticks and soundcards etc. 
  Now in recent times technology has emerged that allows more than one of
the same type of device be attached to a PC. You could have a PS/2 mouse
and a serial mosue attached at the same time. The trend amplified even
more. Now with PCI bus you can have multiple video cards running in the
same PC. So now you can have the PC itself behave just like the old
mainframes used to. Today the term is called multihead. It's still the
same thing with the old mainframes. You can have mor ethan one person now
working on the same machine directly. The difference being the PC is much
smaller and cheaper then the old mainframes used to be. The other
difference is the PC has much greater variety of types of hardware you can
attached. The old mainframes just had the ttys. 
  So you can see that in the days of mainframes multihead was done with
ttys and their didn't exist the extra devices like their is today. So now
we have migrated from a terminal to a head. What is the difference? Well a
head can be though of as a extenstion of a terminal or better yet a
terminal is a subset of a head. So a head is a place where a person can
sit down and interface with a machine. The person experiences the
virtual computer. The computer seems to belong to just him or her. You
have a bunch of input devices that can manipulated by a single user and
have a effect on what he/she experiences (usually a video screen). A
terminal can now be one of these devices alongside other devices such as
joysticks. Now that we know what a head is the next question is what makes
a device belong to a head? A device belonging to a head means that data
goes from the devices attached to that head to be displayed on a device
attached to that head. In plain english what you do doesn't end up on
someone elses head. You don't move someone else cursor or display your
text on their screen. Now we have different types of devices that can be
attached to a head. A input device or a output device or a device that
does both. A input device would be a mouse. A output device would be a
video card or a sound card. A device that does both would be a serial or
video terminal. Also a device can behave as different types of devices. A
sound card for example. You might want to have different sound card belong
to different heads or you might have one sound card and have that piped
into the entire office. So these are things to think about when it comes
to the design of this new system.  

"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

On Wed, Apr 05, 2000 at 05:54:36PM +0000, Petr Vandrovec wrote:
> On  5 Apr 00 at 10:38, James Simmons wrote:
> >
> > [...]
> > 
> > Second Model:
> >   Create VT pools per head. In this model we have a each head behave
> > indpenedently. For each head you you can VT switch around but you can
> > never VT switch to another head. 
> I really do not want to have to buy another keyboard because of I have
> dualhead G400. Or what is definition of head and how is it supposed
> to work?

You can simply define a 'maguic' key, that switches the keyboard (or more
generic: input device) between vts.


Christoph

-- 
Always remember that you are unique.  Just like everyone else.

On Wed, Apr 05, 2000 at 10:38:38AM -0400, James Simmons wrote:

> First Model:
> 
>    The current kernel doesn't really handle this very well. The kernel has
> 32 virtaul consoles. Fbdev has a function con2fb that maps a framebuffer
> to a VT or set of VTs. This is done because the current console system
> can't handle multihead properly. Continuing to use this model we would map
> devices around. Many problems with this model :(
> 
> Second model:
> 
>   Create VT pools per head. In this model we have a each head behave
> indpenedently. For each head you you can VT switch around but you can
> never VT switch to another head. 
> 
> Any other models/ideas people can think of? Comments welcomed!

Now I won't talk about implementation, but about configurations the model
we choose must handle:

1) Single monitor, single keyboard, many VTs. Simple.

2) Any number of monitors, keyboards, VTs. There must be a working
console which the root can log on even without any setup.

3) Same number of monitors as keyboards. Separate heads with multiple
VTs each for separate users that can think they have a computer for
themselves each.

4) Single keyboard many monitors. Each monitor has a couple VTs, any can
be selected from the single keyboard.

These are the four basic scenarios we have to cover. If we handle more,
then even better, but we have to handle these.

-- 
Vojtech Pavlik
SuSE Labs

On  5 Apr 00 at 10:38, James Simmons wrote:
> Second issue:
>    The next question is how to handle multihead? Here are some models.
> ---------------------------------------------------------------------------
> First Model:
>    The current kernel doesn't really handle this very well. The kernel has
> 32 virtaul consoles. Fbdev has a function con2fb that maps a framebuffer
  ^^ 64
> to a VT or set of VTs. This is done because the current console system
> can't handle multihead properly. Continuing to use this model we would map
> devices around. Many problems with this model :(
I vote for this model. I do not know where problems with this model live.
Except that with correct code you can have two (or more) keyboards
attached to one VT then. But it is (useful) feature, not a bug. Even
Windows can have two mouses connected at one time, controlling one
mouse pointer together.
> Second Model:
>   Create VT pools per head. In this model we have a each head behave
> indpenedently. For each head you you can VT switch around but you can
> never VT switch to another head. 
I really do not want to have to buy another keyboard because of I have
dualhead G400. Or what is definition of head and how is it supposed
to work? 
                                Best regards,
                                        Petr Vandrovec
                                        van...@vc...
                                        

Hi!!

 Thanks to Vojtech major parts of the kernel have been updated. The
console system now interfaces with the way keyboards are handled by the
input suite. For people that want to use other devices as the keyboard for
the console look at the input device drivers for keyboards now that its
standardized (for brallie guy). Now that we have the input suite
and have fbdev cleanup. The next two big issues to tackle. 

First issue:

  How to cleanup up the console code. Its a mess. Many data structs no
longer needed etc. Also as pointed out when the group first formed. Alot
of stuff for serial consoels needless overlap with the serial console.
This needs to be cleaned up. Also we need to work on splitting up
console.c. Its just big and a mess. 

Second issue:
   The next question is how to handle multihead? Here are some models.

---------------------------------------------------------------------------
First Model:

   The current kernel doesn't really handle this very well. The kernel has
32 virtaul consoles. Fbdev has a function con2fb that maps a framebuffer
to a VT or set of VTs. This is done because the current console system
can't handle multihead properly. Continuing to use this model we would map
devices around. Many problems with this model :(

Second model:

  Create VT pools per head. In this model we have a each head behave
indpenedently. For each head you you can VT switch around but you can
never VT switch to another head. 

Any other models/ideas people can think of? Comments welcomed!
  

"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

I finished the port over of Vojtech changes for char/keyboard.c. Domini
take a look at it to get a fell for how the input suite interfaces with
the keyboard for the console. It needs more work. The multihead hack is
really poorly done. 

"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

> > I'm still working on Vojtechs stuff. The driver/char/keybaord.c code looks
> > like its needds lots of fixing.
> 
> Yes.  I ran in to a design defect in the keytables code: you can´t specify
> alternate sequences, which is quite important for 8-bit mode. If you look
> at the DEC keyboard tables you will find that the function keys and numeric
> keypad keys send CSI or SS3 as prefix with is different depending on whether
> you are in 7 or 8 bit mode.  I also found a couple of errors in the default
> keymap wrt to F1..F5: we are sending sequences i can not find in any doc
> from DEC...  Also we might have a bit of a problem implementing backarrow
> key mode and some other DEC keyboard related modes without changing the
> keyboard driver.  It that is worth the effort is yet another question.

I ported over the bulk of Vojtech work. It's in CVS. I didn't modified
keyboard.c and console.c and vt.c with Vojtech work. We have to work on
cleaning up the keyboard events to console mapping. We have to break it up
into peices. 

On Sat, Apr 01, 2000 at 10:29:59PM -0500, James Simmons wrote:

> I'm still working on Vojtechs stuff. The driver/char/keybaord.c code looks
> like its needds lots of fixing.

Yes.  I ran in to a design defect in the keytables code: you can´t specify
alternate sequences, which is quite important for 8-bit mode. If you look
at the DEC keyboard tables you will find that the function keys and numeric
keypad keys send CSI or SS3 as prefix with is different depending on whether
you are in 7 or 8 bit mode.  I also found a couple of errors in the default
keymap wrt to F1..F5: we are sending sequences i can not find in any doc
from DEC...  Also we might have a bit of a problem implementing backarrow
key mode and some other DEC keyboard related modes without changing the
keyboard driver.  It that is worth the effort is yet another question.

Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

> Great! I got myself a busy week too with lots of little problems eating my
> time.  Worst of all: my laptop has finally  broken down and i am to expect
> a courier from Dell on Monday to pick it up.  I've saved all my work, no
> sweat, but until i get it back there is not much development work possible:
> both my SS10 and my Multia have terrible turn-around times for kernel
> compilation.  Not to mention that 486DX-100 with is doubling as my ISDN
> router.
> 
> Good news is: i will be on vacation beginning mid-April for three weeks and
> i expect that i will find lots of time to do some coding...

Yikes. That's why you have been quite. After may I will be free this
summer. I will graduation from college and as of yet have no job so I will
have plenty of free time. Just need money to eat :( 

I'm still working on Vojtechs stuff. The driver/char/keybaord.c code looks
like its needds lots of fixing.

"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

More console problems. Its gives us something to work on and a way to test
this problem.

---------- Forwarded message ----------
Date: Sat, 1 Apr 2000 22:27:52 +0300
From: Oleg Drokin <gr...@cc...>
To: lin...@vg...
Subject: easy way to get "stuck" gpm on almost any kernel version.

Hello!

  I just found that if you switch to a console, where nobody listens, but only
  something is displayed (e.g. where your syslog puts its logs),
  then select large region of screen and paste it till it pastes,
  you cannot get your mouse cursor to move, as gpm seems to be blocked
  insside "paste_selection" from console.c
  Well, so you may decide to kill gpm..., if you do that, it did not day, no
  matter which signal you'll send to it. But after the signal, it starts to eat
  100% cpu time (system time). And it has no way to die, till somebody flushes
  vt buffers, somehow (kill syslog that writes to vt, for example).

  Now I swear of fork bomb, that also hogs CPU, and which you cannot kill...
  This behaviour was seen on 2.2.14, 2.2.15pre4 and 2.3.99-pre3,
  so I assume every kernel with selection support has this.

Bye,
    Oleg

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 01, 2000 at 10:12:26AM -0500, James Simmons wrote:
> 
> Hi folks!!!
> 
>   Well I have more free time now that my mid terms are behind me. Fbdev
> changes are pretty much finished. For now :) So today I will begain
> merging several patches I receieved and also will merged Domini work. The
> next step will be getting it to work with the input suite. I will commit
> this stuff sometime tonight EST. Have fun.

Great! I got myself a busy week too with lots of little problems eating my
time.  Worst of all: my laptop has finally  broken down and i am to expect
a courier from Dell on Monday to pick it up.  I've saved all my work, no
sweat, but until i get it back there is not much development work possible:
both my SS10 and my Multia have terrible turn-around times for kernel
compilation.  Not to mention that 486DX-100 with is doubling as my ISDN
router.

Good news is: i will be on vacation beginning mid-April for three weeks and
i expect that i will find lots of time to do some coding...

Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

Hi folks!!!

  Well I have more free time now that my mid terms are behind me. Fbdev
changes are pretty much finished. For now :) So today I will begain
merging several patches I receieved and also will merged Domini work. The
next step will be getting it to work with the input suite. I will commit
this stuff sometime tonight EST. Have fun.

"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

On 27 Mar 2000, Kirk Reiser wrote:

> I have anonymous but not commit access.  If you can tell me how to get
> it I'd appreciate it.  I've been working on synth drivers but want to
> turn back to merging things together as well.  If I can get one more
> driver working consistently I can lay off them for a while.

You have to get a sourforge.net account. Go to http://sourceforge.net for
this and then email me your sourceforge username. I will then add you to
the developement list.

I have anonymous but not commit access.  If you can tell me how to get
it I'd appreciate it.  I've been working on synth drivers but want to
turn back to merging things together as well.  If I can get one more
driver working consistently I can lay off them for a while.

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: ki...@br...		University of Western Ontario
phone: (519) 661-3061

On 10 Mar 2000, Kirk Reiser wrote:

> The Last time around, I put in a really nice, trust me nice!,
> description of the status of speakup with 2.3.x.  Unfortunately, I
> forget what all I said.  So I'll just post this and let the electrons
> fly.  Let us know when the cvs is ready for withdrawals! 'grin'
>   Kirk

I'm taking a look at it now. Sorry I have been quite. I have been buried
in writing code. A learned a interesting leason. Its faster to write
from scratch a new driver using the old driver with my new api then to
rewrite the driver. I'm almost done with the 3Dfx driver. I updated the
cvs against 2.3.99-pre3. I going to see how to merge your patch. Do you
have CVS access ? 

"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

>   I'm currently attempting to slap together an XFree4 driver for Vojtech's
> interface in my spare time.  I'm hoping that with it you'll be able to have
> X use a different keyboard than the kernel. Or, have two different X's use
> different keyboards, for multiseat purposes.  

This would be really nice.

>   As a matter of terminology, I think multiseat is a much better term for a
> system where multiple people can sit down and have independant sessions. 
> Were as multihead could also be just somebody with a 3840x1024 desktop. 
> Both have their uses, and are /really/ neat, but we do need to tell the
> ideas apart.
 
Alright. 

> So, if the console interface were able to handle
> this style of input events the whole mess could be handled from either
> userland or in the kernel, perhaps with some sort of fallover.

Right. 

>   userland: "cat /dev/evdev0 > /dev/consoledev0" effectivly attaches evdev0
> to console0. Ugly, but functional.

It should already be attached to the first console. I never liked the
idea of mapping devices from one head to another. Fbdev does this and it
has it problems. 

>   As for that fallover, what I meant by that is, maybe, any device(s) not
> explicitly claimed by anything else(any console) would just fall through to
> a default. That way no configuration would need to be done in the
> default/simplest case.  ei: you let the smoke out of your AT/PS2 keyboard
> port. No problem, just plug in a USB keyboard and everything is happy.

Hot pluggable devices will be fun to deal with. For a fully functional
console you want it to search for the one lacking that part and fill it
in.

>   Then, of course, there is the biggest reason for considering Vojtech's
> interface: It's allready in the kernel, via the USB code.

Yep.

"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

> > > 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.

> > *chuckle*  I chopped way too much out of that one :)  ok, the 
>conversation
> > was about just using /dev/inputX and /dev/fb, and doing the 
>multi-heading in
> > userspace.  You agreed that it was the way to go for multi-head aware
> > programs.  I'm asking if it's possible for a user-space program to 
>create a
> > device.  if it can, we could synthasize VT devices in userland, 
>redirecting
> > them through our app to the framebuffer.
>
>Telnet does exactly that, doesn't it?

excelent point...  so the entire thing could be done in user space, 
therefore not needing any blessings from linus or anyone else.  I'm going to 
retract myself from this conversation now letting you guys finish it, since 
i don't produce any actual code, and i'm no longer subscribed to the list. 
:)
(mailbox was getting too full)

Corey
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

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...

On Thu, 23 Mar 2000 jsi...@ac... wrote:

>> as a filter rule, and be done with it.  Please change this.
>
>I just fixed it :) 

Thanks..  I always wonder why a lot of mailing lists default to
putting stuff in the subject...  Some are fanatical about it
too..  On an 80 column screen though, you get to see like 8
characters of a subject line with the listname in every
message...  Makes it hard to read/locate messages, etc..

Take care!
TTYL

-- 
Mike A. Harris                                     Linux advocate     
Computer Consultant                                  GNU advocate  
Capslock Consulting                          Open Source advocate

I've overclocked my keyboard interface.  It's quite messy dipping my
hands into the mineral oil, but *MAN* is my keyboard ever fast now!
                                         - Anonymous Coward

On Thu, Mar 23, 2000 at 06:24:02PM +0000, Firstname Lastname wrote:

> *chuckle*  I chopped way too much out of that one :)  ok, the conversation 
> was about just using /dev/inputX and /dev/fb, and doing the multi-heading in 
> userspace.  You agreed that it was the way to go for multi-head aware 
> programs.  I'm asking if it's possible for a user-space program to create a 
> device.  if it can, we could synthasize VT devices in userland, redirecting 
> them through our app to the framebuffer.

Telnet does exactly that, doesn't it?

-- 
Vojtech Pavlik
SuSE Labs

> > >A view I share.
> >
> >
> > I haven't looked into it, but i seem to remember some stuff like 
>user-space
> > drivers...  is it possible to create a user-space device?  if so, you 
>could
> > simulate a device, for non-multihead aware programs.
>
>????
>


*chuckle*  I chopped way too much out of that one :)  ok, the conversation 
was about just using /dev/inputX and /dev/fb, and doing the multi-heading in 
userspace.  You agreed that it was the way to go for multi-head aware 
programs.  I'm asking if it's possible for a user-space program to create a 
device.  if it can, we could synthasize VT devices in userland, redirecting 
them through our app to the framebuffer.

Corey



______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

> >A view I share.
> 
> 
> I haven't looked into it, but i seem to remember some stuff like user-space 
> drivers...  is it possible to create a user-space device?  if so, you could 
> simulate a device, for non-multihead aware programs.

????

> > > > session starts because someone ran X on anther station requestion that
> > > > head you are on. I really like to see the X server some day just using
> > > > /dev/input and /dev/fb instead of any VTs like its does now.
> 
> how close does the XGGI "server" come to this?

It depends on libGGI which in turn uses VT code. I don't think libGGI uses
/dev/input yet. You have to ask on their mailing list.