lkml.org 
[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: uniform input device packets?
On Thu, Jun 25, 1998 at 03:31:30PM +0300, Johan Myréen wrote:

> Hold on! Are you sure you know how big the can of worms you
> are opening is?
>
> Take mice with wheels, for example. The wheel typically needs
> to be enabled somehow. This is done by writing to the device.
> (The latest XFree86 does that). If you want to provide a
> generic interface to input devices, and get rid of the "raw"
> devices, you will also have to take things like this into
> account. Not to mention all the input devices that haven't
> even been invented yet. What happened to the "do as little as
> possible in the kernel" paradigm.

The paradigm is still there, it's just its understanding
that differs between me and you. I think, that the kernel
should do enough to make an abstraction of the actual
hardware interfaces, so that the apps don't have to care
whether this is a mouse with a wheel made my Microsoft, or
made by Logitech, serial, PS/2, or with a special card.

They shouldn't care whether it is a digital trackball
connected to a game port. (I'm writing a driver for that
right now, believe me, such things exist).

If we would only do minimal hardware support in the kernel,
and would only export completely raw devices, every
application would have to know about all these crazy
protocols in there. (And, many of these protocols are
possible to be handled in kernel only, to say the least).

So I think it is better to have this stuff in the kernel.

I'm also fed up with that I can use my PS/2 mouse device
only one time at once - either in X or in GPM. Yes, I can
set up GPM in a repeater mode, emulating another mouse, but
I think that this is really an ugly hack, passing the data
around between processes when this is not at all needed,
and could be handled with much more grace.

> Somehow, I get the feeling that things haven't been
> sufficiently thought out at a general level before diving into
> the little details like bit positions in protocols.

Myself I think I have quite a clear idea how to implement
the drivers, and why I need to have such a protocol. It's
the protocol itself I wasn't sure about, mostly because it's
the visible part of all this stuff, and thus has to be
defined once and for good, and thus should be defined well
on the first time. The inner workings of the implementation
can be changed later.

If you have any thoughts on why this effort is useless,
please tell me, I will gladly listen to them, think about
them, and tell you why I think they are wrong, or, if they
are right, stop my efforts (which I doubt ;).

> I'm also not sure of the benefits of this grand unified input
> protocol is. Is the current way of handling things that
> broken?

With /dev/kbdXX we could get rid of the console raw mode,
which only makes things problematic - imagine console mode
restoral troubles when a raw mode application crashes. It
would also solve a lot of console switching trouble with
applications forgetting shift/control/alt states and ceasing
to work.

We need /dev/jsXX without any more discussion, since
joysticks is a bunch of very different beasts, with every
manufacturer having a specific protocol, and sometimes
(Gravis) even not similar between models from the same
manufacturer. And, these protocols are very timing sensitive
and can't be handled in the applications.

We don't necessarily need /dev/mouseXX, but it will be
useful, getting us rid of the mouse repeating trouble,
because /dev/psaux can be opened only once (and other
non-serial mouse devices, too), and would allow both X
and selction (gpm) use the mouse at the same time in a
simple way. Also, new mice will only have to be added to one
place and will immediately work both in X, on console, and
possibly in other places (svgalib?) without need of
recompiling/updating all these.

> It won't make the installation process any easier,
> because you will still, for example, have to specify mouse
> protocol and keyboard layout.

Yes, you will. Because this can't be autodetected. This
thing can't be fixed by anything, and so this unified
interface can't fix it anyway.

The good thing is that you will only need to do this once.

> I also don't see the point in trying to bundle every single
> input device under the same interface. For example, do
> keyboards necessarily have to use the same protocol/interface
> as pointing devices?

No, it doesn't have to. But since the protocols would be
very similar anyway, why not to make them the same, when it
is really convenient? A mouse has buttons, and these are
very similar to keys. Why not to handle them in the same
way?

Vojtech

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans