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 li
> 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
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
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;
> };
> Congratulations!
>
> I'm glad to have been so totally wrong about our prospects.
While on the subject, I may be able to help with supervision, if
required. Should I submit any details? Where?
++L
> 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
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
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
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
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
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
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
There's a GSoC-specific google group for tossing ideas around in, and
later for student discussion and ongoing work. You're encouraged to
propose project ideas and whatnot there. join plan9-gsoc. If you
decide you want to mentor, specifically, contact me directly.
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
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
> >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
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
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
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
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 Thu, Mar 19, 2009 at 4:43 PM, erik quanstrom wrote:
>> so, here's a silghtly controversial (maybe) suggestion. Maybe my
>> memory is wrong, but i believe the vx32 kernel is gcc-compiled. There
>> is gcc for this CPU. It might be easier to start from the vx32 kernel
>> and gcc to target this mac
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
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
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 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
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
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
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
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
> Let me say it differently. The way in which the plan 9 kernel code was
> changed to be gcc-compilable as part of the vx32 kernel might provide
> some hints as to how to change a whole plan 9 kernel. The point being,
> it is not impossible to get a gcc-compilable plan 9 kernel. We used to
> talk a
> 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
On Fri, Mar 20, 2009 at 8:15 AM, erik quanstrom wrote:
> i'm really missing something. what executables does this
> kernel run? how are they generated?
one of us is. I'll let it drop here because it might be me.
ron
> wouldn't it just be easier to use 32-bit compatability mode
> (http://www.mips.com/products/processors/architectures/mips64/)
> for bootstrapping using vc?
Please don't go there! I have just ordered (and paid for) one of
those gadgets and foremost in my mind was the hope that I would not
have t
> i'm really missing something. what executables does this
> kernel run? how are they generated?
Executing ELFs is not the most difficult thing on earth, LinuxEmu does
it in its sleep. Moving the functionality into the kernel would be
trivial for anyone who does not insist in understanding the
On Fri Mar 20 11:34:28 EDT 2009, lu...@proxima.alt.za wrote:
> > wouldn't it just be easier to use 32-bit compatability mode
> > (http://www.mips.com/products/processors/architectures/mips64/)
> > for bootstrapping using vc?
>
> Please don't go there! I have just ordered (and paid for) one of
> t
ron is suggesting is that with minimal effort
the plan 9 kernel could be made to compile
using gcc instead of the standard plan 9 compilers.
he's right.
erik's point is that once you have a kernel up,
you still need to give it executables to run.
this either requires porting the standard compilers
This is the same patch that I applied to devdraw, just in the current
drawterm code base. kEventAppShown gets called when the application
comes out from being hidden/screen saver/etc. Without catching it and
passing it on, we get a blank white window until a resize or
fullscreen event occ
for the RISC processors, it should be relatively straightforward to do the
64-bit
variant of ?[acl], given an existing 32-bit one,
and i'd be surprised if the applications also didn't work immediately
since they run in 64-bit mode on amd64. (anyway, they required relatively little
work, and the co
On Fri, Mar 20, 2009 at 12:15 PM, erik quanstrom wrote:
> wouldn't it just be easier to use 32-bit compatability mode
> (http://www.mips.com/products/processors/architectures/mips64/)
> for bootstrapping using vc?
that's how i started playing.
iru
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
Is a mips-64 port a reasonable GSOC project? The person doing it could
not come in cold, but there is a starting point it seems.
In spite of my earlier suggestion, I have to agree with Russ. Gcc and
its utils are a daily headache for me, I'd rather just get a mips-64
compiler port first.
ron
On Fri, Mar 20, 2009 at 4:52 PM, James Tomaschke wrote:
> I would suggest the compiler as well, students are probably more familiar
> with compiler concepts and it will probably be easier to mentor. In the
> future, the porting work can be distributed over the community anyways.
Sorry, I was not
I would suggest the compiler as well, students are probably more
familiar with compiler concepts and it will probably be easier to
mentor. In the future, the porting work can be distributed over the
community anyways.
ron minnich wrote:
Is a mips-64 port a reasonable GSOC project? The person
2009/3/20 ron minnich :
> On Fri, Mar 20, 2009 at 4:52 PM, James Tomaschke
> wrote:
>> I would suggest the compiler as well, students are probably more familiar
>> with compiler concepts and it will probably be easier to mentor. In the
>> future, the porting work can be distributed over the comm
On Fri, Mar 20, 2009 at 6:57 PM, Charles Forsyth wrote:
> the kernel work is another matter; the essential 64-bit changes have been
> made,
But not released. Maybe the GSoC students can work telepathically on
it, that is a skill that will come handy in their future Plan 9
contributions.
uriel
45 matches
Mail list logo
