lkml.org 
[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.111 / U:1.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site