Messages in this thread | | | Date | Fri, 26 Jun 1998 01:37:27 -0400 | From | Allanah Myles <> | Subject | Re: uniform input device packets? |
| |
On 1998.06.24, Vojtech Pavlik <vojtech-lists@twilight.ucw.cz> wrote: > Yes. Myself I think we could leave out the devicetype field at all.
Correct - if we give each device a major/minor number, then only events of that device-type would be coming down the pipeline. We device type would be redundant.
> Actually, as far as I know there are only 5 types of events:
Fine, 4 bits should be plenty, then.
> Which could fit into 3 or 2 bits, however, there is no real need to > save every bit we can, we have also to think about usage simplicity > and efectiveness of the interface. I think we shouldn't be splitting > fields in less than byte size.
Is this an irrational fear of binary math? *grin*
> Timestamping isn't silly, as I explain in another reply to you. > It's actually very much needed.
Saving commenting on your reply and then commenting again here, I decided to save my response to your reply until now.
Timestamping for some devices may be necessary or practical, but not *all*. I personally can't imagine keyboard events requiring timestamping, although for mouse-on-keyboard emulation, I guess you *would* need timestamping to be able to reliably detect a "double-click". I was just concerned about the added overhead of getting the system time for *every* individual event, whereas if an application needs to know time differences, it can calculate those on it's own. It'll then have timestamping relative to when it receives/drains events from the device queue, rather than from when the system perceived that it received the event from the device itself. This way, the application can choose to incur the overhead, and not enforce it as policy across all devices. FWIW, I'm actually quite impartial about this - but I'm also a tweak-freak, so it *does* count. I believe device-handlers should be as lightweight as possible - leave it up to the application designer/developer to do things sub-optimally. =) This makes it possible for the people who want to really make their device I/O scream to do so.
> 12 bits is too small as well, imagine a high resolution tablet. It won't > do. 16 bits is much better, maybe 32 would be best.
What high-res tablet {needs more than/uses more than} 8192 distinct positions? Yes, this is a clear indication about my naivete about tablets and other input devices, but if your knowledge on the subject is more authoritative, one counterexample is sufficient for me. I just haven't heard of any to date. (Granted, the only experience I have with tablets is the Summasketch.)
> But without important functionality, and with extra effort encoding > and decoding the data into anf from bitfields.
This is silly. There's no "extra decoding" needed. You just perform binary AND operations or binary shift-left/shift-right operations to get the desired values, which, as far as I know, are Pretty Damn Fast(tm) on most architectures. Then again, I've been wrong before, and I'll be wrong again...
> > 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*! > > That means that *only* one application can read (and must read) > > *all* the input from all your devices in this system. That renders > > the whole concept useless. > > This isn't true at all. A device can be opened my many applications > at once. This is no problem.
Duh, I wasn't thinking. That's what I get for reading mail after working on bad code for hours on end...
> I agree with you, that forwarding all device events to all applications > that opened the device might be unnecessary overhead.
Clearly.
-Dossy
-- URL: http://www.panoptic.com/~dossy -< BORK BORK! >- E-MAIL: dossy@panoptic.com Now I'm who I want to be, where I want to be, doing what I've always said I would and yet I feel I haven't won at all... (Aug 9, 95: Goodbye, JG.) "You should change your .sig; not that the world revolves around me." -s. sadie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |