linuxconsole-dev

Re: Latest analog joystick code

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

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

> > On the serious
> > side are converters from SUN keyboards to parallel port avaliable or do I
> > have to build one myself? I obtained a keyboard from a old IPX workstation
> > that went into the trash. 
> 
> You'll have to build it yourself. I know of no manufacturers that would
> be producing them.

You have it on your web page so I will build one when I get the time. 
http://www.suse.cz/development/input/

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 ? 

> Btw, there is one little, but annoying bug that disabling 'Extended
> terminal emulation' makes the kernel uncompilable ...

Yeah. I have left it alone waiting for Dominik to work on that. Dominik?

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 02:56:36PM -0400, James Simmons wrote:
> 
> > First, I digged out a very old original IBM design NS558 based gameport,
> > and my 5 years old QuickShot QS-201 analog joystick, cleaned the
> > joystick thoroughly, applied some special contact cleaning and contact
> > care sprays to all the pots in the joystick, and silicone grease to all
> > bearings.
> 
> 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.

> On the serious
> side are converters from SUN keyboards to parallel port avaliable or do I
> have to build one myself? I obtained a keyboard from a old IPX workstation
> that went into the trash. 

You'll have to build it yourself. I know of no manufacturers that would
be producing them.

> As for CVS. I refined the fbdev API a little more after much talk about
> ideas on how to handle it on the fbdev list. Pretty much everything should
> compile and work for you. Their might be some bugs here and their with all
> the drivers being cleaned up. I applied a nice patch Petr posted on the
> lkml mailing list. If you have SMP machines please test it. I don't have a
> SMP machine so I can't. 

Btw, there is one little, but annoying bug that disabling 'Extended
terminal emulation' makes the kernel uncompilable ...

-- 
Vojtech Pavlik
SuSE Labs

Re: Latest analog joystick code

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

On 31 May 00 at 14:56, James Simmons wrote:
> As for CVS. I refined the fbdev API a little more after much talk about
> ideas on how to handle it on the fbdev list. Pretty much everything should
> compile and work for you. Their might be some bugs here and their with all
> the drivers being cleaned up. I applied a nice patch Petr posted on the
> lkml mailing list. If you have SMP machines please test it. I don't have a
> SMP machine so I can't. 
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 ...).
                                            Petr
                                            

Re: Latest analog joystick code

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

> First, I digged out a very old original IBM design NS558 based gameport,
> and my 5 years old QuickShot QS-201 analog joystick, cleaned the
> joystick thoroughly, applied some special contact cleaning and contact
> care sprays to all the pots in the joystick, and silicone grease to all
> bearings.

Can I use my commodore joystick with linux? Only kidding. On the serious
side are converters from SUN keyboards to parallel port avaliable or do I
have to build one myself? I obtained a keyboard from a old IPX workstation
that went into the trash. 

As for CVS. I refined the fbdev API a little more after much talk about
ideas on how to handle it on the fbdev list. Pretty much everything should
compile and work for you. Their might be some bugs here and their with all
the drivers being cleaned up. I applied a nice patch Petr posted on the
lkml mailing list. If you have SMP machines please test it. I don't have a
SMP machine so I can't. 

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

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


> > Length is the value that placed in fb_fix-screeninfo line_length which is
> > the number of bytes wide the way th card sees a scanline. Take a voodoo
> > card for example. No matter what mode you set the card in line_length is
> > 1024. So take for example 800x600. We have video memory layed out like
> > this:
> Then easiest thing is that driver will always report xres_virtual = 1024.
> Or it can compute line_length as it wants, but for such hardware then 
> get_line_length() should not depend on xres_virtual.

Right, you wouldn't need a get_line_length routine. 


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

[PATCH] drivers/char/console.c and reentering

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

Hi Alan
  as nobody answered to my mail from Monday, please apply
this patch to 2.4.0-test1. It fixes one codepath which was 
proven that there is missing lock. Patch was generated 
against 2.4.0-test1-ac7.

  I tried to verify all other callers of set_cursor and
I believe that others are safe - or at least immediate callers
of set_cursor are at least sometime called with console_lock
held. 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.

  I'm using this change since monday on my SMP system and
I do not see any bad effect - only one good that fbdev is
no more reentered.
				Thanks,
					Petr Vandrovec
					van...@vc...




diff -urdN linux/drivers/char/console.c linux/drivers/char/console.c
--- linux/drivers/char/console.c	Sun Apr  2 22:20:27 2000
+++ linux/drivers/char/console.c	Wed May 31 15:52:52 2000
@@ -2290,10 +2290,13 @@
 
 static void con_flush_chars(struct tty_struct *tty)
 {
+	unsigned long flags;
 	struct vt_struct *vt = (struct vt_struct *)tty->driver_data;
 
 	pm_access(pm_con);
+	spin_lock_irqsave(&console_lock, flags);
 	set_cursor(vt->vc_num);
+	spin_unlock_irqrestore(&console_lock, flags);
 }
 
 /*

Re: vfb.c (ruby)

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

On 31 May 00 at 10:37, James Simmons wrote:
> > static u_long get_line_length(int xres_virtual, int bpp)
> > {
> >     u_long length;
> > 
> >     length = (xres_virtual+bpp-1)/bpp;
> 
> This returns the number of bytes wide the screen is. For 640 at 8 bpp that
> would be 640/8 = 80 bytes wide. If we where at 16 bpp we have 640/16 =
> 40 words wide. Why the above formula? It rounds up the number of we
It is obviously wrong... For xres = 640 at 16bpp you should get
1280 bytes and for 8bpp 640 bytes...

length = xres_virtual * bpp / 8;

works for cfb modes with xres_virtual * bpp is multiple of 8. As other
videomodes are impossible on majority of hardware... and generic procedure
cannot say what happens with `overflowed' pixels - maybe that line
length will be 'length = (xres_virtual * bpp + 7) / 8' or
'length = (xres_virtual * bpp + 63) / 64 * 8' or ... 
So let fbdev driver round xres_virtual up to match hardware...

> >     length = (length+31)&-32;
> 
> > What is/should be the return value? 32 bit aligned bytes?
> 
> Yes.

It is wrong... If I say that I want xres_virtual = 1235, then
(if hardware supports such vxres), length must be 1235 * 3 bytes
for 24bpp. No more, no less. Just exactly 3705 bytes... It is
driver responsibility to eventually round xres_virtual up if 
hardware cannot do xres_virtual = 1235... 
> > I thought:
> > 
> >     length = (xres + bpp-1) * bpp;
> > 
> > would be right. But, as I mentioned, I'm a bit confused ;-)
With xres_virtual it is right...

> Length is the value that placed in fb_fix-screeninfo line_length which is
> the number of bytes wide the way th card sees a scanline. Take a voodoo
> card for example. No matter what mode you set the card in line_length is
> 1024. So take for example 800x600. We have video memory layed out like
> this:
Then easiest thing is that driver will always report xres_virtual = 1024.
Or it can compute line_length as it wants, but for such hardware then 
get_line_length() should not depend on xres_virtual.
                                                Petr Vandrovec
                                                van...@vc...
                                                
                                                

Latest analog joystick code

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

Hi!

Just wanted to inform you that I ran an interesting test today:

First, I digged out a very old original IBM design NS558 based gameport,
and my 5 years old QuickShot QS-201 analog joystick, cleaned the
joystick thoroughly, applied some special contact cleaning and contact
care sprays to all the pots in the joystick, and silicone grease to all
bearings.

Then I used my latest analog code (with two stage noise filtration) to
read data from the joystick. And, I've got 10.5 bits of precision from
it. That's more than most digital joysticks can do ... Compared to BIOS
routine which does 5-6 bits, this is quite nice. I wonder how much
Windows drivers do get.

I was also surprised about how much difference proper care of the pots
made - before I applied the sprays and silicone, the resolution was
somewhere about 8.5 bits.

-- 
Vojtech Pavlik
SuSE Labs

Re: vfb.c (ruby)

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

Sorry for the late response. Been busy with the code. I had teh smae
question when I first looked at it.

> static u_long get_line_length(int xres_virtual, int bpp)
> {
>     u_long length;
> 
>     length = (xres_virtual+bpp-1)/bpp;

This returns the number of bytes wide the screen is. For 640 at 8 bpp that
would be 640/8 = 80 bytes wide. If we where at 16 bpp we have 640/16 =
40 words wide. Why the above formula? It rounds up the number of we
bytes/words/longs we have. It also handles things like 24 bpp very well.
Consider so results:

640x480@8

(640+7)/8 = 80   (Stuff after decimal goes away)
(640+15)/16 = 40 
(640+23)/24 = 27
(640+31)/32 = 20

Take for example if a user tried to set a mode with the x resolution of
643. We have:

(643+7)/8 = 81. See it rounded up the number of bytes fo those strange 3
		pixels
(643+31)/32 = 21 

>     length = (length+31)&-32;

This translates it into the number of 32 bit words. 

>     length >>= 3;

Then we translate into bytes. 

>     return(length);
> }
> --------------------------------
> 
> What is/should be the return value? 32 bit aligned bytes?

Yes.

> I thought:
> 
>     length = (xres + bpp-1) * bpp;
> 
> would be right. But, as I mentioned, I'm a bit confused ;-)

Length is the value that placed in fb_fix-screeninfo line_length which is
the number of bytes wide the way th card sees a scanline. Take a voodoo
card for example. No matter what mode you set the card in line_length is
1024. So take for example 800x600. We have video memory layed out like
this:

0                  800        1024
-------------------------------
|                   |          | 0
|                   |          |
|                   |          |
|                   |          |
....
|                   |          |
--------------------------------  600

So the area between 800 and 1024 you can't see. But if you want to draw 
a rectangle you you draw from say 300 to 500 on the first first line. You
of course trnaslate the postion to the byte position in video memory. When
you want to go to the next line you have to add the 1024 to 300 translated
to a byte position to get to the next line to draw on. You keep adding
this 1024 to get to the next line.  

P.S

  By the way the CVS is very active even if the mailing list is not. The
code is in flux so expect some breakage from time to time. In fact I have
to go fix something right now. I will post info later tonight on how to
use this kernel. This should go on our web page next.

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

vfb.c (ruby)

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

Hi,

maybe I'm a bit confused, but I don't understand this piece of code:

-------- vfb.c --- L469 --------

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

    length = (xres_virtual+bpp-1)/bpp;
    length = (length+31)&-32;
    length >>= 3;
    return(length);
}
--------------------------------

What is/should be the return value? 32 bit aligned bytes?

I thought:

    length = (xres + bpp-1) * bpp;

would be right. But, as I mentioned, I'm a bit confused ;-)

Christian.

[PATCH] Re: matrox+history+xoff=fbcon/linux crash?

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

On Mon, May 29, 2000 at 11:34:08PM +0000, Petr Vandrovec wrote:
> > Anyone else have this configuration and can verify the crash?
> Hmm. It is quite reproducible here on dual PIII SMP G400 too :-( 
> Probably it is time to start using 'video=scrollback:0' again... 
> Has anybody local filesystem which does not need fsck after kernel crash?!
Hi again,
  I found offender - but if someone more knowledgable could confirm
that...
  When problem happens, stack trace on first CPU (this is CPU which
already was in console subsystem when another arrived) looks like:

CPU:    1
EIP:    0010:[<c010c2e5>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00000096
eax: 0000001d   ebx: d0800000   ecx: c023ba34   edx: c023ba28
esi: c024e2b0   edi: d0800010   ebp: 00000010   esp: c15bbe1c
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c15bb000)
Stack: c15bbe20 00000018 c01a214d c021a23f c02b6ee0 c1532070 00000038 c1544000 
       ffffffff c1544000 00000001 01e701e0 0000007f 00000010 21a00010 00000001 
       c01a21e1 07070707 00000000 c02b6ee0 c1532078 00000004 0000021a 00000038 
Call Trace: [<c01a214d>] [<c021a23f>] [<c01a21e1>] [<c0194519>] [<c0196ac7>] [<c0175053>] [<c0121afb>] 
       [<c0121a1c>] [<c010d914>] [<c0109690>] [<c0109690>] [<c010bf0c>] [<c0109690>] [<c0109690>] [<c0100018>] 
       [<c01096bd>] [<c0109702>] [<c010bf0c>] 
Code: 50 1e 06 50 55 57 56 52 51 53 89 e0 50 e8 a9 fe ff ff 83 c4 

>>EIP; c010c2e5 <printstate+9/2c>   <=====
Trace; c01a214d <matrox_cfbX_putcs+32d/344>
Trace; c021a23f <dm_head_vals.930+7877/7cf5>
Trace; c01a21e1 <matrox_cfb8_putcs+7d/88>
Trace; c0194519 <fbcon_redraw_softback+201/2e4>
Trace; c0196ac7 <fbcon_scrolldelta+167/2b8>
Trace; c0175053 <console_softint+103/11c>
Trace; c0121afb <tasklet_action+4f/7c>
Trace; c0121a1c <do_softirq+5c/8c>
Trace; c010d914 <do_IRQ+e4/f4>
Trace; c0109690 <default_idle+0/34>
Trace; c0109690 <default_idle+0/34>
Trace; c010bf0c <ret_from_intr+0/20>
Trace; c0109690 <default_idle+0/34>
Trace; c0109690 <default_idle+0/34>
Trace; c0100018 <startup_32+18/c7>
Trace; c01096bd <default_idle+2d/34>
Trace; c0109702 <cpu_idle+3e/54>
Trace; c010bf0c <ret_from_intr+0/20>
Code;  c010c2e5 <printstate+9/2c>
[code stripped, it is only popad; ret]



This is stacktrace of CPU which should not came here...

CPU:    0
EIP:    0010:[<c010c2e5>]
EFLAGS: 00000286
eax: 0000001e   ebx: 21a00000   ecx: c023ba34   edx: c023ba28
esi: 00000008   edi: 00000130   ebp: 00000010   esp: cfd49d54
ds: 0018   es: 0018   ss: 0018
Process ls (pid: 16, stackpage=cfd49000)
Stack: cfd49d58 00000018 c01a1f38 c021a220 c02b6ee0 c152c04c 00000026 c1544000 
       00000003 c1544000 00000001 c1544000 0000007f 00000010 21a00010 00000001 
       c01a21e1 07070707 00000000 c02b6ee0 c152c04c 00000004 0000021a 00000026 
Call Trace: [<c01a1f38>] [<c021a220>] [<c01a21e1>] [<c0194519>] [<c0196ac7>] [<c0196c35>] [<c019411b>] 
       [<c0171e3e>] [<c017563a>] [<c017cb36>] [<c017f211>] [<c016c643>] [<c017ef78>] [<c0135cfe>] [<c010be4c>] 
Code: 50 1e 06 50 55 57 56 52 51 53 89 e0 50 e8 a9 fe ff ff 83 c4 

>>EIP; c010c2e5 <printstate+9/2c>   <=====
Trace; c01a1f38 <matrox_cfbX_putcs+118/344>
Trace; c021a220 <dm_head_vals.930+7858/7cf5>
Trace; c01a21e1 <matrox_cfb8_putcs+7d/88>
Trace; c0194519 <fbcon_redraw_softback+201/2e4>
Trace; c0196ac7 <fbcon_scrolldelta+167/2b8>
Trace; c0196c35 <fbcon_set_origin+1d/24>
Trace; c019411b <fbcon_cursor+57/1c8>
Trace; c0171e3e <set_cursor+6e/80>
Trace; c017563a <con_flush_chars+12/18>
Trace; c017cb36 <opost_block+15a/174>
Trace; c017f211 <write_chan+299/3a4>
Trace; c016c643 <tty_write+24b/340>
Trace; c017ef78 <write_chan+0/3a4>
Trace; c0135cfe <sys_write+de/100>
Trace; c010be4c <system_call+34/38>
Code;  c010c2e5 <printstate+9/2c>

[code stripped; it is only popad; ret]

So console system forgot to acquire lock somewhere between opost_block
and matrox_cfb8_putcs (I think that between opost_lock and
fbcon_set_origin, as scrollback is not reentrant too...). So
spin_lock(&console_lock); is missing either in con_flush_chars()
or in set_cursor() - and we cannot place it into set_cursor() because
of set_cursor() is invoked by vt_console_print(), which contains note:
Call me with console_lock held only...

There are 4 additional callers of set_cursor() which looks suspicious
to me: update_region(), redraw_screen(), unblank_screen() and
putconsxy(). I have no idea what is semantic of these functions and
I have to go home... But I think that at least putconsxy() should
acquire lock too.

So this patch is only minimal one. I was not able to cause crash
with this patch, but... there are still 4 unchecked entrypoints above...
						Petr Vandrovec
						van...@vc...

P.S.: Another solution is to disable scrollback. Then set_cursor
only shows cursor and this operation can be done specially (reentrant)
on vgacon/fbdev level (as software cursor blinks from bottomhalf,
these procedures are reentrant already... almost...).

P.P.S.: Alan, I do not know whether apply it or whether wait for
someone else's approval...

diff -urdN linux/drivers/char/console.c linux/drivers/char/console.c
--- linux/drivers/char/console.c	Sun Apr  2 22:20:27 2000
+++ linux/drivers/char/console.c	Mon May 29 21:05:03 2000
@@ -2290,10 +2290,13 @@
 
 static void con_flush_chars(struct tty_struct *tty)
 {
+	unsigned long flags;
 	struct vt_struct *vt = (struct vt_struct *)tty->driver_data;
 
 	pm_access(pm_con);
+	spin_lock_irqsave(&console_lock, flags);
 	set_cursor(vt->vc_num);
+	spin_unlock_irqrestore(&console_lock, flags);
 }
 
 /*

Re: [linux-fbdev] Planing for next kernel

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

> On Fri, May 26, 2000 at 08:12:41PM -0400, James Simmons wrote:
> > > One question.  Support for fonts that contain more than 512 characters, is
> > > it planned for fb or not?
> > 
> > I like to see that :) This is more of a console issue tho. 
> OK. :)  So has this already been discussed anywhere? And planned?

It hasn't been brought up yet that I know of. I know the emulation code is
being rewritten to behave much closer to a real vt100. If the old VT
series supported this it will be in there.

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

Synced with 2.4.0-test1

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

I just synced our work with kernel 2.4.0-test1. Now to work on more fbdev
drivers. Dominik your you ready to add your improvements 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: lots of fbdev updates

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

> >   As you can see we have alot of nice updates recently. Everything
> > complies, now to test it. As for the multihead support. I realized this is
> > going to be tougher than I though. I mean massive surgery of the tty
> > layer. 
> 
> Could you give some explanations why you need such heavy changes in the 
> tty layer? KGI does a tiny little patch to fix /dev/console mapping,
> but that's almost all. All the rest is being handled outside.

   Two primary reasons. The first being that fbdev can now support up to
256 video cards in the system. With USB support you can have up to 127
keyboards. So all total you can have 127 fully functional terminals. For
video consoles the tty layer only supports 64 VCs. This is hardcoded :(
From what Gooch told me this also impacts the serial drivers which
count on the first 64 ttys belonging to the video console layer. Soon this
will no longer be the case.
   This brings us to our second reason. Support for hot swappable cards
and insmodable drivers. Here we have to make the tty layer support a way
to dynamically add and subtract a VC pool for each card. 

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: lots of fbdev updates

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

James Simmons wrote:
> 
> Hi!
> 
>   As you can see we have alot of nice updates recently. Everything
> complies, now to test it. As for the multihead support. I realized this is
> going to be tougher than I though. I mean massive surgery of the tty
> layer.


Could you give some explanations why you need such heavy changes in the 
tty layer? KGI does a tiny little patch to fix /dev/console mapping,
but that's almost all. All the rest is being handled outside.


			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...
--------------- The KGI Project: http://kgi.sourceforge.org -------------------

lots of fbdev updates

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

Hi!

  As you can see we have alot of nice updates recently. Everything
complies, now to test it. As for the multihead support. I realized this is
going to be tougher than I though. I mean massive surgery of 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: nvidia text mode console

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

Pretty cool. I added to 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

On Wed, 10 May 2000, Matan Ziv-Av wrote:

> 
> Hi,
> 
> I wrote a console text mode driver for nvidia card which is not the
> primary card in the system. Its usage is similar to mdacon.
> The card needs to be initialized before the module is loaded, which can
> be done by the bios (if there is support for this in the bios), or the
> x86emu package.
> If you have more than one nvidia card in the system, use the vram module
> option to make sure the module controls the correct card (the one with
> the video ram aperture at the given address).
>  
> The source code is at http://www.arava.co.il/matan/misc/nvvgacon.tar.gz

fbdev updates

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

Hi!

  I just made a huge amount of updates this morning. I have done
extensive tetsing to ensure the drivers compile. Most do. I still have to
work on the cirrus, permidea and TGA driver. The rest are a go from what I
tested last night. The current CVS is now in complete sysnce with final
pre9. 
  I toke a look at the NVIDIA text console driver. Very nice work :) Like
fbdev you have to wait until pci is running to see whats going on. I
really like the idea of hardware text console drivers taking advantage of
higher end hardware with text modes. Another reason for fbdev and the
console system to be more seperated. I'm going to have to figure out how
to the NVIDIA text driver and the nvidia fbdev work in harmony.
Thank you for the driver.

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: I'm back

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

On Mon, May 22, 2000 at 09:53:20AM -0400, James Simmons wrote:
> 
> Hi!
>   
>   Sorry I was gone for awhile. I had to deal with recent fbdev issues.
> With the discussions it helped bring to light some very important issues
> and what needs to be dealt with. I have been busy as some might of seen
> redoing my fbdev drivers. I will place that work in CVS for people to try.
> I have serious updates to work on. I hope to finish them by tonight.
> Vojtech thank you so very much for keeping CVS in sync while I was gone.
> Off to finish my work.

Good. I am also back from vacation, but all sorts of disasters are keeping
me occupuied at the moment.  Hopefully i will have things sorted out by
the end of the week...

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                           

I'm back

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

Hi!
  
  Sorry I was gone for awhile. I had to deal with recent fbdev issues.
With the discussions it helped bring to light some very important issues
and what needs to be dealt with. I have been busy as some might of seen
redoing my fbdev drivers. I will place that work in CVS for people to try.
I have serious updates to work on. I hope to finish them by tonight.
Vojtech thank you so very much for keeping CVS in sync while I was gone.
Off to finish my work.

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/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: console alertness - notifying of console activities

[Jacek K. <kop...@in...>]

 > I think you put too much in the kernel, and you completely ignore
 > multi-heads setup. What you can probably do better is:
 > Have an event mask for every console (beep, write, cursor move, etc.)
 > and whenever an unmasked event occurs, write a packet describing the
 > event and which console to a char misc device. Then, a user space daemon
 > can read the events, and decide what to do.

Thanks for suggestions. 8-)
I recall now that policy shouldn't go into the kernel. 8-)
This was a quick-and-dirty patch to satisfy my needs. And it was made
for the 2.2.12 kernel without any consideration for future, so in
linuxconsole-dev I was actually only asking whether I should go on
with this (and implement that char device and other suggestions) or if
it's all unneeded and useless crap. 8-)
 AND I didn't know much about the kernel workings, certainly not
enough to even think of making a device. 8-) I'll probably be able to
study more during the summer, if I'm told it's useful and acceptable.

                            Jacek Kopecky
-- 
http://www.inf.upol.cz/~kopeckyj      ICQ: 49514837
Finger  kopeckyj(at)alpha.inf.upol.cz for Geek Code.

Re: console alertness - notifying of console activities

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

I think you put too much in the kernel, and you completely ignore
multi-heads setup. What you can probably do better is:
Have an event mask for every console (beep, write, cursor move, etc.)
and whenever an unmasked event occurs, write a packet describing the
event and which console to a char misc device. Then, a user space daemon
can read the events, and decide what to do.


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

console alertness - notifying of console activities

[Jacek K. <kop...@in...>]

 Hello. 8-)
 You might have seen this on lkml but I only got one response then...
I'd like to know if this has any value or if I should just keep my
small patch for myself. Your opinions?
 Following is the description of a patch to console.c and
console_macros.c from 2.2.12 (I know it's old but I don't know if I
should work on integrating my changes into your linuxcosole sets). 
 Also the patch itself is added.

Here's what I sent then:

I always wanted the console to be able to alert me when something
happened in it. So I started writing a patch to allow me to set a
virtual console so that it gets switched to whenever it beeps. I then
expanded it so that now you can:
 - have the vc switched to when it beeps,
 - have the vc switched to when anything is written to it,
 - have the vc beep whenever anything is written to it
 - do nothing of the above. 8-)

My current additions to get you interested:

Why would I like the console to beep/get switched to on write? I'd
want that in cases when I want to know that something happened (peer
in talk woke up, long computation ended etc.) 
 Once somebody suggested reading /dev/vcs$N periodically but that
doesn't work if nothing actually changes on the console (cursor
movements for example). But yes, userspace daemon would usually do,
but since I was doing the other switch (on beep) that cannot be done
in userspace (afaik) I could as well add this. 8-)

So why would I like the console to be switched to on beep? Again if my
peer in talk wanted my attention, they could beep. I'd then be
switched right into the console without having to look for the source
of the beep.

So again - I'll appreciate your ideas on whether to continue or forget
this. 8-)

                      Jacek Kopecky


The patch:
----------------------------------------------------------

diff -u --recursive linux-2.2.12/drivers/char/console.c linux/drivers/char/console.c
--- linux-2.2.12/drivers/char/console.c	Thu Mar 11 01:51:35 1999
+++ linux/drivers/char/console.c	Thu Jul 15 11:55:38 1999
@@ -66,6 +66,8 @@
  *
  * Resurrected character buffers in videoram plus lots of other trickery
  * by Martin Mares <mj...@at...>, July 1998
+ *
+ * Console alertness by Jacek Kopecky <ja...@un...>, July 1999
  */
 
 #include <linux/module.h>
@@ -1263,6 +1265,10 @@
 		case 14: /* set vesa powerdown interval */
 			vesa_off_interval = ((par[1] < 60) ? par[1] : 60) * 60 * HZ;
 			break;
+		case 15: /* set console alertness: 
+			    1 beep on write, 2 switch on beep , 3 switch on write*/
+			alert = (par[1] > 2) ? 3 : par[1];
+			break;
 	}
 }
 
@@ -1402,6 +1408,8 @@
 	save_cur(currcons);
 	if (do_clear)
 	    csi_J(currcons,2);
+
+	alert = 0;
 }
 
 static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int c)
@@ -1416,6 +1424,9 @@
 	case 7:
 		if (bell_duration)
 			kd_mksound(bell_pitch, bell_duration);
+		/* switch console if alertness on beep */
+		if ((alert == 2) && (currcons != fg_console))
+			change_console(currcons);
 		return;
 	case 8:
 		bs(currcons);
@@ -1927,6 +1938,16 @@
 	}
 	FLUSH
 	enable_bh(CONSOLE_BH);
+
+	/* Switch to this console if alertness is 3
+	 * or beep if alertness is 1
+	 */
+	if (alert && (currcons != fg_console)) {
+		if (alert == 3) change_console(currcons);
+		else if ((alert == 1) && bell_duration)
+			kd_mksound(bell_pitch, bell_duration);
+	}
+
 	return n;
 #undef FLUSH
 }
diff -u --recursive linux-2.2.12/drivers/char/console_macros.h linux/drivers/char/console_macros.h
--- linux-2.2.12/drivers/char/console_macros.h	Thu Sep 17 18:35:03 1998
+++ linux/drivers/char/console_macros.h	Wed Jun 30 20:50:00 1999
@@ -64,6 +64,7 @@
 #define complement_mask (vc_cons[currcons].d->vc_complement_mask)
 #define s_complement_mask (vc_cons[currcons].d->vc_s_complement_mask)
 #define hi_font_mask	(vc_cons[currcons].d->vc_hi_font_mask)
+#define alert		(vc_cons[currcons].d->vc_alert)
 
 #define vcmode		(vt_cons[currcons]->vc_mode)
 
diff -u --recursive linux-2.2.12/include/linux/console_struct.h linux/include/linux/console_struct.h
--- linux-2.2.12/include/linux/console_struct.h	Thu Sep 17 18:35:04 1998
+++ linux/include/linux/console_struct.h	Wed Jun 30 22:45:11 1999
@@ -65,6 +65,7 @@
 	unsigned int	vc_can_do_color	: 1;
 	unsigned int	vc_report_mouse : 2;
 	unsigned int	vc_kmalloced	: 1;
+	unsigned int	vc_alert	: 2;    /* Switch to this console on write or beep */
 	unsigned char	vc_utf		: 1;	/* Unicode UTF-8 encoding */
 	unsigned char	vc_utf_count;
 		 int	vc_utf_char;
diff -u --recursive --new-file linux-2.2.12/Documentation/console-alertness linux/Documentation/console-alertness
--- linux-2.2.12/Documentation/console-alertness	Thu Jan  1 01:00:00 1970
+++ linux/Documentation/console-alertness	Fri Aug  6 22:45:45 1999
@@ -0,0 +1,31 @@
+This file describes the console alertness function of linux virtual consoles
+as implemented by Jacek Kopecky (ja...@un...) in July 1999.
+
+First, what does console alertness mean anyway?
+In cases when you want to be warned when something changes or only beeps on a
+virtual console other than the one that's active at the moment (so that you
+don't see the changes yourself), you can use the following escape sequences
+to set the console-alertness-level to get some warnings:
+
+echo -ne "\033[15;0]" > /dev/ttyX	    alertnes off ("beep on beep")
+echo -ne "\033[15;1]" > /dev/ttyX	    beep on write to the console
+echo -ne "\033[15;2]" > /dev/ttyX	    switch to the console on beep
+echo -ne "\033[15;3]" > /dev/ttyX	    switch to the console on write
+
+At the level 1 the virtual console /dev/ttyX beeps whenever anything is
+written to it but only if the console is not currently the foreground console.
+The level 2 makes the console get switched to whenever it beeps. On the highest
+level the console gets switched to on each write to it.
+
+A side-effect of setting beep-on-write (1) or switch-on-write (3) on another
+console is that the other console beeps or is switched to, this comes handy
+as a test it's working. 8-)
+The sequence for setting the switch-on-beep (2) level can be enhanced to give
+the same kind of test:
+
+echo -ne "\033[15;2]\a" > /dev/ttyX
+
+The setting sequences may seem to be a little too user-unfriendly so I'm
+planning to try to incorporate alertness setting into the setterm package.
+
+Enjoy. 8-)

nvidia text mode console

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

Hi,

I wrote a console text mode driver for nvidia card which is not the
primary card in the system. Its usage is similar to mdacon.
The card needs to be initialized before the module is loaded, which can
be done by the bios (if there is support for this in the bios), or the
x86emu package.
If you have more than one nvidia card in the system, use the vram module
option to make sure the module controls the correct card (the one with
the video ram aperture at the given address).


The source code is at http://www.arava.co.il/matan/misc/nvvgacon.tar.gz



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

Re: running true multihead...

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

Marcus Sundberg wrote:
> 
> Steffen Seeger <s.s...@ph...> writes:
> 
> > However, even if that would have worked, there is another issue I came about
> > when configuring XDM:
> >
> > xterm and some other programs expect /dev/console to be owned by the user
> > sitting on the console. So, even if we map /dev/console to tty's on a
> > per-work-place basis, how do we manage to map ownership and permissions?
> 
> Hmm? xterm doesn't even touch /dev/console on any Linux-system I've
> seen, and I doubt many other regular user application do either.
> Exactly what problems are you experiencing?

The two scripts 

/usr/X11/lib/X11/xdm/TakeConsole
/usr/X11/lib/X11/xdm/GiveConsole

give the following notice:

# Reassign ownership of the console to root, this should disallow
# assignment of console output to any random users's xterm

and change permissions and ownership on /dev/console. It seems as there
is some security issue involved, e.g. xterm and may be xconsole
requiring correct ownership of /dev/console before attaching to the console.

There is a similar mechanism (see /etc/security/console.perms) used to control
access to joysticks, mice, serial lines, etc.).

So, my concern is (as with other device files in /dev/ that virtualize
workplace local devices), that if running two independent sessions from xdm
the session started later will take over devices of the first, unless
the device sets have no common elements. Also, applications that require
user-local preferences (e.g. what is your preferred sound output device)
will fail if you are not logged on to the same head as during configuration.

What I do imagine is something like /proc/self for workplace local devices.
But do not yet know if that is actually enough...

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...
TU-Chemnitz                                      http://www.tu-chemnitz.de/~sse
--------------- The GGI Project: http://www.ggi-project.org -------------------