Helge Hafting vs. make menuconfig help

Helge Hafting vs. make menuconfig help

[Karel Kulhavý]

Hello

Helge Hafting says that CONFIG_INPUT is about HID in general.
make menuconfig help in 2.4.25 says that CONFIG_INPUT is about USB HID only.

This is 1:1. I would like to know what the truth is. Please add your
opinions, I'll make a statistics and then evaluate the probable truth.
Thank you.

Cl<

Re: Helge Hafting vs. make menuconfig help

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Tue, 2004-06-15 14:02:06 +0000, Karel Kulhavý <clock@twibright.com>
wrote in message <20040615140206.A6153@beton.cybernet.src>:
> Hello
> 
> Helge Hafting says that CONFIG_INPUT is about HID in general.
> make menuconfig help in 2.4.25 says that CONFIG_INPUT is about USB HID only.

HID is used in conjunction of USB input devices (USB mice, USB
keyboards, ...).

CONFIG_INPUT only gives you an API where you can process input events
with. For instance, look at the atkbd.c, sunkbd.c or lkkbd.c drivers.
They all send key strokes into the Input API (activated by
CONFIG_INPUT), but none of them actually uses USB (but the PS/2 keyboard
port or normal serial ports with non-standard plugs).

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Helge Hafting vs. make menuconfig help

[Karel Kulhavý]

On Tue, Jun 15, 2004 at 04:10:39PM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2004-06-15 14:02:06 +0000, Karel Kulhavý <clock@twibright.com>
> wrote in message <20040615140206.A6153@beton.cybernet.src>:
> > Hello
> > 
> > Helge Hafting says that CONFIG_INPUT is about HID in general.
> > make menuconfig help in 2.4.25 says that CONFIG_INPUT is about USB HID only.
> 
> HID is used in conjunction of USB input devices (USB mice, USB
> keyboards, ...).
> 
> CONFIG_INPUT only gives you an API where you can process input events
> with. For instance, look at the atkbd.c, sunkbd.c or lkkbd.c drivers.
> They all send key strokes into the Input API (activated by
> CONFIG_INPUT), but none of them actually uses USB (but the PS/2 keyboard
> port or normal serial ports with non-standard plugs).

Is it correct what <Help> for CONFIG_INPUT in 2.4.25 says or no?

Cl<
> 
> MfG, JBG
> 
> -- 
>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
>     fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
>    ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Re: Helge Hafting vs. make menuconfig help

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

On Tue, 2004-06-15 14:20:40 +0000, Karel Kulhavý <clock@twibright.com>
wrote in message <20040615142040.B6241@beton.cybernet.src>:
> On Tue, Jun 15, 2004 at 04:10:39PM +0200, Jan-Benedict Glaw wrote:
> > On Tue, 2004-06-15 14:02:06 +0000, Karel Kulhavý <clock@twibright.com>
> > wrote in message <20040615140206.A6153@beton.cybernet.src>:

> > CONFIG_INPUT only gives you an API where you can process input events
> > with. For instance, look at the atkbd.c, sunkbd.c or lkkbd.c drivers.
> > They all send key strokes into the Input API (activated by
> > CONFIG_INPUT), but none of them actually uses USB (but the PS/2 keyboard
> > port or normal serial ports with non-standard plugs).
> 
> Is it correct what <Help> for CONFIG_INPUT in 2.4.25 says or no?

At least, it's not really wrong. You need CONFIG_INPUT to be able to do
something with the HID stuff. However, to have an uniform interface, you
may also use the CONFIG_INPUT stuff to access your "normal" (AT / PS/2
style) keyboard.

In 2.6.x, that's cleaned up a bit. (Nearly?) all keyboards now push
their key strokes into the CONFIG_INPUT API, so you really want to have
CONFIG_INPUT (as long as this isn't some kind of embedded system).

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Helge Hafting vs. make menuconfig help

[Karel Kulhavý]

> > 
> > Is it correct what <Help> for CONFIG_INPUT in 2.4.25 says or no?
> 
> At least, it's not really wrong. You need CONFIG_INPUT to be able to do
> something with the HID stuff. However, to have an uniform interface, you

Does HID means always USB?

However when disabling CONFIG_INPUT, the keyboard still works. Is a keyboard
considered a HID or nor?

> may also use the CONFIG_INPUT stuff to access your "normal" (AT / PS/2
> style) keyboard.
> 
> In 2.6.x, that's cleaned up a bit. (Nearly?) all keyboards now push
> their key strokes into the CONFIG_INPUT API, so you really want to have
> CONFIG_INPUT (as long as this isn't some kind of embedded system).

Isn't there some graphical chart (preferrably made in sodipodi ;-) ) that
describes how data are flowing inside the kernel? I have problems visualizing
this.

Cl<
> 
> MfG, JBG
> 
> -- 
>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
>     fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
>    ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Re: Helge Hafting vs. make menuconfig help

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]

On Tue, 2004-06-15 17:21:29 +0000, Karel Kulhavý <clock@twibright.com>
wrote in message <20040615172129.F6843@beton.cybernet.src>:
> > > 
> > > Is it correct what <Help> for CONFIG_INPUT in 2.4.25 says or no?
> > 
> > At least, it's not really wrong. You need CONFIG_INPUT to be able to do
> > something with the HID stuff. However, to have an uniform interface, you
> 
> Does HID means always USB?

No, but USB HID devices (mouse, keyboard, ...) always implies HID.

> However when disabling CONFIG_INPUT, the keyboard still works. Is a keyboard
> considered a HID or nor?

In 2.4.x, the transition from "old-style" input drivers to new-style
(Input API) was never finished. Instead, Input API was introduced, and
HID devices reported their input to Input API, while old drivers still
used all their old ways to deliver their input.

This is why a keyboard still works without CONFIG_INPUT in 2.4.x, but it
won't any longer work in 2.6.x, because the old path for submitting
input was thrown away.

> > may also use the CONFIG_INPUT stuff to access your "normal" (AT / PS/2
> > style) keyboard.
> > 
> > In 2.6.x, that's cleaned up a bit. (Nearly?) all keyboards now push
> > their key strokes into the CONFIG_INPUT API, so you really want to have
> > CONFIG_INPUT (as long as this isn't some kind of embedded system).
> 
> Isn't there some graphical chart (preferrably made in sodipodi ;-) ) that
> describes how data are flowing inside the kernel? I have problems visualizing
> this.

2.4.x:
	- USB keyboards/mice/... are "HID" devices, using the USB HID
	  protocol, delivering their data to the Input APU
	  (CONFIG_INPUT).
	- Legacy drivers (PS/2 keyboard and the like) had their own data
	  path and directly put their input into the virtual console
	  subsystem.

2.6.x:
	- USB keyboards/mice/... are "HID" devices, using the USB HID
	  protocol, delivering their data to the Input APU
	  (CONFIG_INPUT).
	- All legacy drivers are converted to also use the new Input API
	  subsystem; direct delivery of input was removed from the code
	  base.

So in 2.4.x, you've got two APIs for drivers to dispatch their input
(new drivers using the USB HID protocol already stuff their data into
Input API, old drivers still each use a direct way). In 2.6.x, the
direct ways were thrown away, and only the Input API is remaining.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

AT Keyboard (was: Helge Hafting vs. make menuconfig help)

[Karel Kulhavý]

> In 2.4.x, the transition from "old-style" input drivers to new-style
> (Input API) was never finished. Instead, Input API was introduced, and
> HID devices reported their input to Input API, while old drivers still
> used all their old ways to deliver their input.

I (hopefully correctly) assume that one of the old ones is AT keyboard.

What happens when I press a key on keyboard and the application that
has the keyboard somehow on it's stdin reads a key? What happens between
the two events and how does it travel inside the kernel?

I know how the keys can be read from port 0x60 or whichever.

Cl<

Re: AT Keyboard (was: Helge Hafting vs. make menuconfig help)

[Helge Hafting]

On Tue, Jun 15, 2004 at 05:46:51PM +0000, Karel Kulhavý wrote:
> > In 2.4.x, the transition from "old-style" input drivers to new-style
> > (Input API) was never finished. Instead, Input API was introduced, and
> > HID devices reported their input to Input API, while old drivers still
> > used all their old ways to deliver their input.
> 
> I (hopefully correctly) assume that one of the old ones is AT keyboard.
> 
> What happens when I press a key on keyboard and the application that
> has the keyboard somehow on it's stdin reads a key? What happens between
> the two events and how does it travel inside the kernel?
> 
> I know how the keys can be read from port 0x60 or whichever.
> 
1. You press the key (on an AT keyboard)
2. The keyboard hardware makes an interrupt
3. The interrupt acitvates the i8042 driver (in 2.6)
   which does the port 0x60 stuff.  
4. From there, the key is propagated through tty and
   console and ends up in your application.  This application
   might be X, which passes the key onto some program using X.

Helge Hafting
 

Re: AT Keyboard (was: Helge Hafting vs. make menuconfig help)

[Karel Kulhavý]

> 4. From there, the key is propagated through tty and
>    console and ends up in your application.  This application
>    might be X, which passes the key onto some program using X.

I am insterested in the 4. itself.

What's the console? I get a feeling that it's where kernel writes it's debug
messages but sometimes else I get a feeling it's the text output of the
machine at all.

And what are the ttys? And does the key go first into console and then tty,
or the other way?

Cl<

Re: AT Keyboard (was: Helge Hafting vs. make menuconfig help)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Tue, 2004-06-15 19:59:03 +0000, Karel Kulhavý <clock@twibright.com>
wrote in message <20040615195903.A7813@beton.cybernet.src>:
> > 4. From there, the key is propagated through tty and
> >    console and ends up in your application.  This application
> >    might be X, which passes the key onto some program using X.
> 
> I am insterested in the 4. itself.

This is from memory, some details may be wrong:

	- The keyboard driver first determines what key the scancodes
	  belong to. If you press one single key, it may be sent as
	  multiple scancodes. The keyboard driver first has to assemble
	  these scancodes and make a decision from it (like "Key 'a'
	  pressed"). This information ('a' pressed down). is put into
	  Input API.
	- Input API then prepares hands this key press to the TTY
	  driver.
	- An application on the currently visible VT gets the 'a' (if it
	  didn't request raw scancodes. In this case, the TTY layer
	  *emulates* scancodes from the "'a' pressed down" event), and
	  the 'a' is also displayed on the VT (if echo'ing is switched
	  on).

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: AT Keyboard (was: Helge Hafting vs. make menuconfig help)

[Helge Hafting]

On Tue, Jun 15, 2004 at 07:59:03PM +0000, Karel Kulhavý wrote:
> > 4. From there, the key is propagated through tty and
> >    console and ends up in your application.  This application
> >    might be X, which passes the key onto some program using X.
> 
> I am insterested in the 4. itself.
> 
> What's the console?
The console is the text interface you see when not running 
X (the graphical user interface).
 
> I get a feeling that it's where kernel writes it's debug
> messages but sometimes 
Yes, the console is also used for this.

> else I get a feeling it's the text output of the
> machine at all.
> 
You can also have text output in an xterm, thats not the console.
Or even on real terminals connected to serial ports.

> And what are the ttys? And does the key go first into console and then tty,
> or the other way?

TTY = TeleTYpe interface.  The machine may have quite a few different
text interfaces, one of them is special and is the console.

Helge Hafting

Re: Helge Hafting vs. make menuconfig help

[Vojtech Pavlik]

On Tue, Jun 15, 2004 at 02:02:06PM +0000, Karel Kulhavý wrote:
> Hello
> 
> Helge Hafting says that CONFIG_INPUT is about HID in general.
> make menuconfig help in 2.4.25 says that CONFIG_INPUT is about USB HID only.
> 
> This is 1:1. I would like to know what the truth is. Please add your
> opinions, I'll make a statistics and then evaluate the probable truth.
> Thank you.

Both are right. In 2.6, CONFIG_INPUT is used for all Human Input
Devices. In 2.4, though, only USB drivers use it. Get out of ancient
times, and look at 2.6 - it makes much more sense.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR