[9fans] A couple questions about /dev/draw and /dev/kbmap

[9fans] A couple questions about /dev/draw and /dev/kbmap

[Dave MacFarlane]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

Hi 9fans,

I have most of a working prototype of a Go Shiny driver for Plan9, but
there's a couple issues that I'd like to resolve and cleanup that I'd like
to do.

First, reads and writes to /dev/draw/n/data seem to fail if it's larger
than 65536 bytes. At 4 bytes per pixel, that's not very much (that means
the image you can read is 128x128, and the biggest you can write slightly
smaller with the overhead of the header for the write..) As a hack, I'm
splitting up the calls for rectangles larger than that when reading or
writing ('r' and 'y' messages from draw(3)) into 1 read/write per row. But
65536 bytes still seems pretty artificially low? Is there any other way
around it? I'm not even sure if it's Go, Plan9, or drawterm that's adding
this restriction..

Second, I'd like to improve the keyboard handling. Right now I'm just
assuming that reading 'a' off /dev/cons came from the a key, 'A' came from
shift-A, etc. I'd like to load /dev/kbmap and make a more intelligent guess
of "the first key code which matches this utf8 rune in the kbmap" but man
kbmap is only partially helpful. It says that column 1 is "a table number"
and column 2 is "a hardware specific scan code". I think it's safe to
assume that table 0 is the unmodified key, but other than that does anyone
have any pointers for how to go from "table number" to "modifiers which
that table represents" and "hardware specific scan code" to "USB HID Key
Code"?

- Dave

[-- Attachment #2: Type: text/html, Size: 1754 bytes --]

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[hiro]

draw rpcs are restricted in size. there are some places in plan9 code
that do what you do and only write some lines.
9p message are also limited in size by the iounit.
there's no way around it.
do you have a monitor that is more than 16384 pixel wide?

i don't understand anything about the second issue, sorry.

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[cinap_lenrek]

you wont have that limitation on devdraw on the local machine. but
over 9p, your reads and writes are limited by the iounit of the
channel over which 9p is transfered.

the reson for having a iounit is that you'r not the only one doing
stuff over the channel. you chunk stuff up in packets, so multiple
things can appear as simultanious even tho theres only one serial
channel. the bigger you make the packets, the bigger the latency
for concurrent packets wanting to be transmitted.

for the keyboard stuff. you cant do that with /dev/cons. drawterm
only gives you runes, but no kbmap (you'r probably seeing the cpu
servers kbmap, not the one in drawterm). in 9front [1,2], theres
/dev/kbd [3] which also gives you button states.

[1] http://9front.org/
[2] http://drawterm.9front.org/
[3] http://man.9front.org/8/kbdfs

--
cinap

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[Dave MacFarlane]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

In that case, is there any way to get the current max packet size that 9p
will allow for
a read or write, or to determine if you're drawing to a local machine or
not? I'm not seeing anything obvious under /dev or /env.

On Wed, May 4, 2016 at 10:45 PM, <cinap_lenrek@felloff.net> wrote:

> you wont have that limitation on devdraw on the local machine. but
> over 9p, your reads and writes are limited by the iounit of the
> channel over which 9p is transfered.
>
> the reson for having a iounit is that you'r not the only one doing
> stuff over the channel. you chunk stuff up in packets, so multiple
> things can appear as simultanious even tho theres only one serial
> channel. the bigger you make the packets, the bigger the latency
> for concurrent packets wanting to be transmitted.
>
> for the keyboard stuff. you cant do that with /dev/cons. drawterm
> only gives you runes, but no kbmap (you'r probably seeing the cpu
> servers kbmap, not the one in drawterm). in 9front [1,2], theres
> /dev/kbd [3] which also gives you button states.
>
> [1] http://9front.org/
> [2] http://drawterm.9front.org/
> [3] http://man.9front.org/8/kbdfs
>
> --
> cinap
>
>


--
- Dave

[-- Attachment #2: Type: text/html, Size: 1859 bytes --]

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[Aram Hăvărneanu]

You're asking the wrong questions.

-- 
Aram Hăvărneanu

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[cinap_lenrek]

> In that case, is there any way to get the current max packet size that 9p
> will allow for
> a read or write, or to determine if you're drawing to a local machine or
> not? I'm not seeing anything obvious under /dev or /env.

the iounit is negotiated before you mount with the Tversion/Rversion
message:

               size[4] Tversion tag[2] msize[4] version[s]
               size[4] Rversion tag[2] msize[4] version[s]

plan9 has the iounit syscall for retriving the negotiated value
for a particular file descriptor. (see iounit(2))

libdraw determines the iounit in initdraw() and sizes
its write buffer accordingly. uploading pixels into a image
will split the y/Y operation in multiple ones so they fit
into the buffer.

--
cinap

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On 5 May 2016 at 14:56, <cinap_lenrek@felloff.net> wrote:

> libdraw determines the iounit in initdraw() and sizes
> its write buffer accordingly. uploading pixels into a image
> will split the y/Y operation in multiple ones so they fit
> into the buffer.
>

Yes, and the data doesn't go through rio (unlike an older system), but to
/dev/draw, so in the local graphics
case the kernel is pulling the draw data directly from the client memory:
it doesn't go through 9p.
If /dev/draw is imported from a remote system, the local system will
generate the 9p, and the remote
will receive that, turn round and access its /dev/draw.

[-- Attachment #2: Type: text/html, Size: 1071 bytes --]

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

The beauty of it is the uniformity and not making any assumptions about the
specifics of what's underneath; notice starting rio inside a rio window.

http://herpolhode.com/rob/lec5.pdf

On Thu, May 5, 2016 at 6:12 AM Dave MacFarlane <driusan@gmail.com> wrote:

> In that case, is there any way to get the current max packet size that 9p
> will allow for
> a read or write, or to determine if you're drawing to a local machine or
> not? I'm not seeing anything obvious under /dev or /env.
>
> On Wed, May 4, 2016 at 10:45 PM, <cinap_lenrek@felloff.net> wrote:
>
>> you wont have that limitation on devdraw on the local machine. but
>> over 9p, your reads and writes are limited by the iounit of the
>> channel over which 9p is transfered.
>>
>> the reson for having a iounit is that you'r not the only one doing
>> stuff over the channel. you chunk stuff up in packets, so multiple
>> things can appear as simultanious even tho theres only one serial
>> channel. the bigger you make the packets, the bigger the latency
>> for concurrent packets wanting to be transmitted.
>>
>> for the keyboard stuff. you cant do that with /dev/cons. drawterm
>> only gives you runes, but no kbmap (you'r probably seeing the cpu
>> servers kbmap, not the one in drawterm). in 9front [1,2], theres
>> /dev/kbd [3] which also gives you button states.
>>
>> [1] http://9front.org/
>> [2] http://drawterm.9front.org/
>> [3] http://man.9front.org/8/kbdfs
>>
>> --
>> cinap
>>
>>
>
>
> --
> - Dave
>

[-- Attachment #2: Type: text/html, Size: 2476 bytes --]