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?

    > The method I'm proposing would only require generating 3 bytes
    > per event, much less than your 16 bytes...

    I have a whole format an artist and I designed in 1994 for a game. the
    program was made in QuickBASIC but the format was so full of bitfields
    that we should have considered rewriting everything in C at that point.

    > If we're safe to assume that 8 (2^3) devices of any one type is
    > sufficient, and that there will never be more than 32 (2^5) different
    > types of devices, then we can represent this information in 1 byte. We're
    > basically saying that each device/ID# is unique, allowing for a *total*
    > of 255 (2^8) possible devices (although no more than 8 in any category).
    > I think this is sufficient.

    this smells like major/minor numbers at a lower scale... 0.3 design
    decision: 4 bits each, and anyway it isn't *that* useful, because most
    streams will contain only stuff from *one* device anyway.

    > > 1 byte: describes the type of event happening:
    > > '0'== a boolean has been reset.
    > > '1'== a boolean has been set.
    > > '2'== a set boolean is auto-repeating.
    > > '@'== the absolute integer #0 has changed to...
    > > 'A'== the absolute integer #1 has changed to...
    > > 'Z'== the "" #26 ...
    > > '`'== the relative .. #0 .. has changed by...
    > > 'a'== the relative .. #1 ...
    > ... I'm not positive how many events are necessary, but I'd be
    > flustered if any *specific* I/O device generated more than 16 (2^4)
    > different classes of events. This means we can represent the
    > event as a 4-bit value. The way to determine event-type will be
    > device-type specific.

    restating my stuff in another way, three types of events are necessary,
    and here are pseudocode function signatures corresponding to them:

    abs_int_changed (index in range 0..255, newvalue of type short);
    rel_int_changed (index in range 0..255, movement of type short);
    bool_changed (index in range 0..255, newvalue in range 0..2);

    where the value 2 as the 2nd parameter of bool_changed means that it's an
    automatic repeat event coming from the keyboard.

    and let's add a 4th one just in case:

    special_stuff (whatever);

    unifying all of those signatures, this leaves us with 2 bits for the type
    of event. the rest is left to be determined.

    > I've replied to someone else as to why I think timestamping of events
    > is really silly. Eliminating this trims out a whole 8 bytes.

    it's now 6 bytes, and could drop to 4 bytes if i drop the long-term
    considerations (system latency shouldn't be higher than 65536 seconds or
    there is something really wrong...) so each event won't unnecessarily
    store years, months, weeks, and even days.

    > Since even the standard PC keyboard has 102 keys (and some have a few
    > more), I'd venture to say that no one device will have more than
    > 255 (2^8) "keys" or identifiable inputs. For items with absolute

    but : there are more than that Key Variations. There are, on a typical
    Sun Sparc-5 keyboard, over 15 keys with no equivalent on a PC: Help, Cut,
    Copy, Paste, Find, Open/Close, Stop, Front, Undo, Again, Props,
    Speaker[+], Speaker[-], Speaker[On/Off], Suspend. Add up all such
    variations and you're over 128 alot, maybe over 256.

    > positionings, I think -127..128 is a bit small of a range. Since the
    > we only used 4 bits for the event-type, lets make this 12 bits large,
    > which will give us a range of -4095..4096, which should be plenty.

    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.

    > Human readability is unnecessary overhead. If this needs to be human
    > readable, write a small program that interprets the data into a
    > human-readable format. With the right API written for other programs
    > to take advantage of this system, a short program to generate
    > user-friendly output should be trivial.

    that's taken in account at proposal 0.2, written yesterday. :-)

    > > i don't know what to do about portability of scancodes. how about a
    > > unicode-like system of keyboard scancodes? i bet it exists... i think
    > > i've seen something similar once...
    > This will probably be ugly. But, fear not, someone's probably already
    > done this.

    Well, I knew there was one: The xkb / Xserver is, to a certain point.

    > My one *BIG* problem with this system is the fact that you wanted
    > to make all the data come out of one system device - that's *ugly*!

    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.

    > only have 255 devices, we would only need 1 major number. Then,
    > applications could use devices through this generic system
    > interface...which would be really neat.

    > 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'.

    > Well, that's my bit to try and help out with your efforts =).
    > Good luck, and keep me posted!

    matju


    -
    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    [W:0.032 / U:1.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site