linuxconsole-dev

Re: New to the input layer

[Franz S. <Fra...@la...>]

At 13:19 04.07.00, Vojtech Pavlik wrote:
>But something like that will be badly needed for other parts of the
>system as well. For example the USB Storage driver already does it. So
>it's possible.

I'll check that out.


> > Hmm. Let me think about that... What will the application see? I don't see
> > a type like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?
>
>Right now, the events from the device will just stop coming in.

Hmm, this means even input layer aware applications will have no chance to 
react? Is anything planned in this area?

> > I see. Actually, what I'm looking for is a reasonable simple way to port
> > some legacy (but unfortunately still needed) applications to the input
> > layer... Hmm, I can live with mice and keyboards being separate, so would
> > you accept if I added a keyboard mixer device to keybdev.c?
>
>Keybdev.c already does that, and keyboard.c (in the complete input
>drivers) is doing it as well.

Heh, but they mix to "legacy" console devices (or do I miss something 
here?), I want an event protocol device :-). Remember, on PPC we used ADB 
scancodes so far. I don't wan't to change to AT scancodes now and then 
again to events, when the input layer is 100% ready. That's why I want a 
/dev/input/keyboards, running the event protocol. I'll make it CONFIG_PPC 
specific if you want.

> > BTW, are there any known problems with the current backport and console
> > switching? It seems to lock down some of the modifier keys from time to
> > time, then you have to press all of them to get them back in a known state.
> > And it seems the LED status sent to USB keyboards is inverted.
>
>There seems to be a problem with some keys not getting released
>correctly. I wasn't able to find the cause yet.

I have a feeling that this might be related to key repeat. What happens to 
the repeat timers on console switch?

Also do you know if the LED's on USB keyboards work correctly on a PC? 
Benjamin is working with the USB analyzer today and will look at this.

Benjamin Herrenschmidt wrote a few minutes ago on IRC/#mklinux/EFnet:
<BenH> Also, I have the HID specs, I'll be able to look at those LEDs 
problems. I'd like to know if they work on PC however
<BenH> Looks like apple leaves KBDs in boot protocol on MacOS 9
<BenH> They do a SetProtocol(0), a SetIdle, a few SetReport and that's all

Franz.

Re: New to the input layer

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

On Tue, Jul 04, 2000 at 12:25:17PM +0200, Franz Sirl wrote:

> >Creating /dev/input/events is the wrong approach. Creating a way how to
> >make an already-open disappearing and appearing again device to appear
> >back at the same device number.
> 
> Seems like a quite difficult task to me...

But something like that will be badly needed for other parts of the
system as well. For example the USB Storage driver already does it. So
it's possible.

> Hmm. Let me think about that... What will the application see? I don't see 
> a type like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?

Right now, the events from the device will just stop coming in.

> I see. Actually, what I'm looking for is a reasonable simple way to port 
> some legacy (but unfortunately still needed) applications to the input 
> layer... Hmm, I can live with mice and keyboards being separate, so would 
> you accept if I added a keyboard mixer device to keybdev.c?

Keybdev.c already does that, and keyboard.c (in the complete input
drivers) is doing it as well.

> >The ioctls should modify the event->keymap structure.
> 
> Sure. But you mean event->keycode, or?

Sorry, I meant struct input_dev->keycode. I should have checked the
sources first.

> >Ok. Implementing setkeycode with USB keyboards won't be easy, since
> >hid.c has a quite complicated structure for this. If you won't be able
> >to find any such initialization (and even if you will) I think an
> >exception in the hid.c driver for this keyboard will be needed.
> 
> I'll try to find out more.
> 
> BTW, are there any known problems with the current backport and console 
> switching? It seems to lock down some of the modifier keys from time to 
> time, then you have to press all of them to get them back in a known state.
> And it seems the LED status sent to USB keyboards is inverted.

There seems to be a problem with some keys not getting released
correctly. I wasn't able to find the cause yet.

-- 
Vojtech Pavlik
SuSE Labs

Re: New to the input layer

[Franz S. <Fra...@la...>]

At 23:36 03.07.00, Vojtech Pavlik wrote:
> > > > - why is there no mixer device /dev/input/events similar to
> > > > /dev/input/mice? Should I implement such a device?
> > >
> > >Is it needed for anything?
> >
> > Well, I have noticed that on unplugging/replugging a device, it won't
> > re-use the previous /dev/input/eventX if it is still held open by an
> > application. That means applications have to scan the event devices
> > continously themselves as soon as the device is removed, to check where it
> > reappears. Think about an X user which unplugs his keyboard, plugs in a
> > mouse and replugs the keyboard, does X have to scan then on which eventX
> > device the keyboard reappears? I think this is overkill for the usual
> > single-user single/multi-screen installations which probably make up 99.9%
> > of all installations. With a /dev/input/events mixer device X can 
> attach to
> > a single device for all events and doesn't have to care what the user does
> > with them. Maybe a ioctl to attach/detach event devices from the event
> > mixer would be a good idea then.
>
>Creating /dev/input/events is the wrong approach. Creating a way how to
>make an already-open disappearing and appearing again device to appear
>back at the same device number.

Seems like a quite difficult task to me...


>The device number is currently held busy until it's not referenced
>anymore. It doesn't have to be so.

Hmm. Let me think about that... What will the application see? I don't see 
a type  like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?

> > > > - only 32 event devices, looks a bit short sighted?
> > >
> > >There's space for up to 196 (64-255).
> >
> > Yes, I know. I was searching for a good minor for /dev/input/events.
> > Probably 255 then :-).
>
>I really don't think it's needed. We would have to add some device ID to
>struct input_event, because mixing input from a joystick and a tablet
>(or two joysticks or whatever) simply wouldn't work.

I see. Actually, what I'm looking for is a reasonable simple way to port 
some legacy (but unfortunately still needed) applications to the input 
layer... Hmm, I can live with mice and keyboards being separate, so would 
you accept if I added a keyboard mixer device to keybdev.c?


> > > > - the [sg]etkeycode ioctls are not implemented yet, anyone working on
> > > this?
> > > > If not, I'll probably give it a shot
> > >
> > >Please do.
> >
> > OK, I will try to come up with a patch this week.
>
>The ioctls should modify the event->keymap structure.

Sure. But you mean event->keycode, or?


> > >Really? What keyboard is it and what keys it doesn't report to have? I
> > >think this is more likely to be included in a 'blacklist' in the hid
> > >driver.
> >
> > It's a Lindy USB kbd for Macintosh, german version. It looks similar to 
> the
> > MacSense one. It reports itself as ALCOR 9410 (this seems to be the ID of
> > the generic Alcor kbd/hub chip, so it's probably hard to distinguish from
> > PC keyboards), language ID 409. The missing keys are KEY_POWER (0x66) and
> > KEY_KPEQUAL (0x67). I'll try to find out if MacOS uses some initialization
> > USB command to switch the keyboard to a different mode.
>
>Ok. Implementing setkeycode with USB keyboards won't be easy, since
>hid.c has a quite complicated structure for this. If you won't be able
>to find any such initialization (and even if you will) I think an
>exception in the hid.c driver for this keyboard will be needed.

I'll try to find out more.

BTW, are there any known problems with the current backport and console 
switching? It seems to lock down some of the modifier keys from time to 
time, then you have to press all of them to get them back in a known state.
And it seems the LED status sent to USB keyboards is inverted.

Franz.

Re: New to the input layer

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

On Mon, Jul 03, 2000 at 06:57:31PM +0200, Franz Sirl wrote:
> At 17:57 03.07.00, Vojtech Pavlik wrote:
> >On Mon, Jul 03, 2000 at 01:02:08PM +0200, Franz Sirl wrote:
> > > Hi,
> > >
> > > I'm currently working on the integration of PMac ADB into the input layer.
> > > I use the 2.2.16 USB backport for my work and most stuff works well
> > > already. But I have some generic implementation questions now:
> > >
> > > - who will assign a BUS_ADB number? I used 0x17 for now
> >
> >That's ok.
> 
> Fine. Please update input.h then, I'll remove my local definition as soon 
> as they collide :-)

Ok. Added.

> > > - why is there no mixer device /dev/input/events similar to
> > > /dev/input/mice? Should I implement such a device?
> >
> >Is it needed for anything?
> 
> Well, I have noticed that on unplugging/replugging a device, it won't 
> re-use the previous /dev/input/eventX if it is still held open by an 
> application. That means applications have to scan the event devices 
> continously themselves as soon as the device is removed, to check where it 
> reappears. Think about an X user which unplugs his keyboard, plugs in a 
> mouse and replugs the keyboard, does X have to scan then on which eventX 
> device the keyboard reappears? I think this is overkill for the usual 
> single-user single/multi-screen installations which probably make up 99.9% 
> of all installations. With a /dev/input/events mixer device X can attach to 
> a single device for all events and doesn't have to care what the user does 
> with them. Maybe a ioctl to attach/detach event devices from the event 
> mixer would be a good idea then.

Creating /dev/input/events is the wrong approach. Creating a way how to
make an already-open disappearing and appearing again device to appear
back at the same device number.

The device number is currently held busy until it's not referenced
anymore. It doesn't have to be so.

> > > - only 32 event devices, looks a bit short sighted?
> >
> >There's space for up to 196 (64-255).
> 
> Yes, I know. I was searching for a good minor for /dev/input/events. 
> Probably 255 then :-).

I really don't think it's needed. We would have to add some device ID to
struct input_event, because mixing input from a joystick and a tablet
(or two joysticks or whatever) simply wouldn't work.

> > > - the [sg]etkeycode ioctls are not implemented yet, anyone working on 
> > this?
> > > If not, I'll probably give it a shot
> >
> >Please do.
> 
> OK, I will try to come up with a patch this week.

The ioctls should modify the event->keymap structure.

> >Really? What keyboard is it and what keys it doesn't report to have? I
> >think this is more likely to be included in a 'blacklist' in the hid
> >driver.
> 
> It's a Lindy USB kbd for Macintosh, german version. It looks similar to the 
> MacSense one. It reports itself as ALCOR 9410 (this seems to be the ID of 
> the generic Alcor kbd/hub chip, so it's probably hard to distinguish from 
> PC keyboards), language ID 409. The missing keys are KEY_POWER (0x66) and 
> KEY_KPEQUAL (0x67). I'll try to find out if MacOS uses some initialization 
> USB command to switch the keyboard to a different mode.

Ok. Implementing setkeycode with USB keyboards won't be easy, since
hid.c has a quite complicated structure for this. If you won't be able
to find any such initialization (and even if you will) I think an
exception in the hid.c driver for this keyboard will be needed.

> >None - the Fn key on notebooks usually doesn't generate any scancodes.
> >Anyway, the "KEY_MACRO" (112) would make sense - it's used for keys like
> >that (Macro key, Logitech key, Multi key, or the Fn key).
> 
> Aha, thanks. Some Powerbooks with ADB keyboards seem to report this key.

Ok.

-- 
Vojtech Pavlik
SuSE Labs

Re: New to the input layer

[Franz S. <Fra...@la...>]

At 17:57 03.07.00, Vojtech Pavlik wrote:
>On Mon, Jul 03, 2000 at 01:02:08PM +0200, Franz Sirl wrote:
> > Hi,
> >
> > I'm currently working on the integration of PMac ADB into the input layer.
> > I use the 2.2.16 USB backport for my work and most stuff works well
> > already. But I have some generic implementation questions now:
> >
> > - who will assign a BUS_ADB number? I used 0x17 for now
>
>That's ok.

Fine. Please update input.h then, I'll remove my local definition as soon 
as they collide :-)

> > - why is there no mixer device /dev/input/events similar to
> > /dev/input/mice? Should I implement such a device?
>
>Is it needed for anything?

Well, I have noticed that on unplugging/replugging a device, it won't 
re-use the previous /dev/input/eventX if it is still held open by an 
application. That means applications have to scan the event devices 
continously themselves as soon as the device is removed, to check where it 
reappears. Think about an X user which unplugs his keyboard, plugs in a 
mouse and replugs the keyboard, does X have to scan then on which eventX 
device the keyboard reappears? I think this is overkill for the usual 
single-user single/multi-screen installations which probably make up 99.9% 
of all installations. With a /dev/input/events mixer device X can attach to 
a single device for all events and doesn't have to care what the user does 
with them. Maybe a ioctl to attach/detach event devices from the event 
mixer would be a good idea then.

> > - only 32 event devices, looks a bit short sighted?
>
>There's space for up to 196 (64-255).

Yes, I know. I was searching for a good minor for /dev/input/events. 
Probably 255 then :-).


> > - the [sg]etkeycode ioctls are not implemented yet, anyone working on 
> this?
> > If not, I'll probably give it a shot
>
>Please do.

OK, I will try to come up with a patch this week.

> > - it seems an ioctl to set the key bitmap is needed, cause I have an USB
> > keyboard here which reports 0x65 keys, when in reality it has 0x67 :-(
>
>Really? What keyboard is it and what keys it doesn't report to have? I
>think this is more likely to be included in a 'blacklist' in the hid
>driver.

It's a Lindy USB kbd for Macintosh, german version. It looks similar to the 
MacSense one. It reports itself as ALCOR 9410 (this seems to be the ID of 
the generic Alcor kbd/hub chip, so it's probably hard to distinguish from 
PC keyboards), language ID 409. The missing keys are KEY_POWER (0x66) and 
KEY_KPEQUAL (0x67). I'll try to find out if MacOS uses some initialization 
USB command to switch the keyboard to a different mode.


> > - what key entry in input.h relates to the "Fn" key found on notebooks?
>
>None - the Fn key on notebooks usually doesn't generate any scancodes.
>Anyway, the "KEY_MACRO" (112) would make sense - it's used for keys like
>that (Macro key, Logitech key, Multi key, or the Fn key).

Aha, thanks. Some Powerbooks with ADB keyboards seem to report this key.

Franz.

Re: New to the input layer

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

On Mon, Jul 03, 2000 at 01:02:08PM +0200, Franz Sirl wrote:
> Hi,
> 
> I'm currently working on the integration of PMac ADB into the input layer. 
> I use the 2.2.16 USB backport for my work and most stuff works well 
> already. But I have some generic implementation questions now:
> 
> - who will assign a BUS_ADB number? I used 0x17 for now

That's ok.

> - why is there no mixer device /dev/input/events similar to 
> /dev/input/mice? Should I implement such a device?

Is it needed for anything?

> - only 32 event devices, looks a bit short sighted?

There's space for up to 196 (64-255).

> - the [sg]etkeycode ioctls are not implemented yet, anyone working on this? 
> If not, I'll probably give it a shot

Please do.

> - it seems an ioctl to set the key bitmap is needed, cause I have an USB 
> keyboard here which reports 0x65 keys, when in reality it has 0x67 :-(

Really? What keyboard is it and what keys it doesn't report to have? I
think this is more likely to be included in a 'blacklist' in the hid
driver.

> - what key entry in input.h relates to the "Fn" key found on notebooks?

None - the Fn key on notebooks usually doesn't generate any scancodes.
Anyway, the "KEY_MACRO" (112) would make sense - it's used for keys like
that (Macro key, Logitech key, Multi key, or the Fn key).

-- 
Vojtech Pavlik
SuSE Labs

New to the input layer

[Franz S. <Fra...@la...>]

Hi,

I'm currently working on the integration of PMac ADB into the input layer. 
I use the 2.2.16 USB backport for my work and most stuff works well 
already. But I have some generic implementation questions now:

- who will assign a BUS_ADB number? I used 0x17 for now
- why is there no mixer device /dev/input/events similar to 
/dev/input/mice? Should I implement such a device?
- only 32 event devices, looks a bit short sighted?
- the [sg]etkeycode ioctls are not implemented yet, anyone working on this? 
If not, I'll probably give it a shot
- it seems an ioctl to set the key bitmap is needed, cause I have an USB 
keyboard here which reports 0x65 keys, when in reality it has 0x67 :-(
- what key entry in input.h relates to the "Fn" key found on notebooks?

Thanks,
Franz.

Re: console_lock too early in printk???

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

> Is it currently possible to make a driver which leaves the accel engine
> do its work on the background so you don't have to wait by polling the 
> hardware until the operation is done? With issues like this, it is still
> possible that bigger blits will cause relatively big latencies. Certainly
> not in the tens-of-seconds variety but unacceptable for the causes people
> keep arguing here about.

True. This is a more general problem that needs a more general solution.

> I haven't got a picture how multihead will be worked out? Will you have
> some per-head structure? Then it is natural to move most of the current 
> global variables and locks in this structure.

For the console system yes. I also have rewritten the console code to
reentry since this is required in a multihead enivornment. At least I
hope. As for raw hardware device access like /dev/dsp and /dev/fb I
haven't figured away around that 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: console_lock too early in printk???

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

> > If we really want to fix this problem we have to rethink the console lock.
> > See my other post.
> 
> I agree that a more general solution would be better... but it would
> probably not be appropriate for 2.4.0...

Right. I'm working on it now for 2.5.X :-) I rather have code go in right
away and have it already tested to make sure it works.

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: console_lock too early in printk???

[Chris L. <sa...@sk...>]

> > Moral of this story:  Don't you DARE use printk for debugging, you might
> > introduce more problems than you started with.  :)
> Especially with video drivers :-(

Or in my case... the VM system.  :)

> > On a more serious note... couldn't issues like these be temporarily side
> > stepped by making the console_lock recursive, similar to the monster
> > kernel_lock?  You could keep one copy of the entrance count with the lock
> > itself, rather than one copy each in the "current" task_struct...

> If we really want to fix this problem we have to rethink the console lock.
> See my other post.

I agree that a more general solution would be better... but it would
probably not be appropriate for 2.4.0...

-Chris

Re: console_lock too early in printk???

[Aki M L. <aml...@cc...>]

On Sat, 1 Jul 2000, James Simmons wrote:
> > 1. Get rid of the tasklet and setup a worker thread, kconsoled, to do
> > the dirty work. This has plus side that we can sleep and check if we
> > need rescheduling.
> 
> That's a interesting idea. The problem is mostly with fbcon. It just takes
> to long to draw pixel by pixel. In time I hope to see fbcon move to become 

You tell me about it. On a laptop I have, I always have to be extremely
cautious not to say for example cat bigger text files. If I do, then the
whole machine is pretty much jammed, until it is done. During that time
even keyboard input (ctrl-c or changing virtual terminals) does not work.

> accelcon where nearly all the drivers use the video cards accel engine to
> draw for the console. This should nearly eliminate the latency problems.

Is it currently possible to make a driver which leaves the accel engine
do its work on the background so you don't have to wait by polling the 
hardware until the operation is done? With issues like this, it is still
possible that bigger blits will cause relatively big latencies. Certainly
not in the tens-of-seconds variety but unacceptable for the causes people
keep arguing here about.

> we most likely will run into problems. So the locking system needs to be 
> thought out. By next week I will have multihead running for mdacon and
> vgacon so I will find out. 

I haven't got a picture how multihead will be worked out? Will you have
some per-head structure? Then it is natural to move most of the current 
global variables and locks in this structure.

> Do you think you can come up with some code to try out. As I said by next
> week I will have multihead running so we can give these ideas a try. As

Not so soon, sorry. I don't have time until thursday earliest.

> for moving the console/vt code to userspace. In theory you can do this
> using /dev/fbX and /dev/eventX to create a userland console.

If only you didn't need to printk fatal oopses/panics/etc, the portion of
code which would have to live in kernel would be pretty minimal.


-- 
D.

[PATCH] Small kernel/printk.c fix (fwd)

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

---------- Forwarded message ----------
Date: Fri, 30 Jun 2000 12:58:47 +0200
From: Benjamin Herrenschmidt <bh...@ca...>
To: tor...@tr..., al...@lx...
Cc: lin...@vg...
Subject: [PATCH] Small kernel/printk.c fix


Hi Linus & Alan.

Here's a small change to kernel/printk.c that I expect harmless.
Basically, it reverts the console registration mecanism to a clean state
when the last console is unregistered. It helps implementing a very small
early boot debug mecanism I use on the PPC tree that enables very-early
use of printk but which, without this patch, cause problems when the real
VT takes over.

(Since it's a small mecanism, it's implemented as a console structure,
implementing a consw would be really way too much for what it's meant for
and would bloat the code).

I usually keep this patch in my tree, but having it merged would help me
reducing the diffs between my own tree and the main one and would allow
this useful mecanism to be merged in the main PPC branch.

Here's the 2.2.x version (as of 2.2.17pre7)

--- linuxppc_2_2/kernel/printk.c	Fri Jun 30 12:00:07 2000
+++ ben_kernel/kernel/printk.c	Tue Jun 27 15:10:30 2000
@@ -468,7 +468,14 @@
 			}  
 		}
 	}
-	
+
+	/* If last console is removed, we re-enable picking the first
+	 * one that gets registered. Without that, pmac early boot console
+	 * would prevent fbcon from taking over.
+	 */
+	if (console_drivers == NULL)
+		preferred_console = -1;
+		
 	spin_unlock_irqrestore(&console_lock,flags);
 	return res;
 }

Here's the 2.4 version (as of test2)

--- printk.c.orig	Fri Jun 30 12:47:25 2000
+++ printk.c	Fri Jun 30 12:46:52 2000
@@ -471,6 +471,14 @@
 		}
 	}
 	
+	/* If last console is removed, we re-enable picking the first
+	 * one that gets registered. Without that, pmac early boot console
+	 * would prevent fbcon from taking over.
+	 */
+	if (console_drivers == NULL)
+		preferred_console = -1;
+		
+
 	spin_unlock_irqrestore(&console_lock, flags);
 	return res;
 }


Regards,
Ben.




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

console_lock too early in printk??? (fwd)

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

Date: Fri, 30 Jun 2000 18:37:20 -0700 (PDT)
From: Chris Lattner <sa...@sk...>
To: lin...@vg...
Subject: console_lock too early in printk???


I've been fighting a bizarre spinlock problem... and it turns out that I
was reentrantly calling printk...  the problem was that while vsprintf was
executing, it dereferenced a pointer on an unpaged page... which caused a
page fault, which caused (for me) a printk...  the problem is that it
would then try to reaquire the console_lock... which it could never do.

So....

I moved the "spin_lock_irqsave(&console_lock, flags);" to after the
va_end, so that the printk code looks like this:

        va_start(args, fmt);
        i = vsprintf(buf + 3, fmt, args); /* hopefully i < sizeof(buf)-4 */
        buf_end = buf + 3 + i;
        va_end(args);
        spin_lock_irqsave(&console_lock, flags);

        for (p = buf + 3; p < buf_end; p++) {

instead of this:

	spin_lock_irqsave(&console_lock, flags);
        va_start(args, fmt);
        i = vsprintf(buf + 3, fmt, args); /* hopefully i < sizeof(buf)-4 */
        buf_end = buf + 3 + i;
        va_end(args);
        for (p = buf + 3; p < buf_end; p++) {

And everything is beautiful and things just magically work for me.

Okay, so my question is this ('cause obviously people shouldn't be
printk'ing their pagefault handlers!):

Why are we grabbing the console lock so early?  Is it really neccesary
there (I don't think so)?  With lots of printk's, concurrancy is
needlessly killed (vsprintf can take a relatively long time...)

Anyways, does anyone see a problem with moving it for 2.4?

-Chris



-
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: console_lock too early in printk???

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

> Just one?-) I thought about this and the console latency problems a bit.
> Would the following sound reasonable in mid/long-term? 
> 
> 1. Get rid of the tasklet and setup a worker thread, kconsoled, to do
> the dirty work. This has plus side that we can sleep and check if we
> need rescheduling.

That's a interesting idea. The problem is mostly with fbcon. It just takes
to long to draw pixel by pixel. In time I hope to see fbcon move to become 
accelcon where nearly all the drivers use the video cards accel engine to
draw for the console. This should nearly eliminate the latency problems.
Their will still be offb and vesafb which have no accel support but has
more accelerated fbdev drivers come into being this will go away.   
 
> 2. Create a new console semaphore and serialize with consoledriver.write 
> by that means instead of the console spinlock.

This needs to be done. Soon or later we are going to run into video
hardware that is irq driven only. Also once the kernel supports multihead 
we most likely will run into problems. So the locking system needs to be 
thought out. By next week I will have multihead running for mdacon and
vgacon so I will find out. 

> Having done that there's still printk which is the big problem. How about
> if we change semantics, 
> 
> printk: serializes by means of semaphore so can sleep. If in interrupt
> then queue the job for the worker thread to do asynchronously. I think
> most places in interrupts could change to use asynchronous semantics.
> __printk: same but doesn't grab the lock - used inside console code?
> 
> This will leave us with that one ugly case (oopses/panics etc.) which
> simply have to get the job done but maybe console is in inconsistant
> state. So what to do, I'm not sure? Safe way would be to check an
> atomic variable (console_dirty) and abort if no can do. The other strategy
> would be to hope the best and see what happens.
> 
> I must have missed something? Btw. has anyone thought of pushing most
> of console/vt code to user-space?

Do you think you can come up with some code to try out. As I said by next
week I will have multihead running so we can give these ideas a try. As
for moving the console/vt code to userspace. In theory you can do this
using /dev/fbX and /dev/eventX to create a userland console.

Re: console_lock too early in printk???

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

> Moral of this story:  Don't you DARE use printk for debugging, you might
> introduce more problems than you started with.  :)

Especially with video drivers :-(

> On a more serious note... couldn't issues like these be temporarily side
> stepped by making the console_lock recursive, similar to the monster
> kernel_lock?  You could keep one copy of the entrance count with the lock
> itself, rather than one copy each in the "current" task_struct...

If we really want to fix this problem we have to rethink the console lock.
See my other post.

Re: early multihead support

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

> Sorry if this reply is too much after the fact, but I have the
> required setup you describe above.  I use a PCI Cirrus Logic
> with an old ISA mono card with kernels 2.2.x and it works
> fine.  If you've got some new code that needs testing, I'd be
> glad too.  I also have a Voodoo card in this box as well - if
> that makes any difference.
> 
> Just let me know if you need any testing, either public testing
> or private stuff - you can email me - as can anyone else involved
> with the console stuff.
> 
> I look forward to this new subsystem.

Its almost done. I have to finish the blanking code. After this is
just a matter of changing the size of the VC pools to 16 and with the
current 64 limit we can have 4 active heads at one time. After this I'm
going to have to raise the 64 limit which is going to require alot of tty
code changes :-( I will announce when you will be avaiable for testing and
then once we have it going I will announce it on the kernel and fbdev
mailing list. 

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: [linux-fbdev] Rage128 engine idle interrupt

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

> Do not forget that it has no use in fbdev, as in 2.4.x complete fb
> system is guarded by spin_lock_irqsave(&console_lock, ...) - i.e.
> runs with interrupts disabled (and you cannot reenable them without
> changes to console subsystem).
> 
> Yes, we should change it, as currently I can dialup only with 
> 'fbset -depth 0', as otherwise sometime some characters get lost between 
> modem and pppd during VT switches. But I do not think that change will 
> happen before 2.4.0...

I noticed this to. Yes the console lock needs to be replaced with
some else. It don't think its going to be good enough for multihead
systems. Also one lock is going to be poor performace. Their is no reason
to lock out multiple VTs. Just the VT that is impacted. 

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: early multihead support

[Mike A. H. <mh...@me...>]

On Sun, 30 Apr 2000, James Simmons wrote:

>Date: Sun, 30 Apr 2000 10:55:05 -0400 (EDT)
>From: James Simmons <jsi...@ac...>
>To: Linux console project <lin...@li...>
>Subject: early multihead support
>
>
>hi!!
>
>  Well today I have been work on some new code that will allow you to boot
>both a MDA display and a VGA con display at the same time. I'm going to
>finish it today. Does anyone have a MDA display and a video card that can
>run as VGAcon. I really like to give this a try soon. Thank you.
>
>Q: Why did they deprecate a.out support in linux?
>A: Because a nasty coff is bad for your elf.

Sorry if this reply is too much after the fact, but I have the
required setup you describe above.  I use a PCI Cirrus Logic
with an old ISA mono card with kernels 2.2.x and it works
fine.  If you've got some new code that needs testing, I'd be
glad too.  I also have a Voodoo card in this box as well - if
that makes any difference.

Just let me know if you need any testing, either public testing
or private stuff - you can email me - as can anyone else involved
with the console stuff.

I look forward to this new subsystem.

Take care,
TTYL

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

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

current status

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

Hi!

  I just wanted to give updates to what has been happening. The vt_struct
and vc_data tree setup I has talking about has been put into place. I
haven't made the vt_struct a link list so multihead has been disabled for 
now. Once I'm finish I will bring it right back. I have devleoped a VC
pool for each vt_struct. Also you can add more pools. I have yet
to implement this due to the the 64 tty limit :-( I have unblanking when
you press the keyboard effect a particular VT. 

  This brings me to some questions about hwat you did Vojtech. Is
show_console obsolete now ? Also you have register_leds but nothing uses
it. What is it for? I know it is safe to call poke_blank_console direct so
I'm going to try to see if we can remove 

do_poke_blanked_console;
takslet_schedule(...)

and replace it with a call to poke_blank_console instead. Off it test. By
the way everything in CVS compiels and works :-)

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: VC switching code fixed :-)!!!!!!!!

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

> > Yeap. I rewrote the VT switching code today and it works great. It nearly
> > fixed that one buig you reported Vojtech with seeing AAA if you keep VT
> > switching to the first VC. It still does it but much much less often. Give
> > it a try.
> 
> Cool! I will. Now if you could also fix at least the MGAfb, it'd be
> neat.

Give me a few days. I'm on the verge of multihead support. A few more
things have to go in 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: VC switching code fixed :-)!!!!!!!!

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

On Sat, Jun 24, 2000 at 08:15:29PM -0400, James Simmons wrote:

> Yeap. I rewrote the VT switching code today and it works great. It nearly
> fixed that one buig you reported Vojtech with seeing AAA if you keep VT
> switching to the first VC. It still does it but much much less often. Give
> it a try.

Cool! I will. Now if you could also fix at least the MGAfb, it'd be
neat.

-- 
Vojtech Pavlik
SuSE Labs

VC switching code fixed :-)!!!!!!!!

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

Yeap. I rewrote the VT switching code today and it works great. It nearly
fixed that one buig you reported Vojtech with seeing AAA if you keep VT
switching to the first VC. It still does it but much much less often. Give
it a try.

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

fixes

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

Now it compiles against test2. I updated input to the new devfs protocol.
It has been tested and works fine. 

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

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

I just synced most of the tree with test2. The only files that need to be
updtaed are teh fbdev drivers now but I can leave them go for now as I
rewrite the console code first.

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

keyboard.c has been changed

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

Hi!

  Many more changes have been done. They have been test and work fine with
vgacon. I have moved struct kbd_struct kbd_table into vc_data. This means
keyboard.c doesn't need to initialize these structures. vte_ris does :-)
The VC switching behaves better but their still is problems. I'm going to
be working on it next. I made struct tty_struct *tty not global. This
should make the code more reenter. I still have some more work to do yet.
For single head systems it works fine. I haven't made it multihead aware
just yet. Give me a few more days :-)

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