From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <a104dd0de7ac139f1036ce147b53ade6@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 20 Mar 2009 05:12:57 -0400
To: 9fans@9fans.net
In-Reply-To: <49C34C55.5070607@orcasystems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] Raw Input Driver
Topicbox-Message-UUID: bfd688cc-ead4-11e9-9d60-3106f5b1d025

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