> okay, this is part of my 0.3 proposal now:
>
> A B C D
> || |||||| |||||||||||||| ||
>
> these are four zones of 2, 6, 14, 2 bits.
> zone A is always the event type: relint, absint, bool, special.
> in relint and absint, the B is the index, and CD (C*4+D) is the new value
> or the movement.
> in bool, it's BC (B*16384+C) that is the index, and D that is the value.
> in special, it's not defined yet.
My opinion is that this is very nice, very clever, very space saving,
but not very useful. You have used 24 bits. It's a really little amount,
however, with 40 bits you would get rid of all the complexity,
and would not have to fear any future extension needs.
> no, this will be handled as the administrators and programmers wish. It
> will normally be operated on separate channels, but one is able to merge
> them, hence the device ID's.
I don't think it is needed to mix streams together. An applicacion
can always open more devices/sockets ...
> > From here, comes issues of two-or-more processes sharing the
> > same device (say, X and some other application sharing the
> > mouse). With this scheme, I don't see it as being possible...
> > am I missing something?
>
> Yes. If you want to share devices, you create a filter that will split
> output, similar to 'tee'.
This is a bad idea. For running another application, once you have your
/dev/keyboard already used, you would have to kill the running application,
install a 'tee', and re-run both.
Input devices *should* be shareable.
Have fun,
Vojtech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu