[-- 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 --]
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.
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
[-- 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 --]
You're asking the wrong questions. -- Aram Hăvărneanu
> 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
[-- 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 --]
[-- 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 --]