linuxconsole-dev

Re: fbvid.h feature request

[Nick K. <nic...@ma...>]

Hello, Romain!

On Sun, 13 Jan 2002 20:08:32 +0100 you wrote:

> > I'm sorry to trouble you.
> 
> No trouble, it's just that Real Life sometimes interfere :-/
> 
> > Currently I've found that I can't continue development of my driver for
> > Linux kernel. Since after applying color correction algorithm it became
> > violate rule: "No float in the kernel" :( So I've dropped it into
> > userspace.
> 
> You couldn't have used fixed-point arithmetic instead of FP ? Should
> have enough precision for imaging, and wouldn't cause problem...
> 
It was one from many solutions. But I'm not expert of fixed-point arithmetic.
Also there were requests for portability and I decide to implement something
what was called VIDIX (Video acceleration is wanted on every system).
> -- 
> DOLBEAU Romain               | We'll know for the first time
> ENS Cachan / Ker Lann        |     If we're evil or divine
> Thesard IRISA / CAPS         |          -- Dio,
> dol...@cl...    |             'The Last In Line'
> 


Best regards! Nick

Re: [linux-usb-devel] [PATCH] Add some PID stuff and fix HID debug prettyprinting

[Johann D. <jo...@Do...>]

On Wed, 16 Jan 2002, Bj|rn Augustsson wrote:

> > How far have you got ? Have you managed to make your joystick move yet ?
> > Please also have a look at the input/event API. It would be nice if it was
> > the one used to download effects to the device.
> 
> No, I haven't, but I'm close. (I think!)

Great !

> 
> OK, longish status update time:
> 
> [...]
> 
> There's a few policy type things to consider. There's an Usage called
> PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if
> you hold the joystick or not (and if you let go, it turns the forces
> off). Since the existing HID-input "parser" reports every one-bit input
> usage as a button, this gets reported that way (except it's inverted, if
> you let go of the stick, it goes 0 -> 1). 
> 
> It's not really a button, but it could be useful to a game anyway. You
> could bind pause to it for example, or something. Do I report it to the
> API as a button, or do I add a new bit about this somewhere?

I guess by the name BTN_DEAD (0x12f) could be used for that, but as I
said, that's only a guess.


-- 
Johann Deneux

Re: [linux-usb-devel] [PATCH] Add some PID stuff and fix HID debug prettyprinting

[Bj|rn A. <d3a...@dt...>]

Quoting Johann Deneux <jo...@Do...>:
> [cc to the linuxconsole list]
> (Bj|rn is currently working on support for force feedback for microsoft
> joysticks, and sent a patch to the usb-devel ML concerning the debugging
> system of the hid driver)
> 
> On Wed, 16 Jan 2002, Bj|rn Augustsson wrote:
> 
> > Nope, 1.8 is what I've got here.
> > 
> > I'll certainly look into that. Thanks for the heads up!
> > 
> > I have quite a lot more written, but there's still some bugs and stuff
> > that I haven't implemented yet, so I split this part out.
> 
> How far have you got ? Have you managed to make your joystick move yet ?
> Please also have a look at the input/event API. It would be nice if it was
> the one used to download effects to the device.

No, I haven't, but I'm close. (I think!)

OK, longish status update time:

I am using the event API. The joystick now reports almost all of it's 
features to the event stuff, but actually writing stuff to the it 
doesn't work yet.  I haven't started on uploading effects, but I thought
I had the "set device gain" thing working last night, but I ran into 
problems where this happens:

Jan 16 03:49:06 localhost kernel: Setting device gain to 127, span = 255
Jan 16 03:49:06 localhost kernel: hid-debug: input PhysicalInterfaceDevice.Device_Gain = 127
Jan 16 03:49:06 localhost kernel: hid-core.c: ctrl urb status -32 received

-32 is EPIPE, and I'll have to look into why that happens a bit later today.

The joystick actually seems to be a proper PID device, so that's what
I'm aiming for, and trying not to hard-code anything MS-FF2-specific in
there.

There's a few policy type things to consider. There's an Usage called
PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if
you hold the joystick or not (and if you let go, it turns the forces
off). Since the existing HID-input "parser" reports every one-bit input
usage as a button, this gets reported that way (except it's inverted, if
you let go of the stick, it goes 0 -> 1). 

It's not really a button, but it could be useful to a game anyway. You
could bind pause to it for example, or something. Do I report it to the
API as a button, or do I add a new bit about this somewhere?

Also, HID devices (can) have physical units bound to them, as in "This
axis measues rotation, +- 30 degrees, 8bit resolution." There is no way
for an app to get this information thru the input API, and it should
probably be added at some point. It's not critical for game controllers,
but other apps might want that information.

(But as I said, I'll have to look at the current hid code, as I've been
working against what's in 2.4.18pre3. Maybe things have changed.)

/August.
-- 
Wrong on most accounts.  const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo.  const Foo const *foo; would mean the same but is
illegal (double const).  You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system

Re: [linux-usb-devel] [PATCH] Add some PID stuff and fix HID debug prettyprinting

[Johann D. <jo...@Do...>]

[cc to the linuxconsole list]
(Bj|rn is currently working on support for force feedback for microsoft
joysticks, and sent a patch to the usb-devel ML concerning the debugging
system of the hid driver)

On Wed, 16 Jan 2002, Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
> > On Tue, 15 Jan 2002, Bj|rn Augustsson wrote:
> > 
> > > Hi!
> > > 
> > > Here's a small patch against 2.4.18pre3 that
> > > 
> > >[...] 
> > 
> > I do not have the sources of this version, but it seems that the 2.4.17
> > kernel included revision 1.8 of hid-core.c. The most up-to-date release
> > can be found in the linuxconsole cvs. The revision here is 1.35 !
> > Unless patches went into 2.4.18pre3, it means you may be working on files
> > that are 7 months old. Luckily, your changes are new, and I guess it could
> > be interesting to include them anyway.
> 
> Nope, 1.8 is what I've got here.
> 
> I'll certainly look into that. Thanks for the heads up!
> 
> I have quite a lot more written, but there's still some bugs and stuff
> that I haven't implemented yet, so I split this part out.

How far have you got ? Have you managed to make your joystick move yet ?
Please also have a look at the input/event API. It would be nice if it was
the one used to download effects to the device.

-- 
Johann Deneux

Re: fbvid.h feature request

[<dol...@cl...>]

> I'm sorry to trouble you.

No trouble, it's just that Real Life sometimes interfere :-/

> Currently I've found that I can't continue development of my driver for
> Linux kernel. Since after applying color correction algorithm it became
> violate rule: "No float in the kernel" :( So I've dropped it into
> userspace.

You couldn't have used fixed-point arithmetic instead of FP ? Should
have enough precision for imaging, and wouldn't cause problem...

-- 
DOLBEAU Romain               | We'll know for the first time
ENS Cachan / Ker Lann        |     If we're evil or divine
Thesard IRISA / CAPS         |          -- Dio,
dol...@cl...    |             'The Last In Line'

Re: fbvid.h feature request

[Nick K. <nic...@ma...>]

Hello, Romain!

On Sun, 13 Jan 2002 19:14:05 +0100 you wrote:

> Sorry for the late answer, been busy...
> 
I'm sorry to trouble you.
Currently I've found that I can't continue development of my driver for
Linux kernel.
Since after applying color correction algorithm it became violate rule:
"No float in the kernel" :(
So I've dropped it into userspace.

I've designed new technology - VIDIX (VIDeo Interface for *niX)
which is portable (Linux, *BDS, Solaris; Intel, Sun, DecAlpha),
much faster of X11 and uses mathematics library.
I've found a lot of fellow campaigner which currently develop new drivers
for VIDIX.

So if someone interested with it - please visit: mplayerhq.hu (CVS tree)

> > Gerd Knorr (from vid...@re...) said that ruby tree will be
> > included into Linux-2.5.x.
> 
> The tree will probably be integrated by incremental patch, not as a
> whole, and I suspect that the ioctl-oriented nature of fbvid.h will
> prevent it from being integrated in 2.5.x :-(
> 
> > In this connexion, I have some question and feature request:
> > Do you plan to expand possibility of subj?
> > I mean that existing interface lacks some possibility for fully featured
> > BES support:
> 
> [snip]
> 
> > After studying v4l2 project (http://www.thedirks.org/v4l2/videodev.txt)
> > I've found that it is more advanced against of fbvid.h. What about to add
> > some possibility into fbvid.h from this project and even more?
> 
> > I have some ideas also but what about above extensions?
> 
> Well, I'm no sure that fbvid != v4l2 :-)
> 
> fbvid is (was ?) mostly an in-house project to get overlay on the
> Permedia3, that was proposed to the community to start discussion on the
> subject of possible extension to a regular framebuffer. Your interest
> prove it was a good idea :-)
> 
> The name was probably not well-chosen... All you extensions look useful,
> but they mostly consist of adding better _video_ support to the
> framebuffer, where I only though at first of static overlay, that could
> have been used by video app to store their frames.
> 
> I didn't know v4l2 included a video _output_ API, I though that like
> regular v4l it was mostly video input. I didn't look thoroughly, but if
> a regular framebuffer driver can be extended to become a v4l2 output
> device, it might be the best way - in particular if v4l2 has an API that
> is going to be integrated into 2.5.x. If this extension is not possible,
> it migth be worth contacting the v4l2 guys and see with them what is
> possible to do. Having the FB driver registering an output device should
> be possible, in particular with devfs ; James Simmons also intend to add
> a FB filesystem in 2.5.x I believe.
> 
> -- 
> DOLBEAU Romain               | The Gods made Heavy Metal
> ENS Cachan / Ker Lann        |     and it's never gonna die
> Thesard IRISA / CAPS         |           -- Manowar,
> dol...@cl...    |    'The Gods made Heavy Metal'
> 


Best regards! Nick

Re: fbvid.h feature request

[<dol...@cl...>]

Sorry for the late answer, been busy...

> Gerd Knorr (from vid...@re...) said that ruby tree will be
> included into Linux-2.5.x.

The tree will probably be integrated by incremental patch, not as a
whole, and I suspect that the ioctl-oriented nature of fbvid.h will
prevent it from being integrated in 2.5.x :-(

> In this connexion, I have some question and feature request:
> Do you plan to expand possibility of subj?
> I mean that existing interface lacks some possibility for fully featured
> BES support:

[snip]

> After studying v4l2 project (http://www.thedirks.org/v4l2/videodev.txt)
> I've found that it is more advanced against of fbvid.h. What about to add
> some possibility into fbvid.h from this project and even more?

> I have some ideas also but what about above extensions?

Well, I'm no sure that fbvid != v4l2 :-)

fbvid is (was ?) mostly an in-house project to get overlay on the
Permedia3, that was proposed to the community to start discussion on the
subject of possible extension to a regular framebuffer. Your interest
prove it was a good idea :-)

The name was probably not well-chosen... All you extensions look useful,
but they mostly consist of adding better _video_ support to the
framebuffer, where I only though at first of static overlay, that could
have been used by video app to store their frames.

I didn't know v4l2 included a video _output_ API, I though that like
regular v4l it was mostly video input. I didn't look thoroughly, but if
a regular framebuffer driver can be extended to become a v4l2 output
device, it might be the best way - in particular if v4l2 has an API that
is going to be integrated into 2.5.x. If this extension is not possible,
it migth be worth contacting the v4l2 guys and see with them what is
possible to do. Having the FB driver registering an output device should
be possible, in particular with devfs ; James Simmons also intend to add
a FB filesystem in 2.5.x I believe.

-- 
DOLBEAU Romain               | The Gods made Heavy Metal
ENS Cachan / Ker Lann        |     and it's never gonna die
Thesard IRISA / CAPS         |           -- Manowar,
dol...@cl...    |    'The Gods made Heavy Metal'

input patch for kernels 2.4.17

[Johann D. <jo...@Do...>]

Hi,

It seems I finally managed to make it. The patch is available at
http://www.docs.uu.se/~johannd/projects/ff/patch-2.4.17.bz2

It includes the input-related part of the ruby tree, without the console
stuff.
People using ps2 keyboards and/or mice must enable support for them in the
input section of the config panel. Indeed, the standard kernel code for
handling keyboards and ps2 mice is disabled by the patch.

This patch may not work for non-intel architectures. That's because I had
to do manipulations on pc_keyb.c to get it to work. Similar manipulations
may be needed for other architectures.

-- 
Johann Deneux

Re: input patch

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

On Sat, Jan 12, 2002 at 05:57:12PM +0100, Johann Deneux wrote:
> On Sun, 23 Dec 2001, Vojtech Pavlik wrote:
> 
> > On Sun, Nov 25, 2001 at 02:30:46PM +0100, Johann Deneux wrote:
> > > On Fri, 16 Nov 2001, Johann Deneux wrote:
> > > 
> > > > Hello,
> > > > 
> > > > About the directory hierarchy, I decided to keep linus' hierarchy. Not
> > > > that this is a better choice, but it first appeared to me being easier
> > > > (fewer changes to makefiles). However, I think I will try to move to the
> > > > linuxconsole hierarchy in the next version.
> > > 
> > > I have been trying to do that, and encountered a problem. Making this
> > > input patch makes sense provided the console and input stuff are
> > > separable. Is that the case ? Right now, it looks to me there is a strong
> > > depedency: the keyboard depends on the vt, which depends on the console,
> > > which depends on the frame buffer.
> > > At the end, my input patch may more or less include the whole ruby/linux
> > > tree !!!
> > 
> > The only way the input subsystem depends on the VT is through the
> > keyboard.c file. However, if you use keybdev.c instead, you can keep
> > what's in the normal kernels. It's a hack, though not too a gross one.
> > 
> 
> Hmm, do you mean keybdev.c replaces the standard keyboard.c ? From what I
> read in the input.txt file, and from what I've seen in keybdev.c,
> keybdev.c uses handle_scancode defined in keyboard.c.

No. It's just that in the ruby kernel, keyboard.c is modified to take
input from the input subsystem. If you want to keep your *normal*
keyboard.c, you need keybdev.c to feed keypresses into it.

> The problem is, keyboard.c seems to use functions from pckbd, namely
> pckbd_{set,get}keycode and others.
> That means I cannot use the ps2 keyboard+mouse stuff from ruby with my
> patch. This is ok for me, as the standard code works quite well, but it
> makes me wonder if the usb keyboard code will work.

Yes, it will. Also, if you hack pc_kbd.c a little to not register the
ports and the interrupt, it'll just not work and then you can use the
input stuff.

That way you can avoid using the console part of the ruby kernel
changes. 

> Can hid.o, keybdev.o (both from ruby),  keyboard.o and pc_keyb.o (from
> the standard kernel) all work together ?

Yep. That's what normally happens in standard kernels. There also is hid
and keybdev there.

-- 
Vojtech Pavlik
SuSE Labs

Re: input patch

[Johann D. <jo...@Do...>]

On Sun, 23 Dec 2001, Vojtech Pavlik wrote:

> On Sun, Nov 25, 2001 at 02:30:46PM +0100, Johann Deneux wrote:
> > On Fri, 16 Nov 2001, Johann Deneux wrote:
> > 
> > > Hello,
> > > 
> > > About the directory hierarchy, I decided to keep linus' hierarchy. Not
> > > that this is a better choice, but it first appeared to me being easier
> > > (fewer changes to makefiles). However, I think I will try to move to the
> > > linuxconsole hierarchy in the next version.
> > 
> > I have been trying to do that, and encountered a problem. Making this
> > input patch makes sense provided the console and input stuff are
> > separable. Is that the case ? Right now, it looks to me there is a strong
> > depedency: the keyboard depends on the vt, which depends on the console,
> > which depends on the frame buffer.
> > At the end, my input patch may more or less include the whole ruby/linux
> > tree !!!
> 
> The only way the input subsystem depends on the VT is through the
> keyboard.c file. However, if you use keybdev.c instead, you can keep
> what's in the normal kernels. It's a hack, though not too a gross one.
> 

Hmm, do you mean keybdev.c replaces the standard keyboard.c ? From what I
read in the input.txt file, and from what I've seen in keybdev.c,
keybdev.c uses handle_scancode defined in keyboard.c.

The problem is, keyboard.c seems to use functions from pckbd, namely
pckbd_{set,get}keycode and others.
That means I cannot use the ps2 keyboard+mouse stuff from ruby with my
patch. This is ok for me, as the standard code works quite well, but it
makes me wonder if the usb keyboard code will work.
Can hid.o, keybdev.o (both from ruby),  keyboard.o and pc_keyb.o (from
the standard kernel) all work together ?

-- 
Johann Deneux

input patch & arch/i386/kernel/dmi_scan.c

[Johann D. <jo...@Do...>]

I'have just started to build an input patch for kernel 2.4.17. Keyboard
handling on PCs is still bugging me, but nothing too difficult.

While going through files, I noticed that dmi_scan.c seems to lag
behind. It's still synchronized with kernel 2.4.13. Anyway, what was the
point of having this file in linuxconsole ?
My guess is that the function broken_ps2_resume calls a pckbd function,
which may well be missing when using the new input stuff.

Am I right ? Is that the only reason ?


-- 
Johann Deneux

new API and low level drivers

[jani <ja...@as...>]

Hi
is the new 2.5 API going to support both fbgen and non-fbgen based
approaches to low level driver writing as the current one in 2.4?
I find that confusing myself...
Thanks
Jani

fbvid.h feature request

[Nick K. <nic...@ma...>]

Hello!

Gerd Knorr (from vid...@re...) said that ruby tree will be included into Linux-2.5.x.
In this connexion, I have some question and feature request:
Do you plan to expand possibility of subj?
I mean that existing interface lacks some possibility for fully featured BES support:
/* switch the __u8 frame in multibuffer mode */
#define FBIOPUT_SELECT_FRAME _IOW('F',0xF4, __u8)

typedef struct fb_rect_s
{
   __u32	x;
   __u32	y;
   __u32	w;
   __u32	h;
   __u32	pitch;		/* bytes per line */
}fb_rect_t;

typedef struct fb_slice_s
{
   void*	address;		/* app -> driver */
   __u32	size;			/* app -> driver */
   fb_rect_t	slice;			/* app -> driver */
}fb_slice_t;

typedef struct fb_dma_s
{
   fb_slice_t	src;                    /* app -> driver */
   fb_slice_t	dest;			/* app -> driver */
#define FB_DMA_NOSYNC		0
#define FB_DMA_SYNC		1       /* means: wait vsync or hsync */
   __u32	flags;			/* app -> driver */
}fb_dma_t;

/* copies source frame to BES memory with using DMA */
#define FBIOPUT_COPY_FRAME _IOW('F',0xF5, fb_dma_t)

For this it would be correctly to add some capability:
FB_VIDOVERLAY_CAPABILITY_DMA /* means: can use dma */
FB_VIDOVERLAY_CAPABILITY_DMA_ANY_PITCH /* means: can use dma if src.pitch != dst.pitch */

After studying v4l2 project (http://www.thedirks.org/v4l2/videodev.txt) I've found that
it is more advanced against of fbvid.h. What about to add some possibility into fbvid.h
from this project and even more?
For example:
struct fb_vidoverlay_buf {
	unsigned long omem_start;       /* <- Start of overlay frame buffer mem (phys add) or 0 (failure) */
        __u32 omem_len;                 /* <- length of overlay frame buffer mem or 0 (failure) */
        __u32 xsize;                    /* <-> X size of buffer */
        __u32 ysize;                    /* <-> Y size of buffer */
	__u32 stride;                   /* <- line lenght in byte (can be longer than X*pixelsize due to hardware restriction */
	__u32 fourcc_id;                /* -> FOURCC that'll go in the buffer  */
	__u16 depth;                    /* -> depth that'll go in the buffer */
	__u8  n_buf;                    /* <-> number of the buffer to use (or -1 for any) */
};
I guess it would be better to add here also:

+struct fb_vidoverlay_yuv {
+	__u32 y;
+	__u32 u;
+ 	__u32 v;
+}
+
+#define MAX_FRAMES 32
 struct fb_vidoverlay_buf {
 	unsigned long omem_start;       /* <- Start of overlay frame buffer mem (phys add) or 0 (failure) */
        __u32 omem_len;                 /* <- length of overlay frame buffer mem or 0 (failure) */
        __u32 xsize;                    /* <-> X size of buffer */
        __u32 ysize;                    /* <-> Y size of buffer */
-	__u32 stride;                   /* <- line lenght in byte (can be longer than X*pixelsize due to hardware restriction */
+	struct fb_vidoverlay_yuv pitch;
	__u32 fourcc_id;                /* -> FOURCC that'll go in the buffer  */
	__u16 depth;                    /* -> depth that'll go in the buffer */
	__u8  n_buf;                    /* <-> number of the buffer to use (or -1 for any) */
+	struct fb_vidoverlay_yuv offset[MAX_FRAMES]; /* <- offsets of y,u,v planes for each frame from begin of BES memory */
 };
Lets driver tells to app which offsets of planes it wants to use for this fourcc.

What about to have configurable color correction?

typedef struct fb_video_eq_s
{
   int		brightness;	/* -1000 : +1000 */
   int		contrast;	/* -1000 : +1000 */
   int		saturation;	/* -1000 : +1000 */
   int		hue;		/* -1000 : +1000 */
   int		red_intense;	/* -1000 : +1000 */
   int		green_intense;  /* -1000 : +1000 */
   int		blue_intense;   /* -1000 : +1000 */
}fb_video_eq_t;

If driver/card don't support such feature it would be possible to notify about through
FB_VIDOVERLAY_CAPABILITY_COLOR_CORRECTION constant.

And what about HW support of DVD decoding?
As I found v4l extension already have some code for that.
And it could be extended too but fbvid != v4l althouhg BES and DVD are video multimedia extensions, imho.

I have some ideas also but what about above extensions?

Happy New Year!

Best regards! Nick

P.S.: Please CC me.

Re: dj tree.

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

On Mon, Dec 31, 2001 at 08:31:51AM -0800, James Simmons wrote:
> 
> > > agree to use the dj tree for our work. 
> > 
> > So the `dj' tree is something like the `ac' tree, but for 2.5.x?
> > That's OK for me (world domination ;-)
> 
> Yeap. Great. I have some more stuff to push today. We can soon start
> pushing input api changes to the dj tree as well. 

Glad to hear this.

-- 
Vojtech Pavlik
SuSE Labs

Re: dj tree.

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

> > agree to use the dj tree for our work. 
> 
> So the `dj' tree is something like the `ac' tree, but for 2.5.x?
> That's OK for me (world domination ;-)

Yeap. Great. I have some more stuff to push today. We can soon start
pushing input api changes to the dj tree as well. 

Re: dj tree.

[Geert U. <ge...@li...>]

On Sat, 29 Dec 2001, James Simmons wrote:
>    I talked to Dave Jones a little bit ago about accepting patches. As we
> know Linus has been busy with the block layer and hasn't been taking abny
> other patches. I like to see our work get a larger audience. So David has
> agreed to this. So Geert and Vojtech I like to push our work to the dj
> tree. Note the ruby tree will remain against the standard Linus tree but
> the dj tree will end up closer to the ruby tree. Eventually it will sync
> over to Linus tree. 
>    I already have sent patchs for the new fbdev api. The one you blessed
> Geert. I sent some of tty stuff as well. So I like to see everyone here
> agree to use the dj tree for our work. 

So the `dj' tree is something like the `ac' tree, but for 2.5.x?
That's OK for me (world domination ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

dj tree.

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

Hi folks!

   I talked to Dave Jones a little bit ago about accepting patches. As we
know Linus has been busy with the block layer and hasn't been taking abny
other patches. I like to see our work get a larger audience. So David has
agreed to this. So Geert and Vojtech I like to push our work to the dj
tree. Note the ruby tree will remain against the standard Linus tree but
the dj tree will end up closer to the ruby tree. Eventually it will sync
over to Linus tree. 
   I already have sent patchs for the new fbdev api. The one you blessed
Geert. I sent some of tty stuff as well. So I like to see everyone here
agree to use the dj tree for our work. 

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

[PATCH] added consoel field to struct tty_driver

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

   A have a new version of the console lock. The goal is to move
[acquire/release]_console_lock into the upper tty layers. This
way other TTY drivers besides the VT layer can take advanatge 
of it. Plus I like to make the lock per console device. Their is
no reason to block the serial console while say the frmaebuffer 
is drawing to the screen for a printk. 
   First I reworked my console lock thanks to Alan pointing out the
lp console issue. So now I have it handle 3 conditions:

1) Console by itself (i.e lp console). The console initializes the lock.

2) tty driver without a console. A lock in struct tty_driver is
   initialized. 

3) Hardware has both a console and a tty. Then the lock is shared between
   both struct tty_driver and struct console.  

This patch is pretty big so I had to break it up. The first patch below 
places a struct console field into struct tty_driver. Why? So code in
tty_io.c function tty_register_driver can test to see if a console is
associated with this tty device. If it is both structs point to the same
lock. Otherwise tty_register_driver will allocate a semaphore for us. 

This patch touches several serial drivers so if you have problems let me
know. I can update it. Please test since I like to include it in the
standard tree. 

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/arch/mips/au1000/common/serial.c linux/arch/mips/au1000/common/serial.c
--- linux-2.5.2-pre3/arch/mips/au1000/common/serial.c	Thu Dec 27 17:20:16 2001
+++ linux/arch/mips/au1000/common/serial.c	Thu Dec 27 19:11:30 2001
@@ -2606,7 +2606,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_AU1000_SERIAL_CONSOLE
+        serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_open;
 	serial_driver.close = rs_close;
 	serial_driver.write = rs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/arch/mips/baget/vacserial.c linux/arch/mips/baget/vacserial.c
--- linux-2.5.2-pre3/arch/mips/baget/vacserial.c	Thu Dec 27 17:20:16 2001
+++ linux/arch/mips/baget/vacserial.c	Thu Dec 27 19:10:11 2001
@@ -2373,7 +2373,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_open;
 	serial_driver.close = rs_close;
 	serial_driver.write = rs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/arch/ppc/8260_io/uart.c linux/arch/ppc/8260_io/uart.c
--- linux-2.5.2-pre3/arch/ppc/8260_io/uart.c	Thu Dec 27 20:48:03 2001
+++ linux/arch/ppc/8260_io/uart.c	Thu Dec 27 20:47:16 2001
@@ -2290,7 +2290,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_8xx_open;
 	serial_driver.close = rs_8xx_close;
 	serial_driver.write = rs_8xx_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/arch/ppc/8xx_io/uart.c linux/arch/ppc/8xx_io/uart.c
--- linux-2.5.2-pre3/arch/ppc/8xx_io/uart.c	Thu Dec 27 20:48:03 2001
+++ linux/arch/ppc/8xx_io/uart.c	Thu Dec 27 20:47:16 2001
@@ -2536,7 +2536,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+	serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_8xx_open;
 	serial_driver.close = rs_8xx_close;
 	serial_driver.write = rs_8xx_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/amiserial.c linux/drivers/char/amiserial.c
--- linux-2.5.2-pre3/drivers/char/amiserial.c	Wed Dec 26 10:41:48 2001
+++ linux/drivers/char/amiserial.c	Thu Dec 27 19:27:09 2001
@@ -2143,7 +2143,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_open;
 	serial_driver.close = rs_close;
 	serial_driver.write = rs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/console.c linux/drivers/char/console.c
--- linux-2.5.2-pre3/drivers/char/console.c	Thu Dec 27 17:20:21 2001
+++ linux/drivers/char/console.c	Thu Dec 27 19:30:56 2001
@@ -2459,7 +2459,9 @@
 	console_driver.table = console_table;
 	console_driver.termios = console_termios;
 	console_driver.termios_locked = console_termios_locked;
-
+#ifdef CONFIG_VT_CONSOLE
+	console_driver.console = &vt_console_driver;
+#endif
 	console_driver.open = con_open;
 	console_driver.close = con_close;
 	console_driver.write = con_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/dz.c linux/drivers/char/dz.c
--- linux-2.5.2-pre3/drivers/char/dz.c	Thu Dec 27 17:20:21 2001
+++ linux/drivers/char/dz.c	Thu Dec 27 19:27:21 2001
@@ -67,7 +67,7 @@
 extern int (*prom_printf) (char *,...);
 #endif
 
-
+struct console dz_sercons;
 
 #include "dz.h"
 
@@ -1353,7 +1353,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+	serial_driver.console = &dz_sercons;
+#endif
 	serial_driver.open = dz_open;
 	serial_driver.close = dz_close;
 	serial_driver.write = dz_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/keyboard.c linux/drivers/char/keyboard.c
--- linux-2.5.2-pre3/drivers/char/keyboard.c	Thu Dec 27 17:20:21 2001
+++ linux/drivers/char/keyboard.c	Thu Dec 27 19:45:10 2001
@@ -67,8 +67,6 @@
 
 extern void ctrl_alt_del(void);
 
-struct console;
-
 /*
  * global state includes the following, and various static variables
  * in this module: prev_scancode, shift_state, diacr, npadch, dead_key_next.
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/serial.c linux/drivers/char/serial.c
--- linux-2.5.2-pre3/drivers/char/serial.c	Thu Dec 27 17:20:21 2001
+++ linux/drivers/char/serial.c	Thu Dec 27 19:35:57 2001
@@ -5408,7 +5408,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+	serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_open;
 	serial_driver.close = rs_close;
 	serial_driver.write = rs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/serial167.c linux/drivers/char/serial167.c
--- linux-2.5.2-pre3/drivers/char/serial167.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/char/serial167.c	Thu Dec 27 19:41:19 2001
@@ -103,6 +103,7 @@
 DECLARE_TASK_QUEUE(tq_cyclades);
 
 struct tty_driver cy_serial_driver, cy_callout_driver;
+static struct console sercons;
 extern int serial_console;
 static struct cyclades_port *serial_console_info = NULL;
 static unsigned int serial_console_cflag = 0;
@@ -2409,6 +2410,7 @@
     cy_serial_driver.table = serial_table;
     cy_serial_driver.termios = serial_termios;
     cy_serial_driver.termios_locked = serial_termios_locked;
+    cy_serial_driver.console = &sercons;
     cy_serial_driver.open = cy_open;
     cy_serial_driver.close = cy_close;
     cy_serial_driver.write = cy_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/serial_21285.c linux/drivers/char/serial_21285.c
--- linux-2.5.2-pre3/drivers/char/serial_21285.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/char/serial_21285.c	Thu Dec 27 19:42:56 2001
@@ -45,6 +45,7 @@
 
 static struct termios *rs285_termios[1];
 static struct termios *rs285_termios_locked[1];
+static struct console rs285_cons;
 
 static char wbuf[1000], *putp = wbuf, *getp = wbuf, x_char;
 static struct tty_struct *rs285_tty;
@@ -312,7 +313,9 @@
 	rs285_driver.table = rs285_table;
 	rs285_driver.termios = rs285_termios;
 	rs285_driver.termios_locked = rs285_termios_locked;
-
+#ifdef CONFIG_SERIAL_21285_CONSOLE
+	rs285_driver.console = &rs285_cons;
+#endif
 	rs285_driver.open = rs285_open;
 	rs285_driver.close = rs285_close;
 	rs285_driver.write = rs285_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/serial_amba.c linux/drivers/char/serial_amba.c
--- linux-2.5.2-pre3/drivers/char/serial_amba.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/char/serial_amba.c	Thu Dec 27 19:37:50 2001
@@ -1789,7 +1789,9 @@
 	ambanormal_driver.table = ambauart_table;
 	ambanormal_driver.termios = ambauart_termios;
 	ambanormal_driver.termios_locked = ambauart_termios_locked;
-
+#ifdef CONFIG_SERIAL_AMBA_CONSOLE
+	ambanormal_driver.console = &ambauart_cons;
+#endif
 	ambanormal_driver.open = ambauart_open;
 	ambanormal_driver.close = ambauart_close;
 	ambanormal_driver.write = ambauart_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/serial_tx3912.c linux/drivers/char/serial_tx3912.c
--- linux-2.5.2-pre3/drivers/char/serial_tx3912.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/char/serial_tx3912.c	Thu Dec 27 19:29:37 2001
@@ -854,7 +854,9 @@
 	rs_driver.table = rs_table;
 	rs_driver.termios = rs_termios;
 	rs_driver.termios_locked = rs_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        rs_driver.console = &sercons;
+#endif
 	rs_driver.open	= rs_open;
 	rs_driver.close = gs_close;
 	rs_driver.write = gs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/sh-sci.c linux/drivers/char/sh-sci.c
--- linux-2.5.2-pre3/drivers/char/sh-sci.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/char/sh-sci.c	Thu Dec 27 19:28:43 2001
@@ -1040,7 +1040,9 @@
 	sci_driver.table = sci_table;
 	sci_driver.termios = sci_termios;
 	sci_driver.termios_locked = sci_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        sci_driver.console = &sercons;
+#endif
 	sci_driver.open	= sci_open;
 	sci_driver.close = gs_close;
 	sci_driver.write = gs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/char/vme_scc.c linux/drivers/char/vme_scc.c
--- linux-2.5.2-pre3/drivers/char/vme_scc.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/char/vme_scc.c	Thu Dec 27 19:33:24 2001
@@ -92,10 +92,10 @@
 static void scc_break_ctl(struct tty_struct *tty, int break_state);
 
 static struct tty_driver scc_driver, scc_callout_driver;
-
 static struct tty_struct *scc_table[2] = { NULL, };
 static struct termios * scc_termios[2];
 static struct termios * scc_termios_locked[2];
+static struct console sercons;
 struct scc_port scc_ports[2];
 
 int scc_refcount;
@@ -145,7 +145,9 @@
 	scc_driver.table = scc_table;
 	scc_driver.termios = scc_termios;
 	scc_driver.termios_locked = scc_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+	scc_driver.console = &sercons;
+#endif
 	scc_driver.open	= scc_open;
 	scc_driver.close = gs_close;
 	scc_driver.write = gs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/macintosh/macserial.c linux/drivers/macintosh/macserial.c
--- linux-2.5.2-pre3/drivers/macintosh/macserial.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/macintosh/macserial.c	Thu Dec 27 20:01:27 2001
@@ -2580,7 +2580,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+	serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_open;
 	serial_driver.close = rs_close;
 	serial_driver.write = rs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/s390/char/con3215.c linux/drivers/s390/char/con3215.c
--- linux-2.5.2-pre3/drivers/s390/char/con3215.c	Wed Dec 26 10:41:53 2001
+++ linux/drivers/s390/char/con3215.c	Thu Dec 27 19:54:14 2001
@@ -1145,7 +1145,9 @@
 	tty3215_driver.table = tty3215_table;
 	tty3215_driver.termios = tty3215_termios;
 	tty3215_driver.termios_locked = tty3215_termios_locked;
-
+#ifdef CONFIG_TN3215_CONSOLE
+	tty3215_driver.console = &con3215;
+#endif
 	tty3215_driver.open = tty3215_open;
 	tty3215_driver.close = tty3215_close;
 	tty3215_driver.write = tty3215_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/s390/char/tubtty.c linux/drivers/s390/char/tubtty.c
--- linux-2.5.2-pre3/drivers/s390/char/tubtty.c	Wed Dec 26 10:41:53 2001
+++ linux/drivers/s390/char/tubtty.c	Thu Dec 27 19:53:31 2001
@@ -53,6 +53,7 @@
 struct tty_struct *tty3270_table[TUBMAXMINS];
 struct termios *tty3270_termios[TUBMAXMINS];
 struct termios *tty3270_termios_locked[TUBMAXMINS];
+extern struct console tub3270_con;
 #ifdef CONFIG_TN3270_CONSOLE
 int con3270_major = -1;
 struct tty_driver con3270_driver;
@@ -94,7 +95,9 @@
 	td->table = tty3270_table;
 	td->termios = tty3270_termios;
 	td->termios_locked = tty3270_termios_locked;
-
+#ifdef CONFIG_TN3270_CONSOLE
+	td->console = &tub3270_con;
+#endif
 	td->open = tty3270_open;
 	td->close = tty3270_close;
 	td->write = tty3270_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/sbus/char/sab82532.c linux/drivers/sbus/char/sab82532.c
--- linux-2.5.2-pre3/drivers/sbus/char/sab82532.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/sbus/char/sab82532.c	Thu Dec 27 20:00:11 2001
@@ -2251,7 +2251,9 @@
 	serial_driver.table = sab82532_table;
 	serial_driver.termios = sab82532_termios;
 	serial_driver.termios_locked = sab82532_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+	serial_driver.console = &sab82532_console;
+#endif
 	serial_driver.open = sab82532_open;
 	serial_driver.close = sab82532_close;
 	serial_driver.write = sab82532_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/sbus/char/su.c linux/drivers/sbus/char/su.c
--- linux-2.5.2-pre3/drivers/sbus/char/su.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/sbus/char/su.c	Thu Dec 27 19:55:34 2001
@@ -2506,7 +2506,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+	serial_driver.console = &sercons;
+#endif
 	serial_driver.open = su_open;
 	serial_driver.close = su_close;
 	serial_driver.write = su_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/sbus/char/zs.c linux/drivers/sbus/char/zs.c
--- linux-2.5.2-pre3/drivers/sbus/char/zs.c	Thu Dec 27 17:20:22 2001
+++ linux/drivers/sbus/char/zs.c	Thu Dec 27 19:57:51 2001
@@ -2425,7 +2425,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        serial_driver.console = &zs_console;
+#endif
 	serial_driver.open = zs_open;
 	serial_driver.close = zs_close;
 	serial_driver.write = zs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/sgi/char/sgiserial.c linux/drivers/sgi/char/sgiserial.c
--- linux-2.5.2-pre3/drivers/sgi/char/sgiserial.c	Thu Dec 27 17:20:23 2001
+++ linux/drivers/sgi/char/sgiserial.c	Thu Dec 27 19:19:28 2001
@@ -98,6 +98,7 @@
 DECLARE_TASK_QUEUE(tq_serial);
 
 struct tty_driver serial_driver, callout_driver;
+struct console sgi_console_driver;
 struct console *sgisercon;
 static int serial_refcount;
 
@@ -1886,7 +1887,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        serial_driver.console = &sgi_console_driver;
+#endif
 	serial_driver.open = rs_open;
 	serial_driver.close = rs_close;
 	serial_driver.write = rs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/drivers/tc/zs.c linux/drivers/tc/zs.c
--- linux-2.5.2-pre3/drivers/tc/zs.c	Thu Dec 27 17:20:23 2001
+++ linux/drivers/tc/zs.c	Thu Dec 27 19:14:10 2001
@@ -1893,7 +1893,9 @@
 	serial_driver.table = serial_table;
 	serial_driver.termios = serial_termios;
 	serial_driver.termios_locked = serial_termios_locked;
-
+#ifdef CONFIG_SERIAL_CONSOLE
+        serial_driver.console = &sercons;
+#endif
 	serial_driver.open = rs_open;
 	serial_driver.close = rs_close;
 	serial_driver.write = rs_write;
diff -urN -X /home/jsimmons/dontdiff linux-2.5.2-pre3/include/linux/tty_driver.h linux/include/linux/tty_driver.h
--- linux-2.5.2-pre3/include/linux/tty_driver.h	Wed Dec 26 10:42:26 2001
+++ linux/include/linux/tty_driver.h	Thu Dec 27 20:10:25 2001
@@ -130,6 +130,7 @@
 	struct termios init_termios; /* Initial termios */
 	int	flags;		/* tty driver flags */
 	int	*refcount;	/* for loadable tty drivers */
+	struct console *console;/* console attached to this tty hardware */
 	struct proc_dir_entry *proc_entry; /* /proc fs entry */
 	struct tty_driver *other; /* only used for the PTY driver */
 

Re: HID stuff broken.

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

> Umm, I think I have just one keyboard. But at the time of the error
> message the keyboard probably wasn't connected, being USB and with my
> bad USB active extension cable, which needs to be unplugged and
> replugged after each boot to detect the devices on it.
> 
> So it's one-display-no-keyboard case. It works fine with 2.4.14-ruby.

Hm. This must be due to my VT creation changes. A tty is registered when
it detects a keyboard and their is a VT display with no keyboard attached. 

   I just realized their is the other issue I have to fix. That is the
/dev/console redirect thing. Right now this is really broken. For example
for the LP console their is no tty related to it. So if you attempt to
open /dev/console for a LP console it bombs. So I have been working on a
/dev/console that registers it own TTY that wraps aroung the struct
console functions. This will solve alot of problems.
   At present this affects the situation where you have no keyboard plugged 
in at boot time but after boot time you plug it in. Now the console stuff
can exist without a TTY. I reworked the code that way. Unfortunely the
other way around doesn't quite work yet. I'm working on the new /dev/console
TTY driver today. This way their will be no keyboard problems in the
future. /dev/console will be such that it doesn't matter if you have no
way to bring input in (i.e no keyboard). As for /dev/ttyX this will not be
the case.

Re: HID stuff broken.

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

On Thu, Dec 27, 2001 at 09:31:39AM -0800, James Simmons wrote:
> 
> > Done. The Input stuff (and namely HID/HIDBP) now compiles fine again on
> > 2.5.1. I tried to boot that kernel, and failed with 'unable to open the
> > initial console' message from I think the init process. I do have only
> > VGA console enabled (no fbcon ...).
> 
> You must have more than one keybaord attached but only one display.

Umm, I think I have just one keyboard. But at the time of the error
message the keyboard probably wasn't connected, being USB and with my
bad USB active extension cable, which needs to be unplugged and
replugged after each boot to detect the devices on it.

So it's one-display-no-keyboard case. It works fine with 2.4.14-ruby.

> I ran
> into this problem to. I will fix it today. The problem is the way a struct
> vt_struct is added to the link list versus how a keybaord is attached.
> When a new vt_struct is added to the link list it is placed int front of
> the link list. This means the last VT in the list is the first VT. Now
> when a keyboard is detected it scans the VT list from the head to the end. 
> That is why the no console error. I will work on the problem right now.
> 

-- 
Vojtech Pavlik
SuSE Labs

Re: HID stuff broken.

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

> Done. The Input stuff (and namely HID/HIDBP) now compiles fine again on
> 2.5.1. I tried to boot that kernel, and failed with 'unable to open the
> initial console' message from I think the init process. I do have only
> VGA console enabled (no fbcon ...).

You must have more than one keybaord attached but only one display. I ran
into this problem to. I will fix it today. The problem is the way a struct
vt_struct is added to the link list versus how a keybaord is attached.
When a new vt_struct is added to the link list it is placed int front of
the link list. This means the last VT in the list is the first VT. Now
when a keyboard is detected it scans the VT list from the head to the end. 
That is why the no console error. I will work on the problem right now.

Re: Serial design

[Russell K. - A. L. <li...@ar...>]

On Thu, Dec 27, 2001 at 09:22:11AM -0500, Andrew E. Mileski wrote:
> I agree, as serial devices tend not to be essential to booting as are
> most PCI ones.  Hence, most ISA PnP and PCMCIA/PC CARD are detected
> in user space ... though a kernel "helper" driver is not out of line
> should one be necessary.

Actually, all serial ports are detected by in-kernel code, apart from
PCMCIA, which uses cardmgr to bind the serial_cs driver with the card
(but serial_cs still works out where the serial ports are).

User space does get some say in the matter via setserial, but that is
currently only used as an admin tool.

Re: Serial design

[Andrew E. M. <an...@is...>]

Vojtech Pavlik wrote:
> 
> Actually almost any serial device can be identified quite well, but I
> don't think this should be done inside the kernel.

I agree, as serial devices tend not to be essential to booting as are
most PCI ones.  Hence, most ISA PnP and PCMCIA/PC CARD are detected
in user space ... though a kernel "helper" driver is not out of line
should one be necessary.

--
Andrew E. Mileski
Ottawa, Canada

Re: HID stuff broken.

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

On Thu, Dec 27, 2001 at 10:46:32AM +0100, Vojtech Pavlik wrote:

> On Wed, Dec 26, 2001 at 01:11:27PM -0800, James Simmons wrote:
> 
> > I just synced up to 2.5.1 and the USB layer has changed a lot.
> 
> Wonderful!
> 
> > So the HID stuff doesn't work at present. Could you fix it? 
> 
> Yes, of course. I'll try to do that today.

Done. The Input stuff (and namely HID/HIDBP) now compiles fine again on
2.5.1. I tried to boot that kernel, and failed with 'unable to open the
initial console' message from I think the init process. I do have only
VGA console enabled (no fbcon ...).

-- 
Vojtech Pavlik
SuSE Labs

Re: Serial design

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

On Thu, Dec 27, 2001 at 02:20:39AM -0500, Andrew E. Mileski wrote:

> > > >    The second class is using the bus like the PCI/PNP layer to find out
> > > > what got attached.
> > >
> > > This sounds a somewhat Microsofty solution.  Do we really want the kernel
> > > sending stuff like 'AT' commands at various baud rates to the connected
> > > machine, which might be waiting for you to "press any key" after changing
> > > the floppy?
> > 
> > I never said anything about sending AT commands.
> 
> Though I hate to point this out, there is a spec for a serial PnP protocol,
> It doesn't confuse modems or terminals, as it twiddles the RTS/CTS lines.

It confuses serial UPSes. Some of them switch the computer off during
the PnPCom evaluation. ;)

> Yes, Microsoft developed it.  Microsoft serial mice should supoort it.

Actually, they don't. They ignore the line twiddling and just send the
PnP string at powerup (when DTR comes up for long enough to provide
power to the mouse controller chip.)

Most later serial modems do support the PnPCom evaluation, though.

Actually almost any serial device can be identified quite well, but I
don't think this should be done inside the kernel.

-- 
Vojtech Pavlik
SuSE Labs