Messages in this thread | | | Date | Thu, 25 Jun 1998 23:27:03 +0200 | From | Vojtech Pavlik <> | Subject | Re: 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
| |