linuxconsole-dev

Re: Supporting multiple keyboard

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

> 3) Ruby way for AT keyboards:
> 
> i8042.c -(raw)-> atkbd.c -(events)-> input.c -->
> >--(events)-> keyboard.c -(chars)-> tty
> 
> 4) Ruby way for USB keyboards:
> 
> usb.c -(usb)-> hid.c -(events)-> input.c -->
> >--(events)-> keyboard.c -(chars)-> tty

> keyboard.c, now, is a translator from events (which are compatible across
> all architectures and all input device types) to characters for the TTY.

Much cleaner :) So keybdev.c is basically outdated now. I was
confussed in its purpose. Actually I though you where using it to create a
future /dev/kbd like you have a /dv/mouse now. 

> keyboard.c doesn't receive any raw scancodes, however, unfortunately, the
> tty layer has three modes - Cooked, MediumRaw, and Raw. 

   I have noticed those modes :( Hacks for "graphics" programs. These apps
don't want a text console so they first set the console to KD_GRAPHICS to
disable most of the console system. Then they set the keyboard to raw mode
to stop the keyboard data from being cooked by the console layer. Since
the keyboard data is cooked the console doesn't know how to VT switch.
Then the app has to use a userland api to VT switch.  
   What should be done? Have the system go from console to graphics mode.
In graphics mode the application access the raw hardware devices via
/dev/fb and /dev/input or /dev/event. This disables the console system.
Once the devices are done and they close the console system is restored. 

   I have talked to Geert about changing the behavior of VT switching
anyways. Having the kernel totally manage the VT switch instead of having
userland using some ioctl api to handle it. A big reason is when a
userland app can access these raw devices and they ignore the VT switching
api then can see the hardware's data. So if you open /dev/fb and mmap the
vidoe memory then VT switch. What you type on that text console will be
present in the framebuffers memory that another process can see. Big
security hole.

> Cooked mode is OK, it goes through a keymap. Event numbers can be used
> in the keymap. This has a nice effect that keymaps will be architecture
> independent, too. 

This is really nice :) This makes support for different emulations much
easier. Will loadkeys have to be updated? 

> MediumRaw is seldomly used - and is event numbers again. 

Do you think we can get ride of it? I vote to get ride of it.

> Raw is used namely by XFree and SVGAlib - and because keyboard.c doesn't
> get rawmode data, it has to emulate it. The emulation has to be done
> somewhere, and best done closest to the app.

See above. This means patches will have to be made for XFree86. 

Thank you for the clarification. Actually I have anothe question for
you but this email has become to long so I will post another message. The
next question is what is difference between /dev/input and /dev/event?

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: Supporting multiple keyboard

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

On Wed, Jun 07, 2000 at 10:46:33AM -0400, James Simmons wrote:

> Vojtech while looking threw your code I noticed you have a
> keybdev.c in the input directory which has code that is in keyboard.c.
> Also you don't have it enabled. What I was thinking is have keybdev.c as
> the raw keyboard driver. This way when a user uses /dev/input we can send
> raw packets their. Otherwise it send the packets to the console system.
> This way keyboard.c becomes more of a translator from raw keyboard mode to 
> a tty keyboard. A first move might be to move the keybaord tasklet into  
> keybdev.c. What do you think Vojtech? 

No. It works a little differently:

1) Current 2.4 way for AT keyboards:

pc_keyb.c -(raw)-> keyboard.c -(raw)-> pc_keyb.c -->
>--(cooked)-> keyboard.c -(chars)-> tty

2) Current 2.4 way for USB keyboards (uses keybdev):

usb.c -(usb)-> hid.c -(events)-> input.c -(events)-> keybdev.c -->
>--(raw)-> keyboard.c -(raw)-> pc_keyb.c -(cooked)-> keyboard.c -->
>--(chars)-> tty

3) Ruby way for AT keyboards:

i8042.c -(raw)-> atkbd.c -(events)-> input.c -->
>--(events)-> keyboard.c -(chars)-> tty

4) Ruby way for USB keyboards:

usb.c -(usb)-> hid.c -(events)-> input.c -->
>--(events)-> keyboard.c -(chars)-> tty

Basically keybdev.c is a module that takes input events, and emulates an AT
keyboard, passing appropriate raw mode bytes to the original AT keyboard
driver. This was the easiest way how to connect USB keyboards. But it's far
from clean. There is no reason to converts the AT scancodes from, to and
from raw again.

keyboard.c, now, is a translator from events (which are compatible across
all architectures and all input device types) to characters for the TTY.

keyboard.c doesn't receive any raw scancodes, however, unfortunately, the
tty layer has three modes - Cooked, MediumRaw, and Raw. Cooked mode is OK,
it goes through a keymap. Event numbers can be used in the keymap. This has
a nice effect that keymaps will be architecture independent, too. MediumRaw
is seldomly used - and is event numbers again. Raw is used namely by XFree
and SVGAlib - and because keyboard.c doesn't get rawmode data, it has to
emulate it. The emulation has to be done somewhere, and best done closest to
the app.

So, what I see keyboard.c should be doing:
	* receiving events
	* generating a tty keyboard using keymaps
	* generating medraw/raw mode for apps that use that

Perhaps I mean the same as you originally did - it's just that the rawmode
driver is atkbd.c and not keybdev.c.

-- 
Vojtech Pavlik
SuSE Labs

Supporting multiple keyboard

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

y
   I have completed most of the changes needed to make the console system
not depend on currcon. I also seperated the VT emulation code from vt.c.
Also console_macro is almost gone :) Now for some problem I came across.
  
   First and less important problem is blanking the screen. How do tell
which screen is the one we want blank? Any ideas anyone? I had a chessy
hack right now but when true multihead comes into play we need to find a
right solution. 
  
   To get multihead working I need support for multiple keyboards to the
console system. I need to be able to tell which keyboard is doing the VT
switching. Vojtech while looking threw your code I noticed you have a
keybdev.c in the input directory which has code that is in keyboard.c.
Also you don't have it enabled. What I was thinking is have keybdev.c as
the raw keyboard driver. This way when a user uses /dev/input we can send
raw packets their. Otherwise it send the packets to the console system.
This way keyboard.c becomes more of a translator from raw keyboard mode to 
a tty keyboard. A first move might be to move the keybaord tasklet into  
keybdev.c. What do you think Vojtech? 

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: Serial Console & Sysrq (fwd)

[Dominik K. <dom...@un...>]

> If you know that Sysrq over serial console is not working for nobody
> or you can give me any suggestion, they are welcome.

Does not work. Somebody has to implement it. But be careful some
archs (notably sparc) already uses BREAK to drop into the firmware
monitor.

Dominik Kubla
-- 
  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                           

Serial Console & Sysrq (fwd)

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

---------- Forwarded message ----------
Date: 06 Jun 2000 03:40:28 +0200
From: Quintela Carreira Juan J. <qui...@fi...>
To: lkml <lin...@vg...>
Subject: Serial Console & Sysrq


Hi
        I am having the following problem:  I am not able to configure
the sysrq key for the serial console.  I have configured the serial
console correctly, as stated in the Documentation/serial-console.txt.
I have a serial console working OK.  I can indeed use it in lilo to
change kernels using break.  I have also configured the Sysrq key and
it works great while I am using a normal keyboard.  The problem is
that I am not able to use the serial console BREAK key to get a Sysrq.
I am using the minicom program.  I am running a getty in the serial 
terminal.  It makes no difference if I am logged or not.

lines in lilo.conf:
serial=0,9600n8
append="console=ttyS0,9600"

I have followed all the steps in Documentation/serial-console.txt and
Documentation/sysrq.txt.

If you know that Sysrq over serial console is not working for nobody
or you can give me any suggestion, they are welcome.

TIA, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

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

Re: Latest analog joystick code

[Steffen S. <s.s...@ph...>]

James Simmons wrote:
 
> On Fri, 2 Jun 2000, Vojtech Pavlik wrote:
> 
> > On Thu, Jun 01, 2000 at 09:32:26PM -0400, James Simmons wrote:
> >
> > > vc_data we can have. With the present console system we have 64 allocated
> > > vc_data structs for one head. With fbdev you can have up to 256 heads and
> > > USB up to 127 keyboards.
> >
> > Well, no. 127 keyboards on one USB bus. And you can have multiple USB
> > busses - current VIA chipsets implement two, and there are Opti chips
> > that implement four USB busses on one chip.
> 
> Ah :) How do you plan to get around the 256 device limit or does devfs fix
> that ? I know right now the limit for fbdev is set at 32 but can be easily
> changed to 256. Just change FB_MAX to 256. So we can have at least 256
> complete VTs. Maybe more :) Only if motherboards had enough slots!

As if that would be a serious limitation... From my KGI coding, I can only
recommend you to impose no limits by the code you write but live with
the limitations of the environment.

>   As for multihead. Well I attempted booting today with a Voodoo 3 card
> and a Matrox Millenium card. The matrox card came up and then it tried to
> initialize my voodoo card but my system freaked out. It hung and made a
> loud noise.

Welcome to the wonderful world of multihead video hardware programming.
It's just nice to see the problems I have gone through seem to be
inherent to the subject, not my fault :-)).

> Has anyone here has made two PCI video cards work at the same
> time in their system with no problems?


Yes. S3 968 with S3 Trio, S3 968 with PermediaNT, PermediaNT with Permedia2,
Permedia2 with Permedia2 (different vendors).
As long as your drivers are capable of cold-booting the card...

> Also I had this problem with BIOS
> with 2 keyboards. I used your trick to make the computer use the PS/2
> mouse port for another PS/2 keyboard. It works after boot time. If I plug
> both in and turn my computer on it confuses my BIOS and just hanges there.

On my BIOSes this happens only the first time.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...

progress

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

Hi!

  Well I have completed about half of the conversion of the console code.
I'm almost finished with vt.c but have a few more files to go. I see
keyboard.c was updated. That will be the last file I change. It will be a
little while before I have the code ready. I don;t want to enter code that
doesn't at least compile in CVS. 

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: Latest analog joystick code

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

> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/multihead.gz. 

Just wanted people to taek alook at them on the list. 

> If it has CH8398, then I had patches for it... Unfortunately, I stopped
> maintaining them sometime during last year. Maybe Geert or someone still
> has them...

Nope. It's a ATI 68860. I have a patch from harris but it is old and
didn't compile. I didn't bother to intergrate it with the current atyfb
driver. I plan to intergrate it. 

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: vfb.c (ruby)

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

> Okay ... has anybody tested vfb.c? I didn't. If it works, I don't know how,
> because it computes the memory size with get_line_length() to test:

Okay I found out what this code does. I have placed the code with comments
in CVS. Here is the explanation:

static u_long get_line_length(int xres_virtual, int bpp)
{
    u_long length;

    /* Calculate number of bits per display line */
    length = xres_virtual * bpp;
    /* Round up to a multiple of 32 */
    length = (length+31)&~31;
    /* Convert number of bits to number of bytes */
    length >>= 3;
    return(length);
}

Re: Latest analog joystick code

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

On Fri, Jun 02, 2000 at 11:11:00PM -0400, James Simmons wrote:
> 
> > Yes. I had 4 Matroxes (Millennium I, Millennium II, Mystique and
> > G200-AGP) in box for some time... It worked fine (with some fbmem
> > patches which prevented me from doing stupid things). It was 4x matroxfb.
> 
> Patches :) Post them for us to look at. 

You know them... they add FBIOPUT_VT_... and, as side effect,
returns -EXDEV when doing FBIOPUT_VSCREENINFO when you should not...
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/multihead.gz. This
patch was generated for something like 2.3.49...

> > I had also running matrox (G200) with ATI-GX (atyfb, vga16fb)...
> 
> I have a ATI GX but with a strange RAMDAC that's not supported yet.
> That's later on the list.

If it has CH8398, then I had patches for it... Unfortunately, I stopped
maintaining them sometime during last year. Maybe Geert or someone still
has them...

> > You should also add 'video=matrox:novga,nobios' to your command line,
> 
> By default matrox uses the BIOS? 

No, but Voodoo may need videobios range for its own BIOS... If system
BIOS or pci_enable_device() did not enable I/O or BIOS, then matroxfb
will not enable it. But if it is enabled when matroxfb loads, it can
disable them... I needed it for running matroxfb in PowerStack PPC,
otherwise it crashed with sigbus.

> > but you should know that if you do it, it is possible that after
> > reboot Voodo becomes your primary display or machine will not reboot
> > without poweroff at all...
> 
> A cool poweroff should fix this right? 

It depends on BIOS and computer hardware. I have one ATX which I have to
unplug from power if I boot with nobios...
					Petr Vandrovec
					van...@vc...

RE: Latest analog joystick code

[Brad D. <Br...@NE...>]

> -----Original Message-----
> From: James Simmons [mailto:jsi...@ac...]
> 
>   As for multihead. Well I attempted booting today with a Voodoo 3 card
> and a Matrox Millenium card. The matrox card came up and then it tried to
> initialize my voodoo card but my system freaked out. It hung and made a
> loud noise. Has anyone here has made two PCI video cards work at the same
> time in their system with no problems? Also I had this  problem with BIOS

I'm using atyfb (Mach64 GT) and aty128fb (Rage128 Pro).

Both drivers compiled in:
My bios allows me to choose which card gets booted:

Boot atyfb:
The Mach64 comes up fine and when the Rage128 tries to initialize, it says
freeing nonexistent IO 0x9000 or something similar (0x9000 is the IO port
address of the Rage128).  The Rage128 never makes it through init, but the
system works fine as would expect with 1 video card.

Wasn't there some discussion about pci_enable_device() and multihead?  I'll
check the archives.

Boot aty128fb:
The Rage128 comes up fine.  When the Mach64 starts detection all hell breaks
loose.  I get alternating green and black horizontal bars on the Mach64 and
the system hardlocks.

Modular:
Boot atyfb and modular aty128fb:
Mach64 comes up normal.  insmod aty128fb yields nothing.  lsmod simply says
unused.  I've probably overlooked something in the code -- I rarely try
module.

Boot aty128fb and modular atyfb:
Rage128 comes up normal.  insmod atyfb is very bad. system hardlocks.
If I first softboot the Mach64 before insmoding it, I have some success.
The system is a bit touchy and will eventually hardlock (races?).

That's my $.02.

PS -
Keep a camera handy in case things start smoking...  I want pictures for the
web site ;). "When video cards attack".

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

One more thing

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

Oh I will fix the compile fail for the VT emulation stuff.

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

vt.c rewrite

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

Hi!
   I started the cleanup of vt.c (former console.c). I have implemented
the idea of struct vt_struct to represent a physical virtual terminal and 
vc_data for VCs. This will remove the need for fg_console and currcon in 
the console code. This will take a few days to do. The big obstacle to
overcome is the 64 VC limit. This also affects the serial tty drivers. The
best way to handle this is have tty support hot swappable devices. As you
seen from the earlier posting by me and Vojtech the potential to have at
least 128 and even many more is very possible. 

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: Latest analog joystick code

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

> Yes. I had 4 Matroxes (Millennium I, Millennium II, Mystique and
> G200-AGP) in box for some time... It worked fine (with some fbmem
> patches which prevented me from doing stupid things). It was 4x matroxfb.

Patches :) Post them for us to look at. 

> I had also running matrox (G200) with ATI-GX (atyfb, vga16fb)...

I have a ATI GX but with a strange RAMDAC that's not supported yet.
That's later on the list.

> You should try swap your two videocards, making Matrox second head.

Voodoo is AGP and Matrox is PCI. My BIOS doesn't have any functions to
switch the detection. I changed the order in fbmem to get matrox going
first.

> You should also add 'video=matrox:novga,nobios' to your command line,

By default matrox uses the BIOS? 

> but you should know that if you do it, it is possible that after
> reboot Voodo becomes your primary display or machine will not reboot
> without poweroff at all...

A cool poweroff should fix this right? 

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: Latest analog joystick code

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

> I have two nVidia cards. XFree86 4.0 does not work at all (just disables
> both upon starting), but I have no problem running vgacon on the primary
> display and nvvgacon on the secondary (as well as mdacon on a third
> video card). XFree86 3.3.6 runs only on the primary, and svgalib
> (1.9.*) runs on both PCI cards. I did not try fbdev in a long time, but
> looking at the code it seems to me that it does not support a non
> primary card.

XFree86 4.0 isn't really designed for multihead. You can with fbdev support 
more than one display if the fbdev drivers are BIOS/OpenFirmware independent. 
Some like the matrox, aty and soon aty128 driver are. The program you need
to do this is con2fb. It maps a VC range to a specific framebuffer device.
Also their are boot commands to map vc to fb devices. Warning!!! If you
don't map it right you can cause a oops. I plan it fix this. To do this I
really have to do alot of code cleanup.

> I use the second keyboard (on the ps/2 mouse port) with a user mode
> program I wrote, similar to joy2key. So as far as the kernel is
> concerned I have one console, but I actually have two.
> You can see it at http://www.arava.co.il/matan/misc/ps2key-0.1.tar.gz.

I believe the input layer can do this as well. What other goods do you
have? 

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: Latest analog joystick code

[Matan Ziv-Av <ma...@sv...>]

On Fri, 2 Jun 2000, James Simmons wrote:

> As for multihead. Well I attempted booting today with a Voodoo 3 card
> and a Matrox Millenium card. The matrox card came up and then it tried to
> initialize my voodoo card but my system freaked out. It hung and made a
> loud noise. Has anyone here has made two PCI video cardswork at the same
> time in their system with no problems? Also I had this problem with BIOS

I have two nVidia cards. XFree86 4.0 does not work at all (just disables
both upon starting), but I have no problem running vgacon on the primary
display and nvvgacon on the secondary (as well as mdacon on a third
video card). XFree86 3.3.6 runs only on the primary, and svgalib
(1.9.*) runs on both PCI cards. I did not try fbdev in a long time, but
looking at the code it seems to me that it does not support a non
primary card.

> with 2 keyboards. I used your trick to make the computer use the PS/2
> mouse port for another PS/2 keyboard. It works after boot time. If I plug
> both in and turnmy computer on it confuses my BIOS and just hanges there.
> Very annoying. After boot time I can insmod a module to see my second
> keyboard.

I use the second keyboard (on the ps/2 mouse port) with a user mode
program I wrote, similar to joy2key. So as far as the kernel is
concerned I have one console, but I actually have two.
You can see it at http://www.arava.co.il/matan/misc/ps2key-0.1.tar.gz.


-- 
Matan Ziv-Av.                         ma...@sv...

Re: Latest analog joystick code

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

On  2 Jun 00 at 10:42, James Simmons wrote:
>   As for multihead. Well I attempted booting today with a Voodoo 3 card
> and a Matrox Millenium card. The matrox card came up and then it tried to
> initialize my voodoo card but my system freaked out. It hung and made a
> loud noise. Has anyone here has made two PCI video cards work at the same

Yes. I had 4 Matroxes (Millennium I, Millennium II, Mystique and
G200-AGP) in box for some time... It worked fine (with some fbmem
patches which prevented me from doing stupid things). It was 4x matroxfb.

I had also running matrox (G200) with ATI-GX (atyfb, vga16fb)...

You should try swap your two videocards, making Matrox second head.
You should also add 'video=matrox:novga,nobios' to your command line,
but you should know that if you do it, it is possible that after
reboot Voodo becomes your primary display or machine will not reboot
without poweroff at all...

                                            Petr Vandrovec
                                            van...@vc...
                                            

Re: Latest analog joystick code

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

On Fri, 2 Jun 2000, Vojtech Pavlik wrote:

> On Thu, Jun 01, 2000 at 09:32:26PM -0400, James Simmons wrote:
> 
> > vc_data we can have. With the present console system we have 64 allocated
> > vc_data structs for one head. With fbdev you can have up to 256 heads and
> > USB up to 127 keyboards.
> 
> Well, no. 127 keyboards on one USB bus. And you can have multiple USB
> busses - current VIA chipsets implement two, and there are Opti chips
> that implement four USB busses on one chip.

Ah :) How do you plan to get around the 256 device limit or does devfs fix
that ? I know right now the limit for fbdev is set at 32 but can be easily
changed to 256. Just change FB_MAX to 256. So we can have at least 256
complete VTs. Maybe more :) Only if motherboards had enough slots!
 
> If possible, I would prefer not to have any static memory structures for
> this. We'll run out of space sooner or later.
> 
> > With a AT or PS/2 keyboard we can a total of 128
> > complete VTs. This means 128 * 64 = 8,192 vc_data structs. This means we
> > have to adopt a dynamic approach to allocating VCs.
> 
> Yes. Which in turn means a lot of problems with VT numbering and such.
> But these need to be solved nevertheless.

  The best way to approach this is using alot of COW techniques. Allocate
one struct for everything then when one changes its state we allocate a
new struct and change the pointer to it. The text buffer will be tricky to
handle since they vary from VC to VC.

  As for multihead. Well I attempted booting today with a Voodoo 3 card
and a Matrox Millenium card. The matrox card came up and then it tried to
initialize my voodoo card but my system freaked out. It hung and made a
loud noise. Has anyone here has made two PCI video cards work at the same
time in their system with no problems? Also I had this problem with BIOS
with 2 keyboards. I used your trick to make the computer use the PS/2
mouse port for another PS/2 keyboard. It works after boot time. If I plug
both in and turn my computer on it confuses my BIOS and just hanges there.
Very annoying. After boot time I can insmod a module to see my second
keyboard. 

  Some ideas I have been thinking about. Right now the data structs for
the console system are a mess. We have both vt_struct and vc_data struct.
What I was thinking was to make vt_struct represent the real VT and
vc_data represent the virtual consoles. Thus each vc_struct would have a
pointer to a vt_struct which would represent the physical virtual
terminal. Each vt_struct could hold what is per virtual terminal like
consw. Each head would have its own driver. Thus the begining of VC pools.
I might as well start working on this now. I will start will a single head
system and lay the data structures out and then migrate to a multihead
setup.

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: vfb.c (ruby)

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

On Wed, 31 May 2000, James Simmons wrote:

> 
> > > >     length = (xres_virtual+bpp-1)/bpp;
> > It is obviously wrong... For xres = 640 at 16bpp you should get
> > 1280 bytes and for 8bpp 640 bytes...
> 
> Dah!! I don't know what I was thinking. I was just trying to figure what
> the orginal code was doing. Which I stil can't figure it out yet. Petr do
> you have a idea what Geert was thinking when he wrote that routine? 
> 

Okay ... has anybody tested vfb.c? I didn't. If it works, I don't know how,
because it computes the memory size with get_line_length() to test:

------ vfb.c ------ L245 ------

    line_length = get_line_length(var->xres_virtual, var->bits_per_pixel);
    if (line_length*var->yres_virtual > videomemorysize)
	return -ENOMEM;

Any idea? Maybe nobody got a problem because the get_line_length()-function
always produces to small values to return ENOMEM - and the
default/module_param videomemorysize fitted. 

But:
------ vfb.c ------ L506 ------

    fix->line_length = get_line_length(var->xres_virtual,
					var->bits_per_pixel);

would also 'encode' wrong values.

Christian.

Re: Latest analog joystick code

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

> > It's not only when I VT switch away. If I'm on VT 1 and keep pressing 
> > Alt-F1 it also prints out a A. 
> 
> Thanks for the info. But it's even weirder than just that. Try running
> a 'cat' on the VT - the problem disappears. I'll try to look into it.

That is strange. I haven't been able to see anything. The 3Dfx driver with
the new API is giving me the infamous blank screen. So I will be looking
threw that code tomorrow. Video drivers are the worst to debug. The vgacon
driver works like a charm. Once I get the first driver working like a
charm the rest should be easy. The matrox works great. OF course I haven't
touched it.

> Oh, yes. Per-VT keymaps will consume quite a lot of memory, btw ...

Not if you take the write on copy approach. All VC keymap point to same
keymap. If userland wants a different keymap it changes the pointer of the
the VC keymap to the new keymap. The bigger problem is the number of
vc_data we can have. With the present console system we have 64 allocated
vc_data structs for one head. With fbdev you can have up to 256 heads and
USB up to 127 keyboards. With a AT or PS/2 keyboard we can a total of 128
complete VTs. This means 128 * 64 = 8,192 vc_data structs. This means we
have to adopt a dynamic approach to allocating VCs.

Re: Latest analog joystick code

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

On Thu, Jun 01, 2000 at 02:16:47PM -0400, James Simmons wrote:

> > Yes, I know about this and will be looking for the cause. Somehow the
> > shift state isn't carried across different VT's. It might be a bug in my
> > changes to char/keyboard.c, but I doubt that - I kept them minimal.
> 
> It's not only when I VT switch away. If I'm on VT 1 and keep pressing 
> Alt-F1 it also prints out a A. 

Thanks for the info. But it's even weirder than just that. Try running
a 'cat' on the VT - the problem disappears. I'll try to look into it.

> > Anyway, I'd like to rewrite (or better someone else to rewrite :)
> > keyboard.c - it's big, and complex, and doesn't have very clean
> > interface to the rest of the system.
> 
> Better than what was before. Its a matter of creating a better raw
> keyboard to console handling. Especially if we are going to support per VT 
> keymaps. 

Oh, yes. Per-VT keymaps will consume quite a lot of memory, btw ...

-- 
Vojtech Pavlik
SuSE Labs

Re: Latest analog joystick code

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

> linux/Documentation/joystick-parport.txt

Good stuff. I'm going to pass it off to our local LUG. We have a few
electronics buffs in the group.

> > By the way your stuff works great. The only difference I have noticed is
> > if I press ALT-F# more than once it will VT switch then print a capital
> > letter where its position in the alphabet is #. At a login in prompt I get
> > a ^[[A or ^[[B etc depending on which # VT we are one. I wonder if this is
> > from the console code with the new emulation or from the keyboard driver. 
> > Does this happen for a USB keyboard thats attached to a VT ? 
> 
> Yes, I know about this and will be looking for the cause. Somehow the
> shift state isn't carried across different VT's. It might be a bug in my
> changes to char/keyboard.c, but I doubt that - I kept them minimal.

It's not only when I VT switch away. If I'm on VT 1 and keep pressing 
Alt-F1 it also prints out a A. 

> Anyway, I'd like to rewrite (or better someone else to rewrite :)
> keyboard.c - it's big, and complex, and doesn't have very clean
> interface to the rest of the system.

Better than what was before. Its a matter of creating a better raw
keyboard to console handling. Especially if we are going to support per VT 
keymaps. 

> Also, escape sequences are stored right in the keymaps, with I doubt
> does come well with selectable VT emulations.
>
> Oh, and last comment: The input subsystem supports more than 3 LEDs.
> I've seen places in the VT code that limits this to 3 - this should be
> eliminated.

Noted. Some things to cleanup. Is Dominik still will us? Dominik?

Re: Latest analog joystick code

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

> If you are talking about set_cursor() one, I believe that you can trigger
> it on up too, as scrollback code is handled from irq/bh context - so
> irqsave in spin_lock_irqsave() takes effect on UP too... But as I do not
> have UP, I cannot verify my suspect (boot with init=/bin/bash, at prompt
> type echo > /dev/tty2, switch to tty2 and back (to hide logo) and then
> do ls -lR / and hold down shift-pgup... if you have non-reentrant accelerated
> driver, it will die in 10 seconds ...).

I tried it with your matroxfb on a 2.2.14 kernel but that is accelerated.
I had no problems. I haven't tried it yet with no acceleration yet. Has
anyone else tried this. 

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: [PATCH] drivers/char/console.c and reentering

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

> But there are some callers (set_selection, complete_change_console) for
> which I was not able to verify whether they are called with lock held or
> not.

complete_change_console is called with the console_lock. The function
called when a VT switch happens is console_softint which takes the lock
and in turn calls change_console which then calls complete_change_console.
As for set_selection I don't see a lock taken. Here this function is
called by a ioctl via the tty layer.

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: Latest analog joystick code

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

On Wed, May 31, 2000 at 08:59:40PM -0400, James Simmons wrote:
> 
> > > Can I use my commodore joystick with linux? Only kidding.
> > 
> > Well, the QS-201 is a PC joystick, but *YES* you can use your commodore
> > joystick with Linux. :) Actually it's supported by the gamecon.c, db9.c and
> > turbografx.c. And the commodore-to-parallel adapters are easy to build.
> 
> Really :) Can you post where this info is to build this adapter. I have a
> few commodore joysticks. I also have a few atari 2600 paddles and
> joysticks too. He he. This is really cool.

linux/Documentation/joystick-parport.txt

> By the way your stuff works great. The only difference I have noticed is
> if I press ALT-F# more than once it will VT switch then print a capital
> letter where its position in the alphabet is #. At a login in prompt I get
> a ^[[A or ^[[B etc depending on which # VT we are one. I wonder if this is
> from the console code with the new emulation or from the keyboard driver. 
> Does this happen for a USB keyboard thats attached to a VT ? 

Yes, I know about this and will be looking for the cause. Somehow the
shift state isn't carried across different VT's. It might be a bug in my
changes to char/keyboard.c, but I doubt that - I kept them minimal.

Anyway, I'd like to rewrite (or better someone else to rewrite :)
keyboard.c - it's big, and complex, and doesn't have very clean
interface to the rest of the system.

Also, escape sequences are stored right in the keymaps, with I doubt
does come well with selectable VT emulations.

Oh, and last comment: The input subsystem supports more than 3 LEDs.
I've seen places in the VT code that limits this to 3 - this should be
eliminated.

-- 
Vojtech Pavlik
SuSE Labs