Re: [9fans] Raw Input Driver

Re: [9fans] Raw Input Driver

[Francisco J Ballesteros]

Yes, you split the application. UI
elements are kept at the terminal and
the application at the CPU server. The  input event generator knows  
what's
the input, but it runs at the terminal.
The only problem is to come up with a
widget abstract and generic enough.

El 20/03/2009, a las 14:07, rogpeppe@gmail.com escribió:

> 2009/3/20 Charles Forsyth <forsyth@terzarima.net>:
>> in the slow-network situation the thing you're responding to on the  
>> display
>> might not be accurate (eg, feedback delayed) which low-level input  
>> merging
>> won't address.
>
> true, but that's something that's relatively easy for the user
> to adjust to - most actions have an easily perceived visual
> result, and if that hasn't happened, i won't initiate my
> next action.
>
> in fact it's a problem with any slow-responding UI,
> which is where nemo's point about splitting things up
> at a higher level comes in. and that's what (in an extremely
> clunky way) the AJAX thing is all about too.
>
> the problem with choosing a higher level of abstraction is that
> the input event generators can't in general be agnostic about
> what the mouse/keyboard/whatever are operating on,
> so you end up with a smart client or split application,
> which lack the same easy composability that you get
> from plan 9's remote devices.
>
> [/mail/box/nemo/msgs/200903/36582]

Re: [9fans] Raw Input Driver

[roger peppe]

2009/3/20 Francisco J Ballesteros <nemo@lsub.org>:
> Yes, you split the application. UI
> elements are kept at the terminal and
> the application at the CPU server. The  input event generator knows what's
> the input, but it runs at the terminal.
> The only problem is to come up with a
> widget abstract and generic enough.

precisely.

Re: [9fans] Raw Input Driver

[lucio]

> The only problem is to come up with a
> widget abstract and generic enough.

That's because one can't resist generalisations.  Maybe one should be
looking for generalisations at a different level of abstractions.  Off
the cuff, if I could install sprites through a synthetic filesystem, I
may only need a channel in which to exchange commands and responses
with the sprites.  The sprites themselves can contain the semantics
appropriate to their functions.

Or one may create TK objects, then submit TK commands to them and
accept responses on a multiplexor/demultiplexor channel depending on
need.

I'm shooting from the hip, of course, but that would the direction I
would be heading in.

++L

Re: [9fans] Raw Input Driver

[Francisco J Ballesteros]

But I think we have those widgets.
For most (all?) cases.

El 20/03/2009, a las 15:33, rogpeppe@gmail.com escribió:

> 2009/3/20 Francisco J Ballesteros <nemo@lsub.org>:
>> Yes, you split the application. UI
>> elements are kept at the terminal and
>> the application at the CPU server. The  input event generator knows  
>> what's
>> the input, but it runs at the terminal.
>> The only problem is to come up with a
>> widget abstract and generic enough.
>
> precisely.
>
> [/mail/box/nemo/msgs/200903/36591]

Re: [9fans] Raw Input Driver

[Francisco J Ballesteros]

I think it's possible. We have different apps.

El 20/03/2009, a las 15:30, rogpeppe@gmail.com escribió:

> 2009/3/20 Francisco J Ballesteros <nemo@lsub.org>:
>> El 20/03/2009, a las 14:07, rogpeppe@gmail.com escribió:
>>> so you end up with a smart client or split application,
>>> which lack the same easy composability that you get
>>> from plan 9's remote devices.
>
> perhaps i should have written "generality and easy composability"
> there. i'm sure it's possible to make easily composable applications
> with other metaphors (octupus being one example) but is it
> possible to do so without making some strong assumptions
> about the user-interaction model of the application?
>
> [/mail/box/nemo/msgs/200903/36590]

Re: [9fans] Raw Input Driver

[Francisco J Ballesteros]

El 20/03/2009, a las 14:07, rogpeppe@gmail.com escribió:

> 2009/3/20 Charles Forsyth <forsyth@terzarima.net>:
>> in the slow-network situation the thing you're responding to on the  
>> display
>> might not be accurate (eg, feedback delayed) which low-level input  
>> merging
>> won't address.
>
> true, but that's something that's relatively easy for the user
> to adjust to - most actions have an easily perceived visual
> result, and if that hasn't happened, i won't initiate my
> next action.
>
> in fact it's a problem with any slow-responding UI,
> which is where nemo's point about splitting things up
> at a higher level comes in. and that's what (in an extremely
> clunky way) the AJAX thing is all about too.
>
> the problem with choosing a higher level of abstraction is that
> the input event generators can't in general be agnostic about
> what the mouse/keyboard/whatever are operating on,
> so you end up with a smart client or split application,
> which lack the same easy composability that you get
> from plan 9's remote devices.
>
> [/mail/box/nemo/msgs/200903/36582]

Re: [9fans] Raw Input Driver

[roger peppe]

2009/3/20 Francisco J Ballesteros <nemo@lsub.org>:
> El 20/03/2009, a las 14:07, rogpeppe@gmail.com escribió:
>> so you end up with a smart client or split application,
>> which lack the same easy composability that you get
>> from plan 9's remote devices.

perhaps i should have written "generality and easy composability"
there. i'm sure it's possible to make easily composable applications
with other metaphors (octupus being one example) but is it
possible to do so without making some strong assumptions
about the user-interaction model of the application?

[9fans] Raw Input Driver

[James Tomaschke]

Greetings all,

I have created a very simple input driver that interleaves keyboard and
mouse events for an "interactive" program I am working on.  I have tried
to keep it as simple as possible, just a single callback in pc/kbd.c and
port/devmouse.c.

The only goal I had was to capture keys like shift and press/release
events while keeping them in order with mouse events which is working great.

CONS(3) states:
If the string rawon has been written to the consctl file and file is
still open, cons is in rawmode.

Yet I have not had much luck here, the only way I have been able to
prevent echoing has been to use the event library einit(Ekeyboard). So I
have duplicated the code from libdraw/event.c yet it still does not
work.  Any ideas on what I am missing?

Regards,
/james

Re: [9fans] Raw Input Driver

[lucio]

> I have created a very simple input driver that interleaves keyboard and
> mouse events for an "interactive" program I am working on.  I have tried
> to keep it as simple as possible, just a single callback in pc/kbd.c and
> port/devmouse.c.

I've been thinking along the same lines, I'd like to see more
seamlessness between mouse and keyboard.

++L

Re: [9fans] Raw Input Driver

[James Tomaschke]

I am also looking for advice on what people might like for the
interface, right now I am using:

struct InputEvent {
   int            msec;
   unsigned short type;
   unsigned short code;
   int            value;
};

type, keyboard or mouse,
keyboard code, key down or key up
keyboard value, scancode
mouse code, buttons, dx or dy
mouse value, button bits, dx or dy values

lucio@proxima.alt.za wrote:
>> I have created a very simple input driver that interleaves keyboard and
>> mouse events for an "interactive" program I am working on.  I have tried
>> to keep it as simple as possible, just a single callback in pc/kbd.c and
>> port/devmouse.c.
>
> I've been thinking along the same lines, I'd like to see more
> seamlessness between mouse and keyboard.
>
> ++L
>
>
>

Re: [9fans] Raw Input Driver

[erik quanstrom]

On Fri Mar 20 03:58:26 EDT 2009, james@orcasystems.com wrote:
> I am also looking for advice on what people might like for the
> interface, right now I am using:
>
> struct InputEvent {
>    int            msec;
>    unsigned short type;
>    unsigned short code;
>    int            value;
> };

the old objections notwithstanding, i think this is a good idea.
one can easily emulate the old interface with a combined kbd/mouse
interface in libary with the added bonus that it's harder to get misordered
kbd/mouse events which can be a problem on lossy wireless networks
(don't you hate it when your acme clicks and types get out-of-wack?)
and the ability to see more of the kbd state.

if you want to do this, think it terms of a devce, say /dev/input.
most plan 9 devices of this type have a text interface.  see mouse(3).
this format could easily be extended so that mouse is as before
and keyboard events are presented as 'k ' char[11] ' '  scancode[11] ' '
msec[1 - 24].  one would imagine mod being a bit vector of
the normal mode keys encoding plus a bit for key press/release.
<mouse.h> already has a reasonable definition for mouse events.
by analogy,

	typedef struct Keyboard Keyboard;
	struct Keyboard {
		Rune	c;
		uint	sc;
		uvlong	msec;
	};

then

	typedef struct Input Input
	struct Input {
		int	type;	/* 'k' or 'm' */
		union{
			Keyboard
			Mouse
		};
	};

and finally

              typedef struct Inputctl Inputctl;
               struct Inputctl
               {
		Channel	*c;	/* chan(Input[20]) */

		char	*file;
		int	inputfd;	/* to input file */
		int	ctlfd;	/* to ctl file */
		int	pid;	/* of slave proc */
               };

i'm glossing over dealing with mouse vs keyboard control
events.

the work is building this into the kernel and rio.  i think
it would make sense for keyboard(2) and mouse(2) to
be emulated in terms of the new interface for syncronization
reasons.

once you've torn all that up, it will be a trivial undertaking to
get your shift release event. ☺

- erik

Re: [9fans] Raw Input Driver

[Charles Forsyth]

i think it is a mistake to reintroduce single even streams let alone `callbacks'.

it's easy enough to provide a device (say /dev/scancode) or a consctl mode
that gives you the raw keyboard codes. we used the former in inferno,
but the latter might be more logical since it's a different mode
of the same device.  either way, it worked fine in native inferno.
(i can't remember how much was in the hosted versions, but i thought there
was support for scan codes in windows and x11.)

the ordering problem is misleading: you need timely response for
interactive applications; it's a reasonably straightforward application
of real-time programming.  (by the way, if you're passing low-level
things like that across lossy wireless networks, you're possibly
not addressing the most relevant problem first.)  the effects you're trying to synchronise
are typically changes to data structures inside a program (including effects on the display),
so that's where the synchronisation and interlocking should be.

it's not as though the underlying devices
weren't separate streams; they are, and it makes sense for the view
of them to reflect that. it also makes it easier to add new input
devices. i see already you've got 'k' and 'm', with surprisingly different
content, but what about that fingerprint thingy to unlock the cheats? or perhaps more to the point the
'w' for wheel and 'p' for pedals? you'll never finish.

I include these for people that haven't seen them before:

http://swtch.com/~rsc/thread/cws.pdf
http://herpolhode.com/rob/lec5.pdf

Re: [9fans] Raw Input Driver

[Francisco J Ballesteros]

There's a kbdin device used by the usb keyboard driver
to feed scan codes (from usb) to the kernel keyboard
driver for processing.

If you are modifying kbd to read scan codes as well, this may
be relevant.


On Fri, Mar 20, 2009 at 12:05 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> i think it is a mistake to reintroduce single even streams let alone `callbacks'.
>
> it's easy enough to provide a device (say /dev/scancode) or a consctl mode
> that gives you the raw keyboard codes. we used the former in inferno,
> but the latter might be more logical since it's a different mode
> of the same device.  either way, it worked fine in native inferno.
> (i can't remember how much was in the hosted versions, but i thought there
> was support for scan codes in windows and x11.)
>
> the ordering problem is misleading: you need timely response for
> interactive applications; it's a reasonably straightforward application
> of real-time programming.  (by the way, if you're passing low-level
> things like that across lossy wireless networks, you're possibly
> not addressing the most relevant problem first.)  the effects you're trying to synchronise
> are typically changes to data structures inside a program (including effects on the display),
> so that's where the synchronisation and interlocking should be.
>
> it's not as though the underlying devices
> weren't separate streams; they are, and it makes sense for the view
> of them to reflect that. it also makes it easier to add new input
> devices. i see already you've got 'k' and 'm', with surprisingly different
> content, but what about that fingerprint thingy to unlock the cheats? or perhaps more to the point the
> 'w' for wheel and 'p' for pedals? you'll never finish.
>
> I include these for people that haven't seen them before:
>
> http://swtch.com/~rsc/thread/cws.pdf
> http://herpolhode.com/rob/lec5.pdf
>
>

Re: [9fans] Raw Input Driver

[cinap_lenrek]

Did a scancode driver to play zelda in zsnes running in linuxemu
using equis.

/n/sources/patch/devsc

Its in the same format as /dev/scancode from inferno running
in X11.

--
cinap

Re: [9fans] Raw Input Driver

[roger peppe]

2009/3/20 Charles Forsyth <forsyth@terzarima.net>:
> the ordering problem is misleading: you need timely response for
> interactive applications; it's a reasonably straightforward application
> of real-time programming.  (by the way, if you're passing low-level
> things like that across lossy wireless networks, you're possibly
> not addressing the most relevant problem first.)  the effects you're trying to synchronise
> are typically changes to data structures inside a program (including effects on the display),
> so that's where the synchronisation and interlocking should be.

does that mean we shouldn't do graphics over cpu over a slowish
connection? because as things stand, ordering can easily get
mucked up in that case, and in acme that leads to situations where typed text
you expect to go in one window actually goes into another.

i don't think there's a solution to this at the client side (key presses
don't arrive with timestamps, and even if they did, how long would we
wait?), so i can understand people thinking about a server-side
solution.

one possibility would be to have a server that did a general
"merge event files" operation, and have the importing client do the
de-multiplexing
operation - that way at least you'd get the same file interface.
but there's still no guarantee.

yes, the streams are separate at the originating source,
but they actually originate from the same
person, who has a pretty good idea of which event they generated
first. when that information can get lost in transit,
giving unexpected results, there's something wrong.

Re: [9fans] Raw Input Driver

[Fco. J. Ballesteros]

If connection is slow (as the one I'm using now) increasing the
abstraction level is a good thing to do. Merging low level input
streams may patch up things for a while, but won't be enough
if the connection is slower.

Separating the viewer form the application reduces coupling a
lot and makes kbd/mouse events a non issue. For example, in
the o/live I'm using to type this all of mouse/kbd/draw interaction
happens at the terminal. The editor, running at the cpu server,
gets only high-level events like "this was inserted" or "the user
is looking for this" or "the user wants to run that".



>  From: rogpeppe@gmail.com
>  To: 9fans@9fans.net
>  Reply-To: 9fans@9fans.net
>  Date: Fri Mar 20 12:31:54 CET 2009
>  Subject: Re: [9fans] Raw Input Driver
>
>  2009/3/20 Charles Forsyth <forsyth@terzarima.net>:
>  > the ordering problem is misleading: you need timely response for
>  > interactive applications; it's a reasonably straightforward application
>  > of real-time programming.  (by the way, if you're passing low-level
>  > things like that across lossy wireless networks, you're possibly
>  > not addressing the most relevant problem first.)  the effects you're trying to synchronise
>  > are typically changes to data structures inside a program (including effects on the display),
>  > so that's where the synchronisation and interlocking should be.
>
>  does that mean we shouldn't do graphics over cpu over a slowish
>  connection? because as things stand, ordering can easily get
>  mucked up in that case, and in acme that leads to situations where typed text
>  you expect to go in one window actually goes into another.
>
>  i don't think there's a solution to this at the client side (key presses
>  don't arrive with timestamps, and even if they did, how long would we
>  wait?), so i can understand people thinking about a server-side
>  solution.
>
>  one possibility would be to have a server that did a general
>  "merge event files" operation, and have the importing client do the
>  de-multiplexing
>  operation - that way at least you'd get the same file interface.
>  but there's still no guarantee.
>
>  yes, the streams are separate at the originating source,
>  but they actually originate from the same
>  person, who has a pretty good idea of which event they generated
>  first. when that information can get lost in transit,
>  giving unexpected results, there's something wrong.

Re: [9fans] Raw Input Driver

[erik quanstrom]

On Fri Mar 20 07:40:30 EDT 2009, nemo@lsub.org wrote:
> If connection is slow (as the one I'm using now) increasing the
> abstraction level is a good thing to do. Merging low level input
> streams may patch up things for a while, but won't be enough
> if the connection is slower.

i think it does solve the originally stated problem — keeping input
streams in sync, which is a problem for a local viewer if any input-handling
proc does potentially-blocking i/o.

john carmack mentioned this way back when:
	http://9fans.net/archive/1995/11/123

i suppose thinking of this as a real-time problem could make sense,
but simply keeping order would seem to me to be a useful subset of the whole
problem.

- erik

Re: [9fans] Raw Input Driver

[erik quanstrom]

this is mostly a repeat of what rog. said.  i'm a
slow thinker, but i'll subject y'all to what i was thinking
anyway....

> the ordering problem is misleading: you need timely response for
> interactive applications; it's a reasonably straightforward application
> of real-time programming.  (by the way, if you're passing low-level
> things like that across lossy wireless networks, you're possibly
> not addressing the most relevant problem first.)  the effects you're trying to synchronise
> are typically changes to data structures inside a program (including effects on the display),
> so that's where the synchronisation and interlocking should be.
>

that's fine.  but what acme does doesn't work.
i'm sure everyone here has typed something in
one acme window and had it appear in another.

almost always, the keyboard and mouse are connected
to the "same" hardware. and it's people realtime not real
realtime.  so it seems to me that this problem should not
exist.  and it seems to me that the problem is exactly that
the kbd and mouse are on seperate channels.

what i proposed will work when all the input devices are
connected to the "same" hardware.  a combo usb kb/mouse
or a standard pc kb and mouse would qualify. applications like
acme would not need any modification, though libraries would.

what do you propose?

> it's not as though the underlying devices
> weren't separate streams; they are, and it makes sense for the view
> of them to reflect that. it also makes it easier to add new input
> devices. i see already you've got 'k' and 'm', with surprisingly different
> content, but what about that fingerprint thingy to unlock the cheats? or perhaps more to the point the
> 'w' for wheel and 'p' for pedals? you'll never finish.

you have this problem regardless of implementation strategy.
but this is mostly argued in the moot court as most such devices
act like either a keyboard or a mouse.

- erik

Re: [9fans] Raw Input Driver

[Charles Forsyth]

in the slow-network situation the thing you're responding to on the display
might not be accurate (eg, feedback delayed) which low-level input merging
won't address.

(actually, the only time i have trouble with acme is when the mouse positioning
is marginal and it slips. otherwise, no, i don't find things typed in a window
where i didn't intend them.)

>it's people realtime not real realtime.

the former is an example of the latter.
real-time is meeting deadlines. deadlines are always real, if you've got them.
there isn't a distinction based on speed (ie, 1 usec is "real", but 10ms is not).
any hard/soft distinction is typically based on whether the program can miss a deadline,
and the consequences.

Re: [9fans] Raw Input Driver

[erik quanstrom]

> >it's people realtime not real realtime.
>
> the former is an example of the latter.
> real-time is meeting deadlines. deadlines are always real, if you've got them.
> there isn't a distinction based on speed (ie, 1 usec is "real", but 10ms is not).
> any hard/soft distinction is typically based on whether the program can miss a deadline,
> and the consequences.

my point was that the consequences for occassional misses are just
a reduced perception of responsiveness.  for most applications, this
should be okay.  i would think it would be an undue burden to break
out the realtime tools for any program that has a ui.

(not related to my point, what about a time frame of 1 minute?
one day?)

- erik

Re: [9fans] Raw Input Driver

[roger peppe]

2009/3/20 Charles Forsyth <forsyth@terzarima.net>:
> in the slow-network situation the thing you're responding to on the display
> might not be accurate (eg, feedback delayed) which low-level input merging
> won't address.

true, but that's something that's relatively easy for the user
to adjust to - most actions have an easily perceived visual
result, and if that hasn't happened, i won't initiate my
next action.

in fact it's a problem with any slow-responding UI,
which is where nemo's point about splitting things up
at a higher level comes in. and that's what (in an extremely
clunky way) the AJAX thing is all about too.

the problem with choosing a higher level of abstraction is that
the input event generators can't in general be agnostic about
what the mouse/keyboard/whatever are operating on,
so you end up with a smart client or split application,
which lack the same easy composability that you get
from plan 9's remote devices.

Re: [9fans] Raw Input Driver

[tlaronde]

On Fri, Mar 20, 2009 at 01:03:12PM +0000, roger peppe wrote:
>
> the problem with choosing a higher level of abstraction is that
> the input event generators can't in general be agnostic about
> what the mouse/keyboard/whatever are operating on,
> so you end up with a smart client or split application,
> which lack the same easy composability that you get
> from plan 9's remote devices.

For my own stuff, having to rewrite the 2 dimensions user interface, I
have created a library running on the terminal that keeps the
definitions of the graphical elements drawn with an identifier (3
members) giving to the processing unit (remote) a mean to unambiguously
identifies the antecedent for processing.

This has a lot of advantages. The UI is just a _representation_ of the
data (and in fact of the commands by means of labels/buttons).

All the user wandering on the UI, including selecting things, is done on
the terminal.

Since identifying an element (vectorial elements for KerGIS vectorial
stuff; or cell for a grid etc.) is indeed identifying the representation
of the element, there is no acrobatics trying to convert the
transformation leading to the window, the 1, 2 or 3 pixels between the
hot spot of the pointer and the element (in a GIS, converting the
distance between pixels to a ground distance and searching the element
in ground coordinates), but instead, using the representation for what
it is, so searching the representation near 1, 2 or whatever pixel
tolerance the representation is near (indeed reducing the search to what
is displayed, including ability to mask), and then only sending back the
identifier for the real element to processing.

This fundamental split between the representation, i.e. the UI, and the
processing is the fundamental flaw of the X11 approach which has put the
articulation (the network) on the wrong place: in X11, all the UI
handling, except dispatching window events, is done on the processing
unit (the client in X11 terminology).
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Raw Input Driver

[roger peppe]

2009/3/20  <tlaronde@polynum.com>:
> On Fri, Mar 20, 2009 at 01:03:12PM +0000, roger peppe wrote:
> For my own stuff, having to rewrite the 2 dimensions user interface, I
> have created a library running on the terminal that keeps the
> definitions of the graphical elements drawn with an identifier (3
> members) giving to the processing unit (remote) a mean to unambiguously
> identifies the antecedent for processing.

that's fine for location-based events, e.g. from a mouse,
(well, fine for largely static UIs)
but still leaves unresolved the issue of how do deal with
events that are agnostic about their destination, such
as keyboard events. you can't decide which graphical
element a key press is destined for until you know the
mouse language of your application. acme has both click-to-type
and point-to-type - the client would need to know which one
to use, otherwise you still have exactly the same ordering
problem as before.

Re: [9fans] Raw Input Driver

[tlaronde]

On Fri, Mar 20, 2009 at 02:26:02PM +0000, roger peppe wrote:
>
> that's fine for location-based events, e.g. from a mouse,
> (well, fine for largely static UIs)
> but still leaves unresolved the issue of how do deal with
> events that are agnostic about their destination, such
> as keyboard events. you can't decide which graphical
> element a key press is destined for until you know the
> mouse language of your application. acme has both click-to-type
> and point-to-type - the client would need to know which one
> to use, otherwise you still have exactly the same ordering
> problem as before.

In my design, there is a "virtual machine" (?), a software processing
unit (?) on the terminal, stack based, so that when you are gathering
events on a window, whether pointer location-based, or button events
(location agnostic except for the window it is sent in), a task
"returns" and can sent a software button event to dequeue the previous
task on the stack that fires the processing. Or that can requeue an
action if the data is not finished.

For a kind of example, when drawing a line, you can just "point" a
vertex (corresponding ground coordinates will be computed from window
coordinates) or request to fasten on an element which means doing
supplementary processing. In this case, on the terminal, the elements
proposed for fastening are displayed and the user chooses. Only when the
element is chosen, a request back (a "store") is sent since the
representation of the elements is not homomorphe (i.e. due to scale, the
drawing of a n vertex element is not perhaps a n vertex line on screen,
so the mth vertex in the representation is generally not the mth vertex
in the antecedent).
The drawing task is dequeued and the processing fired. Only when, on the
processing unit, the new vertex is computed, a new task is queued to
continue drawing.

I may misunderstand the point both due to my lacks in english and to the
fact that I'm involved in my own implementation needs. But my software
system is so large and touches so many different types of data, and
needs to accomodate so many different types of UI, that I
don't understand how a, at least chunk by chunk, terminal problem can
not be terminal handled. At the moment, I have made improvements, and
modifications (mainly simplifications); there are times when one can not
avoid interrupting and sending to processing; but the principles hold.
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Raw Input Driver

[tlaronde]

Im my previous message, obviously:

s/queue/push/g
s/dequeue/pop/g
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Raw Input Driver

[maht]

>> or perhaps more to the point the
>> 'w' for wheel and 'p' for pedals? you'll never finish.
>>
My steering wheel combines 15 digital inputs (buttons) 3 analogue inputs
(2 pedals and the wheel itself). My joystick has 3 analogues (2 axes of
the stick + a throttle lever)

If one presumes that an int in the proposed InputEvent struct is enough
resolution for such things instead of a float, then one could just use a
for the type, distinguish between devices with code and the value in value.

This is pretty much how Windows does it. You have an input mapper for
your device and map which bit is which for DirectX. You can steer with
the pedals and control throttle with your wheel - which is fun, I can
tell you.

Re: [9fans] Raw Input Driver

[James Tomaschke]

Charles Forsyth wrote:

> it's not as though the underlying devices
> weren't separate streams; they are, and it makes sense for the view
> of them to reflect that. it also makes it easier to add new input
> devices. i see already you've got 'k' and 'm', with surprisingly different
> content, but what about that fingerprint thingy to unlock the cheats? or perhaps more to the point the
> 'w' for wheel and 'p' for pedals? you'll never finish.

I did have an implementation where the program could open the driver and
select which input stream they were interested in from an enumerated
list, if more than one stream is selected it will mux them (interrupt
events are simply discarded if not desired).

As far as 'k' 'm' 'w' 'p', better choice would be buttons/axis.  A three
button mouse with wheel would have 5 buttons and 2 axis.  This can keep
the complexity down in the driver.

Re: [9fans] Raw Input Driver

[lucio]

> struct InputEvent {
>    int            msec;
>    unsigned short type;
>    unsigned short code;
>    int            value;
> };

I would use anonymous union to make it easy to differentiate between
mouse and keyboard variables, rather than blend them.

++L