Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort

[Uriel]

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

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[Devon H. O'Dell]

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 community anyways.
>
> Sorry, I was not clear: I only meant a mips-64 compiler port.

I think so. Who wants to mentor? I'd be up for getting one of these
puppies if anybody wants to do it (though they are rather expensive
considering no US distributor... harrumph) and mentoring to some
degree, but I'm more likely to want to help out with (and probably a
better contact for) 9vx work than that.

--dho

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[James Tomaschke]

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 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

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[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 community anyways.

Sorry, I was not clear: I only meant a mips-64 compiler port.

rno

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[ron minnich]

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

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] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[Iruata Souza]

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

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort

[Charles Forsyth]

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 compiler can help, because only long long and pointers are 
64-bit, unlike gcc.)

the kernel work is another matter; the essential 64-bit changes have been made,
but you still need to adapt or change the 32-bit MIPS kernel implementation to 
suit,
and write drivers.  what does the device use for graphics?

i'm sure i've booted a 32-bit MIPS kernel on a potentially 64-bit MIPS 
processor.
set a bit or two and it works; i don't think there was much more than that.

[9fans] drawterm update to gui-osx/screen.c

[Jeff Sickel]

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 occurs.


-jas


[cpu:cmd/drawterm/gui-osx] jas% cvs diff .
? plan9bunny.icns
cvs diff: Diffing .
Index: screen.c
===
RCS file: /cvs/drawterm/gui-osx/screen.c,v
retrieving revision 1.12
diff -r1.12 screen.c
95,98d94
< // devRect.origin.x = 0;
< // devRect.origin.y = 0;
< // devRect.size.width = 1024;
< // devRect.size.height = 768;
115c111
< static OSStatus ApplicationQuitEventHandler(EventHandlerCallRef  
nextHandler, EventRef event, void *userData);

---
> static OSStatus ApplicationEventHandler(EventHandlerCallRef next,  
EventRef event, void *arg);

167c163,164
const EventTypeSpec app_events[] = {
>{ kEventClassApplication, kEventAppShown },
187,189c184,186
NewEventHandlerUPP 
(ApplicationEventHandler),
>
GetEventTypeCount(app_events),
>app_events,
341c338,339
< static OSStatus ApplicationQuitEventHandler(EventHandlerCallRef  
nextHandler, EventRef event, void *userData)

---
> // and other Application events
> static OSStatus ApplicationEventHandler(EventHandlerCallRef next,  
EventRef event, void *arg)

343,345c341,354
OSStatus result = noErr;
>switch(GetEventKind(event)){
>case kEventAppShown:;
>Rectangle r = Rect(0, 0, bounds.size.width, bounds.size.height);
>flushmemscreen(r);
>result = eventNotHandledErr;
>break;
>
>case kEventAppQuit:
>exit(0);
>// QuitApplicationEventLoop();
>}
>
>return result;

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[Russ Cox]

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
to the target machine or somehow making
the entire source tree compile under gcc,
which would require significantly more effort
than the kernel.  he's also right.

it all depends on what you want from plan 9.

for me, the fleet plan 9 compilers save me
so much time and make me so much more
productive compared to waiting on gcc that
on balance i'd rather spend the time to port
the compiler than switch to gcc.

ron is already using gcc to generate binaries
to run on plan 9, though, and his use of plan 9
depends much more heavily on the "plays well
with networks" aspect than it does on the
fast compilation.  and maybe there's no one
to write the new compiler.  there, using gcc might
make sense.

russ

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort

[erik quanstrom]

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
> those gadgets and foremost in my mind was the hope that I would not
> have to deal with a BIOS that needed emulation to be executed.

what leads you to believe that you need to call their open
bios, it doesn't deal with 32-bit mode, it can't be modified to
deal with 32-bit mode and mode switching is impracticable?
(or whatever the correct order is.)

- erik

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort

[lucio]

> 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 full ELF
specifications before doing it.

The details on where I'm at with this particular effort are available
off list for the asking.  I really don't mind having a shoulder to cry
on :-)

++L

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort

[lucio]

> 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 to deal with a BIOS that needed emulation to be executed.

That said, the claim is that it will be here in five days, but this is
Africa so I'll give it two weeks.  After that, anyone who wants to
hold my hand is welcome.  The timezone here is +0200 and my daytime
cycle (adjustable, of course) is 05:30 to 22:30, approximately.

++L

Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[ron minnich]

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

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] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[erik quanstrom]

> 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 about this at LANL all the time: we called it the "evil project".
> (This idea predates vx32 but it was not my idea; I will let the evil
> person behind the evil project identify himself). This change would
> remove "have to port&test&validate&fix&validate&... the C compiler
> first" as a barrier to entry on new CPUs.
> 
> see src/vx32 in the vx32 tree.

i'm really missing something.  what executables does this
kernel run?  how are they generated?

wouldn't it just be easier to use 32-bit compatability mode
(http://www.mips.com/products/processors/architectures/mips64/)
for bootstrapping using vc?

- erik

Re: [9fans] Raw Input Driver

[tlaronde]

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

Re: [9fans] Raw Input Driver

[tlaronde]

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. 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) 
 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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, 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  
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, 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 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

[roger peppe]

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 generic enough.

precisely.

Re: [9fans] Raw Input Driver

[roger peppe]

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 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?

Re: [9fans] Raw Input Driver

[roger peppe]

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 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

[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, 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 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] I can not remember if I sent this or not: MIPS-64 (sort of) notebook

[ron minnich]

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 machine, rather than do a 64-bit MIPS port of
>> the plan 9 C compiler. Or not: a few of the folks on this list could
>> probably retarget in very short order (I'm not one of the,however).
>
> vx32 relies on x86 segment registers.

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 about this at LANL all the time: we called it the "evil project".
(This idea predates vx32 but it was not my idea; I will let the evil
person behind the evil project identify himself). This change would
remove "have to port&test&validate&fix&validate&... the C compiler
first" as a barrier to entry on new CPUs.

see src/vx32 in the vx32 tree.

ron

Re: [9fans] Raw Input Driver

[Francisco J Ballesteros]

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 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

[tlaronde]

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 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) 
 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 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 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

[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

[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] GSoC 2009: Plan 9 is in!

[Anthony Sorace]

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.

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]

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 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

[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: 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 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]

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

[roger peppe]

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 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

[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

[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  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

[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] GSoC 2009: Plan 9 is in!

[lucio]

> 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

Re: [9fans] Raw Input Driver

[lucio]

> 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

Re: [9fans] Raw Input Driver

[erik quanstrom]

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;
> };

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.
 already has a reasonable definition for mouse events.
by analogy,

typedef struct Keyboard Keyboard;
struct Keyboard {
Runec;
uintsc;
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

[James Tomaschke]

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
mouse code, buttons, dx or dy
mouse value, button bits, dx or dy values

lu...@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

[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

[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