linuxconsole-dev

input patch

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

Hello,

I made a patch for kernel 2.4.12 containing only the input part of
linuxconsole.
This patch is available at
http://www.docs.uu.se/~johannd/projects/ff/patch-2.4.12.bz2

The goal is to allow users to use the input drivers, which are quite
stable, without forcing them to use the totality of the linuxconsole
project (which still needs some work before being usable by end-users).

James, if you want to put this patch in the download area, please do so.

I am a bit late, as the current version of the linux kernel is 2.4.14, but
having a patch that actually includes all needed files, but no more, was
not especially easy.

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.

Feel free to try this file, and tell me if something goes wrong. This
serie of patches has been available for quite a long time now, and I
discovered only recently that it was hardly usable for anyone but me.

-- 
Johann Deneux

Re: input patch

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

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

-- 
Johann Deneux

Re: input patch

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

Sorry. I have been busy writing patches for 2.5.X.

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

Nope. It is the opposite. The console layer depends on the input layer. 
Not the other way around. 

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

No. Both the framebuffer layer and the input layer can exist without a VT
console. Now the VT console does need a display system i.e framebuffer
console, vgacon etc and the input api system.

Re: input patch

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

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.

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

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