lkml.org 
[lkml]   [2000]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you
On Mon, Aug 21, 2000 at 08:34:01PM -0700, Linus Torvalds wrote:

> I think it might be a good idea in a perfect world.
>
> However, it's really hard to make that concept do the right thing for
> serial mice, for example. Which in my opinion waters down the advantages
> of the input approach quit a lot.

Well, it depends on what you mean by 'the right thing'. I have an
in-kernel serial mouse driver, that easily handles all GPM-supported
serial mice (with a small daemon to do the autodetection / init /
userconfig / holding the devices open with an N_MOUSE ldisc), all in
about 290 lines of code. It uses the input interface, yes. It performs
better (updates/second) for some (all MSC, some Logitech) mice, though
not because of being in kernel.

I didn't submit it [yet], because the issue of whether serial mice
should be handled in the userland (GPM, and X, with sharing problems for
newer mice) or kernel was usually a cause of vast disagreement.

> Basically, because we cannot reasonably do a good job for serial mice,
> we'll always be in the situation that the X server needs to be able to
> handle different mice. Which in my opinion makes it redundant in the
> kernel: while I know that things like GPM etc use mouse devices directly,
> I'm personally convinced that in the bigger picture the only thing that
> really matters is X.

It's probably true, and it's also true X will very likely have all the
serial/ps2/busmouse/whatever mouse drivers always in it, if not for
Linux, then for other OSes, anyway.

> And X handles multiple input devices quite nicely, these days. That didn't
> use to be the case. So the advantage of having an input layer in the
> kernel is greatly diminished - and basically nonexistent if X still has to
> be able to do different mice.

Well, it still makes keyboard and joystick drivers much simpler.

> > There is a push on to make ADB keyboards and mice go through the input
> > layer in the PPC port, but no-one has explained to me what we would
> > gain from that.
>
> Quite frankly, I think that input to a large degree was a thing where the
> argument for it has gone away. I suspect the GGI people are the only ones
> who _really_ feel they have to have it.

Maybe. I personally never liked GGI much. In my opinion it was much too
complex for a simple (and impossible with the graphics part of it, too),
task.

Well, even the X people seemed to like the input layer. I've discussed
it with Jim Gettys for example and found out this is very similar to how
he wanted the things to be when X was born.

And game developers like it too, for example Sam Lantinga of Loki said
something like (quotation far from exact) 'it's much easier to write
input-related stuff in Linux than in Windows, I really enjoyed it'.

And distribution makers like it. Once fully implemented, it could remove
most of the huge 'select your mouse type and model' menus in the
installers, a point where most users are perpetually making the wrong
choice.

It's a level of abstraction that makes writing the low-level drivers
easier. Makes the drivers shorter, too. Application writing easier. I
believe that's good.

--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:37    [W:0.099 / U:7.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site