[9fans] kbdputc() in devcons.c in 9front?

[9fans] kbdputc() in devcons.c in 9front?

[kokamoto]

I'm checking how I should build my Plan9 system
in my home environment.   As I said before, we
have to save power as possible as we can (no
nuclear power energy here).   If I choose one
file/auth/cpu server machine, Plan9front may be
fastest.   However, I have here one serious problem.
Ktrans does not work on it.

You, 9front developpers, created kbdfs, and
lost kbdputc() in port/devcdons.c.   Most of
pc/kbd.c stuffs are driven out to user space, kbdfs.

In lab's or 9atom's distribution, I can have
/rc/bin/Kanji, like:
	#!/bin/rc

	pipefile -r ktrans /dev/cons
	rio -i $home/lib/windows </dev/cons

This assumes that the keyboard input from
stdin, and produces kanji translated character to
/dev/cons.

What is the merrit to create kbdfs?
I cann't see it, but only demerit like above.

Kenji

Re: [9fans] kbdputc() in devcons.c in 9front?

[cinap_lenrek]

the problem is that rio reads /dev/kbd instead of
/dev/cons which in addition provides key press
and release events. so translating /dev/cons has
no effect on rio. (rio reads and multiplexes
/dev/kbd file)

/dev/kbd is used by:

games/doom, games/nes, games/snes, games/md
and vnc.

changing ktrans to translate /dev/kbd format
instead of /dev/cons should not be hard. i can
do that when i get back from my day job.

kbdfs removes some code duplication like the
latin1 composing. vncs in 9front just runs another
instance of kbdfs to provide cons and kbd files
instead of reimplementing the kernels console code.

kbdfs also lets you interrupt programs on the
plan9 console.

--
cinap

Re: [9fans] kbdputc() in devcons.c in 9front?

[cinap_lenrek]

i havnt tried this, but as a quick work arround for rio,
you can make the /dev/kbd file unaccessible to rio with
aux/stub so rio will revert to reading /dev/cons:

aux/stub /dev/kbd
pipefile -r ktrans /dev/cons
rio -i $home/lib/windows </dev/cons

--
cinap

Re: [9fans] kbdputc() in devcons.c in 9front?

[Steve Simon]

> As I said before, we
> have to save power as possible as we can

I have a dual atom motherboard, a Supermicro X7SLA-H
which is rather old now, but it still works fine.
This is my cpu, auth, file, dns soa, and smtp/imap
server.

It has two mirrored enterprise grade 500Gb drives
from different manufacturers (the idea is one will
fail before the other). I plan to add an SSD to the
mirror to hopefully speed venti.

This draws about 23 watts.

I run fossil+venti from the labs at present.

I use an raspberry PI terminal (2 watts).

The worsed offender is my DELL HD resolution display
which draws 70 watts. currently the raspberry pi kernel
does not send the CEC sequence to shut down the display
when its idle (screen saver), but its on my list
of things to fix.

I use HDMI but believe if you attach the display via XVGA
the syncs disappear on idle and shutdown the display correctly
but I have not tried this.

I also have a "green" router/wifi basestation/ADSL modem which
draws 5 watts.

-Steve

Re: [9fans] kbdputc() in devcons.c in 9front?

[Steffen Nurpmeso]

kokamoto@hera.eonet.ne.jp wrote:
 |have to save power as possible as we can (no
 |nuclear power energy here).

No!!  That surely can be helped, enough willingness provided.

--steffen

Re: [9fans] kbdputc() in devcons.c in 9front?

[cinap_lenrek]

wheres the source code of the ktrans that you are
using?

i looked at /n/sources/extra/ktrans-2e.tgz but this
one would require the -t flag to work like you intended
in your mail:

	if (argc>1 && strcmp(argv[1], "-t")==0) {
		tflag = 1;
		in = 0;
		out = 1;
	} else {
		if ((in = open("/dev/kbd", OREAD)) < 0)
			exits("open /dev/kbd read");
		if ((out = open("/dev/kbd", OWRITE)) < 0)
			exits("open /dev/kbd/write");
		if (rfork(RFPROC))
			exits(0);
		atnotify(noter, 1);
	}

are you using a different ktrans than this? and if yes,
could you point me to the source?

--
cinap

Re: [9fans] kbdputc() in devcons.c in 9front?

[erik quanstrom]

On Thu Jul 17 04:03:49 EDT 2014, cinap_lenrek@felloff.net wrote:
> i havnt tried this, but as a quick work arround for rio,
> you can make the /dev/kbd file unaccessible to rio with
> aux/stub so rio will revert to reading /dev/cons:
>
> aux/stub /dev/kbd
> pipefile -r ktrans /dev/cons
> rio -i $home/lib/windows </dev/cons

silly idea.  fix the incompatability?  ;-)

- erik

Re: [9fans] kbdputc() in devcons.c in 9front?

[erik quanstrom]

> kbdfs removes some code duplication like the
> latin1 composing. vncs in 9front just runs another
> instance of kbdfs to provide cons and kbd files
> instead of reimplementing the kernels console code.

i found the major source of duplication was the n copies
of (different!) scan code tables in the various /sys/src/9/*/kbd.c
these differences appear to all be accidental.

consolidating them into port/devpckb.c which provides both /dev/kbin
and /dev/kbmap, and removing or reducing $arch/kbd.c to $arch/i8042.c
got a lot of the cleanup done without breaking interfaces.

it would be nice to get away from the annoying pc scan code interface,
but the cost is going to be compatability, and that cost seems too much
to me at this point.  the only way to do something like this imo would be
to agree and coordinate changes.

/dev/kbd seems reasonable if you've got that kind of problem. but
i don't see the benefit to using it where not formerly required,
but i do see a compatibility downside.

i also prefer having the keyboard in the kernel, since i do have kernels
with no user space.  norio(8) was written to deal with console interrupt
for a particular project.  think of it as rio with no graphics, and one
pre-defined window.   but i don't think it's a very good idea.  there are
better options.  (like rio.)

and yes, that's like, ya know, my opinion, man.  so like, whatever. :-)

- erik

Re: [9fans] kbdputc() in devcons.c in 9front?

[sl]

http://9front.org/img/9kbdfs01.png

Re: [9fans] kbdputc() in devcons.c in 9front?

[cinap_lenrek]

rio multiplexes /dev/kbd, so it opens it and derives the windows kbd
and cons files from it. it obviously has to read /dev/kbd to multiplex
it. now, the incompatibility is that opening /dev/kbd disables /dev/cons
input.

the reason is that /dev/cons is buffered but pressing keys on the keyboard
will result in characters being queued to /dev/cons. /dev/kbd reading programs
should *not* require a dummy reader proc to flush duplicated console input in
addition to reading /dev/kbd. you open /dev/kbd and the keyboard is yours.

it is also harder to filter or translate multiple asynchronously read
file stremas instead of just one. and filtering /dev/kbd is not much
differnet from filtering /dev/cons. in addition, you have keyboard
chords.

--
cinap

Re: [9fans] kbdputc() in devcons.c in 9front?

[kokamoto]

> wheres the source code of the ktrans that you are
> using?

It's not the one you checked.
I'll send it to you by private mail.  If I could have a
time I'll change it to be able to open everyone.
It was worked using my business time at office.
I'm now not a enpryee of that organization.

Kenji

Re: [9fans] kbdputc() in devcons.c in 9front?

[cinap_lenrek]

thanks!

--
cinap

Re: [9fans] kbdputc() in devcons.c in 9front?

[kokamoto]

> You, 9front developpers, created kbdfs, and
> lost kbdputc() in port/devcdons.c.   Most of
> pc/kbd.c stuffs are driven out to user space, kbdfs.
>
> In lab's or 9atom's distribution, I can have
> /rc/bin/Kanji, like:
> 	#!/bin/rc
>
> 	pipefile -r ktrans /dev/cons
> 	rio -i $home/lib/windows </dev/cons
>
> This assumes that the keyboard input from
> stdin, and produces kanji translated character to
> /dev/cons.

This is solved by cinap to write a new program, pipekbd
which works like pipefile for 9front's kbdfs.

Now I can use Japanese on Plan9fron, too.
Thanks cinap!

Kenji