Skip to contentSkip to conversation

Helge Hafting vs. make menuconfig help

DISCUSSION Karel Kulhavý 4 participants 12 messages Jun 15, 2004 – Jun 16, 2004

lore
Share & tools
lore

Karel Kulhavý

author
#0 lore raw

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<

#1 lore raw

On Tue, 2004-06-15 14:02:06 +0000, Karel Kulhavý <[email protected]> wrote in message <[email protected]>:

Quoted 4 lines

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

Signature · 4 lines
   Jan-Benedict Glaw       [email protected]    . +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));
author
#2 lore raw
Quoted 7 lines · Jan-Benedict Glaw

On Tue, 2004-06-15 14:02:06 +0000, Karel Kulhavý <[email protected]> wrote in message <[email protected]>:

Quoted 4 lines

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.

Quoted 8 lines

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<

Quoted 8 lines

MfG, JBG

Signature · 4 lines
   Jan-Benedict Glaw       [email protected]    . +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));
#3 lore raw

On Tue, 2004-06-15 14:20:40 +0000, Karel Kulhavý <[email protected]> wrote in message <[email protected]>:

Quoted 11 lines · Jan-Benedict Glaw
Quoted 8 lines

On Tue, 2004-06-15 14:02:06 +0000, Karel Kulhavý <[email protected]> wrote in message <[email protected]>:

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

Signature · 4 lines
   Jan-Benedict Glaw       [email protected]    . +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));
author
#4 lore raw
Quoted 5 lines
Quoted 2 lines

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?

Quoted 6 lines

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<

Quoted 8 lines

MfG, JBG

Signature · 4 lines
   Jan-Benedict Glaw       [email protected]    . +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));
#5 lore raw

On Tue, 2004-06-15 17:21:29 +0000, Karel Kulhavý <[email protected]> wrote in message <[email protected]>:

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 10 lines
Quoted 6 lines

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

Signature · 4 lines
   Jan-Benedict Glaw       [email protected]    . +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));
author
#6 lore raw

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

Quoted 4 lines

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<

#7 lore raw

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

Quoted 5 lines · Karel Kulhavý
Quoted 4 lines

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.

Quoted 8 lines

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

author
#8 lore raw

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

Quoted 3 lines

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<

#9 lore raw

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

On Tue, 2004-06-15 19:59:03 +0000, Karel Kulhavý <[email protected]> wrote in message <[email protected]>:

Quoted 5 lines
Quoted 3 lines

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

Signature · 4 lines
   Jan-Benedict Glaw       [email protected]    . +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));
#10 lore raw

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

In reply to Karel Kulhavý
Quoted 7 lines · Karel Kulhavý
Quoted 3 lines

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

Quoted 2 lines

I get a feeling that it's where kernel writes it's debug messages but sometimes

Yes, the console is also used for this.

Quoted 3 lines

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.

Quoted 2 lines

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

#11 lore raw
In reply to Karel Kulhavý
Quoted 8 lines · 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.

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.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR