All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-kernel@vger.kernel.org
Subject: Re: Helge Hafting vs. make menuconfig help
Date: Tue, 15 Jun 2004 19:32:10 +0200	[thread overview]
Message-ID: <20040615173210.GM20632@lug-owl.de> (raw)
In-Reply-To: <20040615172129.F6843@beton.cybernet.src>

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

  reply	other threads:[~2004-06-15 17:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-15 14:02 Helge Hafting vs. make menuconfig help Karel Kulhavý
2004-06-15 14:10 ` Jan-Benedict Glaw
2004-06-15 14:20   ` Karel Kulhavý
2004-06-15 14:41     ` Jan-Benedict Glaw
2004-06-15 17:21       ` Karel Kulhavý
2004-06-15 17:32         ` Jan-Benedict Glaw [this message]
2004-06-15 17:46           ` AT Keyboard (was: Helge Hafting vs. make menuconfig help) Karel Kulhavý
2004-06-15 18:37             ` Helge Hafting
2004-06-15 19:59               ` Karel Kulhavý
2004-06-15 20:13                 ` Jan-Benedict Glaw
2004-06-16 22:30                 ` Helge Hafting
2004-06-15 20:35 ` Helge Hafting vs. make menuconfig help Vojtech Pavlik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040615173210.GM20632@lug-owl.de \
    --to=jbglaw@lug-owl.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.