linuxconsole-dev

More cleanups in CVS

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

Hi!

  My changes last night broke some of the console system so I had to
rework it today. What is in CVS will compile and work. Its against the
linux-2.4.0-test2-pre2. Their still is a problem with VT switching and yes
the problem is in the console code. I tested it using chvt which uses a
app to change the VC via a ioctl call. Still need to track it down. I will
be working on it tomorrow. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

input/atkbd.c

[Christian H. <ch...@ku...>]

Hello again,

_____atkbd.c_____L435_____________________

	atkbd->dev.idbus = BUS_I8042;
	atkbd->dev.idvendor = 0x0001;
	atkbd->dev.idproduct = atkbd->set;
	atkbd->dev.idversion = 0x0100;
__________________________________________

The 'struct atkbd' has no members of these names and BUS_I8042 is not defined.
Is it a bug or resynch problem?

Christian.

Re: fb subsystem (fbmem.c)

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

On 21 Jun 00 at 15:02, Christian Helmuth wrote:
> 
> _____fbmem.c_____L653__________________________________
> 
>     /*
>      *  Probe for all builtin frame buffer devices
>      */
>     for (i = 0; i < num_pref_init_funcs; i++)
>         pref_init_funcs[i]();
> 
>     for (i = 0; i < NUM_FB_DRIVERS; i++)
>         if (fb_drivers[i].init)
>             fb_drivers[i].init();
> _______________________________________________________
> 
> 
> 1. pref_init_funcs[]()  inits all fbdevs from the boot param line, right?
> 2. fb_drivers[]()       inits the rest, right?
> 
> -> so we init ALL fbdevs. Some with boot params and some without?!

Yes. All framebuffers have some default settings, so there is no need
for having mandatory boottime options (except for vfb).
You can also reorder and disable your framebuffers using these passed
cmdline options (video=XXXXX:off disables such XXXXX framebuffer).
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    
                                                    
                                                    
                        

fb subsystem (fbmem.c)

[Christian H. <ch...@ku...>]

Hi,

After I analysed the init of the frame buffer subsystem (and tried to
understand __setup_# and check_setup() stuff ;-), I'm not sure I got the sense
of the following:

_____fbmem.c_____L653__________________________________

	/*
	 *  Probe for all builtin frame buffer devices
	 */
	for (i = 0; i < num_pref_init_funcs; i++)
		pref_init_funcs[i]();

	for (i = 0; i < NUM_FB_DRIVERS; i++)
		if (fb_drivers[i].init)
			fb_drivers[i].init();
_______________________________________________________


1. pref_init_funcs[]()  inits all fbdevs from the boot param line, right?
2. fb_drivers[]()       inits the rest, right?

-> so we init ALL fbdevs. Some with boot params and some without?!

Thank you,
Christian.

CVS update to test2-pre2

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

Everything has just been updated in CVS to test2-pre2. So it should
compile. Also I add input to all platforms config.in file. Now you can
select input drivers on any system :) Now to test the code in depth.
Vojtech did you find out if the problem with VC switching is related to
ruby or the input code?

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Updates in CVS

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

> True. I'll remove the changes if needed, but I hope we could move a
> little forward with the kernel we're basing our work on - the 2.4.0test1
> kernel is getting old namely with respect to USB, which is making work
> hardwr for me.

I already did. Last night I updated to 2.4.0-test2-pre1. I will update to
test2-pre2 this morning. 

Re: 2.4.0-test2-pre1 compile error

[Alan C. <al...@lx...>]

> I discovered a small problem with the files in 2.4.0-test2-pre1 with
> fops_get and fops_put in input.c. It appears they have disappeared. As the
> files in the console project CVS have teh smae problem. Do you have a
> patch for this. Thanks.

We are still resynching. Be patient

Re: Updates in CVS

[Vojtech P. <vo...@su...>]

On Mon, Jun 19, 2000 at 09:43:33PM -0400, James Simmons wrote:
> 
> > This bug is either in keyboard.c or somewhere closer to the console.
> > I'll try the input stuff with a clean kernel, and see if it happens even
> > without the VT/VC changes.
> 
> Okay. Let me know the results. Also I noticed that the code you put into
> CVS is using a more up to date kernel then what we have been using.

True. I'll remove the changes if needed, but I hope we could move a
little forward with the kernel we're basing our work on - the 2.4.0test1
kernel is getting old namely with respect to USB, which is making work
hardwr for me.

-- 
Vojtech Pavlik
SuSE Labs

2.4.0-test2-pre1 compile error

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

I discovered a small problem with the files in 2.4.0-test2-pre1 with
fops_get and fops_put in input.c. It appears they have disappeared. As the
files in the console project CVS have teh smae problem. Do you have a
patch for this. Thanks.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Updates in CVS

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

> This bug is either in keyboard.c or somewhere closer to the console.
> I'll try the input stuff with a clean kernel, and see if it happens even
> without the VT/VC changes.

Okay. Let me know the results. Also I noticed that the code you put into
CVS is using a more up to date kernel then what we have been using.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Updates in CVS

[Vojtech P. <vo...@su...>]

On Mon, Jun 19, 2000 at 03:27:04PM -0400, James Simmons wrote:

>    I have been moving slowly the new console code into CVS. The code has
> been tested with vgacon so eveyerthing works. I see new code for the input
> stuff. I have been having problems with VC switching. For VCs I have
> already logged into when I VC switch the new VC isn't draw until I press
> another key. When I VC switch to a console that has minigetty running but
> I haven't logged in it takes alot of keypresses to see the screen. I
> haven't tried the most recent changes to the input layer in CVS. I'm going
> to try it now. 

This bug is either in keyboard.c or somewhere closer to the console.
I'll try the input stuff with a clean kernel, and see if it happens even
without the VT/VC changes.

-- 
Vojtech Pavlik
SuSE Labs

Updates in CVS

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

Hi!

   I have been moving slowly the new console code into CVS. The code has
been tested with vgacon so eveyerthing works. I see new code for the input
stuff. I have been having problems with VC switching. For VCs I have
already logged into when I VC switch the new VC isn't draw until I press
another key. When I VC switch to a console that has minigetty running but
I haven't logged in it takes alot of keypresses to see the screen. I
haven't tried the most recent changes to the input layer in CVS. I'm going
to try it now. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Updates

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

I finally got the new console code to compiloe and now it is in the
testing phase. I'm hoping to have it ready by Wednesday. I will post as
soon as I get it to work. Note only vgacon will work with the new console
system. I will update teh other drivers later.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: sysrq on serial port build problem

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

> with console on the serial port and no virtual console turned on in the
> kernel.  i tried to enable "Magic SysRq key" but got this error.
...
> kernel/kernel.o(.data+0x1fb4): undefined reference to `sysrq_enabled'
> make: *** [vmlinux] Error 1
>
> the error goes away when i turn on virtual console.

The reason for this is because sysrq_enabled is in keyboard.c which is
only compiled into the kernel when you have VT support. Vojtech can
you with linus tree use USB keyboards independent of VTs? Do you think
its possible to make a patch against linus tree that allows sysrq
independent of VT support. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Consolechars Doubt

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

---------- Forwarded message ----------
Date: Fri, 16 Jun 2000 20:05:17 +0200
From: Andries Brouwer <ae...@ve...>
To: Ratheesh KrishnaVadhyar <ra...@pe...>
Cc: lin...@vg...
Subject: Re: Consolechars Doubt

On Fri, Jun 16, 2000 at 08:09:34PM +0530, Ratheesh KrishnaVadhyar wrote:

> 	I am a student trying to develop a PSF file for supporting a
> Regional language. For some characters, I need to have multiple glyphs,
> as console doesnt support variable width fonts. We can have a keymap to do
> this , but this actually generates multiple ASCII values and hence wont be
> compatible with other existing ttf/bdf fonts available for X, where there
> is only one ASCII code for a character. 
> 
> 	Can we have a 1 to many mapping from ASCII values to
> glyphs in the PSF/ACM file ? (ie. , can we have multiple glyphs displayed
> for same key pressed?) If this support is not present , what are the
> changes/ configurations that we need to do to support this? 

consolechars is from the console-tools package, a fork of the kbd
package that I know very little about.

The kbd package has some added support for something that almost
sounds like the opposite you are asking: a single font position
described by a sequence of Unicode symbols.
(I needed that last year for Tibetan.)

So, answering your question:
(i) No, as far as I know there is no direct support that will let
the kernel display a sequence of glyphs for a single symbol.
(ii) It would be very easy to extend the psf2 format to allow
this. But a kernel patch would be required.
If you want to discuss this, mail ae...@cw.... I can make the kernel
patch (maybe have it already) and add a version to the psf2 format
so that the kbd utilities will support this. Tell me about the language,
the alphabet, what you use under X and what you want to use on the
console.
(iii) For many somewhat more complicated languages, where the shape
of the representation for a letter depends on the context,
one can get 95% solutions with some kernel kludges, but in the end
a user-space solution with a program reading a pseudo-tty and handling
the screen is the only real good solution.

Andries

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

Keymapping vunerability (drivers/char/vt.c) (fwd)

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

---------- Forwarded message ----------
Date: Thu, 15 Jun 2000 23:10:25 +1000
From: Stephen Thorne <sjt...@oz...>
To: lin...@vg...
Cc: Herbert Xu <he...@go...>, 65...@bu...
Subject: Keymapping vunerability (drivers/char/vt.c)

G'day

The basis to this security vunerability is extremely simple.
As it stands, any user who owns a tty can remap the keyboard
for the entire system. I consider this to be a security risk.

Consider the following situation.

Nefarius person gains access to a tty (can't be telnet, must
be a bona fide tty) and type the following

theseus:~$ loadkeys
string F55 = "\nfoobar\n"
keycode 69 = F55
theseus:~$

Then, a legitimate user logs into the system, and when that
person goes to use the numlock (in this example, to type
a student number)

theseus:~$ finger s
finger: s: no such user.
theseus:~$
theseus:~$ foobar

not only can something as blatantly obvious as this be
achieved, but other, more carnivorous commands can be used
for example, replace foobar with
\necho keycode 101 = F1 F1 F1 F1 F1 F1 F1 F1 F1 |loadkeys\n Nrm -rf /\n

i.e. disable control break, then procede to erase the
entire system.

An.... unusal reason way for someone to use numlock to say the
least.

Attached is a diff that will cause the kernel to check for
superuser permissions before allowing someone to change
the scancode->keycode mappings, key strings or the
keymappings.

Steve.

Re: (Multihead) Console Blanking

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

> The problem is, that if you read it there have been a lot of code changes
> since the patch was written.  The console has been separated out a lot more
> since then. I suppose the patch could be used for ideas. I will try and dig it
> out and attach it.

Thank you for the code. I glanced over it and see it is more than just
multihead blanking support. Its multihead support. No problem. I know the
console code well enough to see what you are doing. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: (Multihead) Console Blanking

[Vojtech P. <vo...@su...>]

On Wed, Jun 14, 2000 at 09:55:14AM -0400, James Simmons wrote:
> 
> > James Simmons <jsi...@ac...> wrote:
> > > I'm one of the ones working on the new console system. Real multihead, meaning
> > > the console system supports mulitple displays and multiple keyboards, needed a
> > > big code rewrite of the console system so it should hold off to 2.5.X. Have 
> > > you come up with a solution by the way for multihead blanking. I haven't :(
> > > Ideas anyone? 
> > 
> > I played with a patch to support the MDA as a second monitor when I was using
> > 2.0.x, that supported screen blanking on both monitors. I will dig the patch
> > out and have a read. How are you going to do multiple keyboards? USB? Or is
> > all of that kind of stuff in an FAQ I have not spotted?
> 
>     You have a patch. Great :) Could you reply with the patch. Thank you
> very much. 
>     As for keyboards using Vojtech's input devices we support multiple
> keyboards via USB. Also you can do what I have. Plug one ps/2 into the
> ps/2 keyboard port and another one into the ps/2 mouse port. Then you can 
> attached a sun keyboard via the parrallel port. I have the sun keyboard
> but you need to build the adapter yourself which I haven't done yet. 

Sun keyboards connect to the serial port. AT keyboards can be attached
to KBD, AUX and parallel ports.

-- 
Vojtech Pavlik
SuSE Labs

Re: (Multihead) Console Blanking

[Edward B. <ed...@de...>]

Edward Betts <ed...@de...> wrote:
> James Simmons <jsi...@ac...> wrote:
> >     You have a patch. Great :) Could you reply with the patch. Thank you
> > very much. 
> 
> No dude, I think one of us may have misunderstood the other. I used a patch,
> written for Linux 2.0.x, that allowed me to use my computer multihead with the
> VGA monitor as the first head, and an IBM MDA as the second head. That patch
> had support for blanking on both monitors. I think you probably got that bit.
> The problem is, that if you read it there have been a lot of code changes
> since the patch was written.  The console has been separated out a lot more
> since then. I suppose the patch could be used for ideas. I will try and dig it
> out and attach it.
> 
> Found it, I think. It is a 100k .tar.gz, I do not want to mess with the
> mailing lists, you can have it in a separate private mail. 

Sorry, sent it to the mailing lists be accident.

-- 
Don't worry  --  shop.

Re: (Multihead) Console Blanking

[Edward B. <ed...@de...>]

James Simmons <jsi...@ac...> wrote:
>     You have a patch. Great :) Could you reply with the patch. Thank you
> very much. 

No dude, I think one of us may have misunderstood the other. I used a patch,
written for Linux 2.0.x, that allowed me to use my computer multihead with the
VGA monitor as the first head, and an IBM MDA as the second head. That patch
had support for blanking on both monitors. I think you probably got that bit.
The problem is, that if you read it there have been a lot of code changes
since the patch was written.  The console has been separated out a lot more
since then. I suppose the patch could be used for ideas. I will try and dig it
out and attach it.

Found it, I think. It is a 100k .tar.gz, I do not want to mess with the
mailing lists, you can have it in a separate private mail. 

-- 
Don't worry  --  shop.

Re: Diff to show my work

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

> > Its a diff against the current ruby tree. If it was against linus tree it
> > would have been twice as big. 
> > 
> OK. Let's get it setup.

Once the code I have works somewhat I will create a big patch against
linus tree with the ruby tree.

> > The problem is telling the blanking routines which head is the one to
> > unblank. Right now I haven't seen away to do this. 
> > 
> If _visible_ VT blanks/unblanks, blank/unblank that FB. As one VT cannot
> be on two FBs, there is trivial relation...

The problem is more than VT is visible in a multiheaded setup. More than
one VT can be blanked and more than one VT can be unblanked. The blanking
timer function, static void vesa_powerdown_screen(void), doesn't pass info
in when the unblank function is called. Some how I need to pass this info
in. It is possible that 2 VTs will be blanked. Which one do I pick then. 
The good news is someone has a patch for this. So I will post this patch
and then combine it in with my work. 

Re: Diff to show my work

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

On 14 Jun 00 at 9:47, James Simmons wrote:
> > Hi,
> >   is it complete diff between Linus/Alan tree and current linuxconsole
> > CVS or is it an addition to linuxconsole CVS (I did not look at patch
> > yet and because of I have no linuxconsole CVS copy here yet, I'm asking...) 
> 
> Its a diff against the current ruby tree. If it was against linus tree it
> would have been twice as big. 
> 
OK. Let's get it setup.

> > I think that for backward compatibility you should add new ioctl
> > OPENVT2, which opens VT on specific output device. Old code (simple
> > open /dev/tty* and OPENVT ioctl) should use same lowlevel device as
> > current->tty uses... I think... Probably with exception that if
> > current->tty is not VT, you should use first head (for use by init, for
> > example, which is connected to /dev/console).
> 
> I was thinking about that as well. I know we need a way to allocate more
> VCs for a head. Once we remove the 64 limit and we can use devfs to create
> VCs on the fly :) As for allocating VCs for a different head then we are
> on. Do we really need this? 

I think that doing open & con2fb is a bit inconvient. Also for some time
VT will exist on fb where you do not want it. But you are probably right -
- any user can open VT on own head, but only priviledged can do con2fb...

> > Create per-VT blanking timers which will expire individually and which
> > are restarted on keypress (on that VT) and console switch... Looks like
> > easiest solution to me. 
> 
> The problem is telling the blanking routines which head is the one to
> unblank. Right now I haven't seen away to do this. 
> 
If _visible_ VT blanks/unblanks, blank/unblank that FB. As one VT cannot
be on two FBs, there is trivial relation...

                                            Petr
                                            

Re: (Multihead) Console Blanking

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

> James Simmons <jsi...@ac...> wrote:
> > I'm one of the ones working on the new console system. Real multihead, meaning
> > the console system supports mulitple displays and multiple keyboards, needed a
> > big code rewrite of the console system so it should hold off to 2.5.X. Have 
> > you come up with a solution by the way for multihead blanking. I haven't :(
> > Ideas anyone? 
> 
> I played with a patch to support the MDA as a second monitor when I was using
> 2.0.x, that supported screen blanking on both monitors. I will dig the patch
> out and have a read. How are you going to do multiple keyboards? USB? Or is
> all of that kind of stuff in an FAQ I have not spotted?

    You have a patch. Great :) Could you reply with the patch. Thank you
very much. 
    As for keyboards using Vojtech's input devices we support multiple
keyboards via USB. Also you can do what I have. Plug one ps/2 into the
ps/2 keyboard port and another one into the ps/2 mouse port. Then you can 
attached a sun keyboard via the parrallel port. I have the sun keyboard
but you need to build the adapter yourself which I haven't done yet. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Diff to show my work

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

> Hi,
>   is it complete diff between Linus/Alan tree and current linuxconsole
> CVS or is it an addition to linuxconsole CVS (I did not look at patch
> yet and because of I have no linuxconsole CVS copy here yet, I'm asking...) 

Its a diff against the current ruby tree. If it was against linus tree it
would have been twice as big. 

> I think that for backward compatibility you should add new ioctl
> OPENVT2, which opens VT on specific output device. Old code (simple
> open /dev/tty* and OPENVT ioctl) should use same lowlevel device as
> current->tty uses... I think... Probably with exception that if
> current->tty is not VT, you should use first head (for use by init, for
> example, which is connected to /dev/console).

I was thinking about that as well. I know we need a way to allocate more
VCs for a head. Once we remove the 64 limit and we can use devfs to create
VCs on the fly :) As for allocating VCs for a different head then we are
on. Do we really need this? 

> Create per-VT blanking timers which will expire individually and which
> are restarted on keypress (on that VT) and console switch... Looks like
> easiest solution to me. 

The problem is telling the blanking routines which head is the one to
unblank. Right now I haven't seen away to do this. 

> Another solution is glue it together as 'seat'
> (all kbds, mouses and monitors at one place), but this does not
> work correctly if you take into account that app can disable blanking
> for such VT (XFree and fbtv does it, for example). 

I noticed that as well :(

> Only unfortunate thing 
> is that currently setting VT blanking period is per-system and not per-VT. 

Right. I want to see it per VT as well. If we have several people at different
VTs attached to one workstation we don't want all the heads to blank out 
when one person walks away for awhile from his desk. That would be annoying. 

Re: Diff to show my work

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

On 13 Jun 00 at 20:30, James Simmons wrote:
>   Well I have the patch attached what I have done. It bzip2ed and its 76K.
> Unzipped it 536K so you can see it is a massive rewrite. I still have some
> cleanup to do yet and some early testing.
Hi,
  is it complete diff between Linus/Alan tree and current linuxconsole
CVS or is it an addition to linuxconsole CVS (I did not look at patch
yet and because of I have no linuxconsole CVS copy here yet, I'm asking...) 

> TODO:
> 
>  Fix con_open. Right now the console system dynamically allocates each VC.
>  I have to figure away to find which VT each tty belongs to when con_open
>  is called.

I think that for backward compatibility you should add new ioctl
OPENVT2, which opens VT on specific output device. Old code (simple
open /dev/tty* and OPENVT ioctl) should use same lowlevel device as
current->tty uses... I think... Probably with exception that if
current->tty is not VT, you should use first head (for use by init, for
example, which is connected to /dev/console).
 
>  Figure out how to have each head be able to be blanked indepedently of
>  each other.
Create per-VT blanking timers which will expire individually and which
are restarted on keypress (on that VT) and console switch... Looks like
easiest solution to me. Another solution is glue it together as 'seat'
(all kbds, mouses and monitors at one place), but this does not
work correctly if you take into account that app can disable blanking
for such VT (XFree and fbtv does it, for example). Only unfortunate thing 
is that currently setting VT blanking period is per-system and not per-VT. 
But we can emulate it...
                                            
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...