From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: Dave MacFarlane Date: Wed, 4 May 2016 16:20:00 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bd758cc001f5a053209f5ba Subject: [9fans] A couple questions about /dev/draw and /dev/kbmap Topicbox-Message-UUID: 8e687598-ead9-11e9-9d60-3106f5b1d025 --047d7bd758cc001f5a053209f5ba Content-Type: text/plain; charset=UTF-8 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 --047d7bd758cc001f5a053209f5ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi 9fans,

I have most of a working prot= otype 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&#= 39;s larger than 65536 bytes. At 4 bytes per pixel, that's not very muc= h (that means the image you can read is 128x128, and the biggest you can wr= ite 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 r= eading 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, Pla= n9, 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 mak= e a more intelligent guess of "the first key code which matches this u= tf8 rune in the kbmap" but man kbmap is only partially helpful. It say= s that column 1 is "a table number" and column 2 is "a hardw= are 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 fo= r how to go from "table number" to "modifiers which that tab= le represents" and "hardware specific scan code" to "US= B HID Key Code"?
=C2=A0
- Dave
--047d7bd758cc001f5a053209f5ba--