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 abou
> 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
Im my previous message, obviously:
s/queue/push/g
s/dequeue/pop/g
--
Thierry Laronde (Alceste)
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
On Fri, Mar 20, 2009 at 02:26:02PM +, 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
But I think we have those widgets.
For most (all?) cases.
El 20/03/2009, a las 15:33, rogpe...@gmail.com escribió:
2009/3/20 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
I think it's possible. We have different apps.
El 20/03/2009, a las 15:30, rogpe...@gmail.com escribió:
2009/3/20 Francisco J Ballesteros :
El 20/03/2009, a las 14:07, rogpe...@gmail.com escribió:
so you end up with a smart client or split application,
which lack the same easy composability t
2009/3/20 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 gener
2009/3/20 Francisco J Ballesteros :
> El 20/03/2009, a las 14:07, rogpe...@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 compo
2009/3/20 :
> On Fri, Mar 20, 2009 at 01:03:12PM +, 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
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, rogp
El 20/03/2009, a las 14:07, rogpe...@gmail.com escribió:
2009/3/20 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.
true, but that's something that's re
On Fri, Mar 20, 2009 at 01:03:12PM +, 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 applica
2009/3/20 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.
true, but that's something that's relatively easy for the user
to adjust to - most actions have an
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
> >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 ba
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 fin
On Fri Mar 20 07:40:30 EDT 2009, n...@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 s
uot; or "the user wants to run that".
> From: rogpe...@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 :
> > the ordering problem is mislea
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
2009/3/20 Charles Forsyth :
> 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 po
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
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 wrote:
> i think it is a mistake to rei
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 th
> struct InputEvent {
>intmsec;
>unsigned short type;
>unsigned short code;
>intvalue;
> };
I would use anonymous union to make it easy to differentiate between
mouse and keyboard variables, rather than blend them.
++L
On Fri Mar 20 03:58:26 EDT 2009, ja...@orcasystems.com wrote:
> I am also looking for advice on what people might like for the
> interface, right now I am using:
>
> struct InputEvent {
>intmsec;
>unsigned short type;
>unsigned short code;
>intvalue;
> };
I am also looking for advice on what people might like for the
interface, right now I am using:
struct InputEvent {
intmsec;
unsigned short type;
unsigned short code;
intvalue;
};
type, keyboard or mouse,
keyboard code, key down or key up
keyboard value, scancode
> 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
27 matches
Mail list logo
