9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] A couple questions about /dev/draw and /dev/kbmap
@ 2016-05-04 20:20 Dave MacFarlane
  2016-05-04 21:53 ` hiro
  2016-05-05  2:45 ` cinap_lenrek
  0 siblings, 2 replies; 8+ messages in thread
From: Dave MacFarlane @ 2016-05-04 20:20 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] A couple questions about /dev/draw and /dev/kbmap
  2016-05-04 20:20 [9fans] A couple questions about /dev/draw and /dev/kbmap Dave MacFarlane
@ 2016-05-04 21:53 ` hiro
  2016-05-05  2:45 ` cinap_lenrek
  1 sibling, 0 replies; 8+ messages in thread
From: hiro @ 2016-05-04 21:53 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] A couple questions about /dev/draw and /dev/kbmap
  2016-05-04 20:20 [9fans] A couple questions about /dev/draw and /dev/kbmap Dave MacFarlane
  2016-05-04 21:53 ` hiro
@ 2016-05-05  2:45 ` cinap_lenrek
  2016-05-05 13:12   ` Dave MacFarlane
  1 sibling, 1 reply; 8+ messages in thread
From: cinap_lenrek @ 2016-05-05  2:45 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] A couple questions about /dev/draw and /dev/kbmap
  2016-05-05  2:45 ` cinap_lenrek
@ 2016-05-05 13:12   ` Dave MacFarlane
  2016-05-05 13:16     ` Aram Hăvărneanu
                       ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Dave MacFarlane @ 2016-05-05 13:12 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] A couple questions about /dev/draw and /dev/kbmap
  2016-05-05 13:12   ` Dave MacFarlane
@ 2016-05-05 13:16     ` Aram Hăvărneanu
  2016-05-05 13:56     ` cinap_lenrek
  2016-05-05 15:38     ` Skip Tavakkolian
  2 siblings, 0 replies; 8+ messages in thread
From: Aram Hăvărneanu @ 2016-05-05 13:16 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

You're asking the wrong questions.

-- 
Aram Hăvărneanu



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] A couple questions about /dev/draw and /dev/kbmap
  2016-05-05 13:12   ` Dave MacFarlane
  2016-05-05 13:16     ` Aram Hăvărneanu
@ 2016-05-05 13:56     ` cinap_lenrek
  2016-05-05 16:00       ` Charles Forsyth
  2016-05-05 15:38     ` Skip Tavakkolian
  2 siblings, 1 reply; 8+ messages in thread
From: cinap_lenrek @ 2016-05-05 13:56 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] A couple questions about /dev/draw and /dev/kbmap
  2016-05-05 13:12   ` Dave MacFarlane
  2016-05-05 13:16     ` Aram Hăvărneanu
  2016-05-05 13:56     ` cinap_lenrek
@ 2016-05-05 15:38     ` Skip Tavakkolian
  2 siblings, 0 replies; 8+ messages in thread
From: Skip Tavakkolian @ 2016-05-05 15:38 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] A couple questions about /dev/draw and /dev/kbmap
  2016-05-05 13:56     ` cinap_lenrek
@ 2016-05-05 16:00       ` Charles Forsyth
  0 siblings, 0 replies; 8+ messages in thread
From: Charles Forsyth @ 2016-05-05 16:00 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2016-05-05 16:00 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-04 20:20 [9fans] A couple questions about /dev/draw and /dev/kbmap Dave MacFarlane
2016-05-04 21:53 ` hiro
2016-05-05  2:45 ` cinap_lenrek
2016-05-05 13:12   ` Dave MacFarlane
2016-05-05 13:16     ` Aram Hăvărneanu
2016-05-05 13:56     ` cinap_lenrek
2016-05-05 16:00       ` Charles Forsyth
2016-05-05 15:38     ` Skip Tavakkolian

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).