From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 28 May 2016 20:04:37 +0200 Message-ID: From: hiro <23hiro@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] More about /dev/draw Topicbox-Message-UUID: 94fc4448-ead9-11e9-9d60-3106f5b1d025 it's easier to just get a thinkpad that's listed on http://fqa.9front.org/fqa3.html On 5/28/16, Dave MacFarlane wrote: > That's exactly what I'm doing. I don't have a monitor with HDMI within > network-cable and power-cable reach to hook it up to, and the last time I > hooked it up to my TV my toddler tore the usb/power cable of the Pi in two, > so I can only try debugging it when he's not around.. > > (And Go 1.6 or later for Plan9, but 1.7 or later for ARM, for the record..) > > On Sat, May 28, 2016 at 1:34 PM, Skip Tavakkolian < > skip.tavakkolian@gmail.com> wrote: > >> a quick and easy way to get a local Plan 9 terminal is to use 9Pi (Plan 9 >> on Raspberry Pi). with Go 1.6 and later you can cross compile for >> plan9/arm. >> >> >> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane >> wrote: >> >>> Either I'm going insane, the default Plan 9 /dev/draw in-memory >>> implementation >>> doesn't implement draw(3), or possibly both. >>> >>> When I do the following, it works as expected under both drawterm and a >>> locally mounted instance: >>> 1. Allocate a screen with an 'A' message >>> 2. Allocate an image on the screen of the same size as /dev/wctl with a >>> 'b' message >>> 3. Draw the image over the window with a 'd' message >>> 4. Flush the buffer with 'v' >>> >>> When I do the following, it works under drawterm, but not with a local >>> /dev/draw implementation: >>> Steps 1-2 above >>> 3. Allocate another image of some arbitrary fill colour with 'b' (with >>> or >>> without the repl bit) >>> 4a. (Optional, doesn't seem to make a difference) set the compositing >>> operator with 'O' >>> 4b. Draw the new image over a portion of the window image from step 2 >>> with 'd' >>> 5. Go to step 3-4 from the first variation. >>> >>> (I don't have a 9front instance to test on.) >>> >>> On the other hand, replacing a portion of the image from step 2 with 'y' >>> works under either. (I haven't gotten around to using 'Y' when >>> appropriate >>> yet.) >>> >>> Basically, I can only get any variation of this code: >>> https://github.com/driusan/exp/blob/18a78a1549541d46d26cb6088a904585c386d812/shiny/driver/devdrawdriver/uploadimpl.go#L50 >>> >>> to work under drawterm. >>> >>> The end result is that under a local Plan 9 instance the basic sample >>> shiny test looks like this: >>> >>> http://driusan.github.io/plan9/basicmem.png >>> >>> Instead of this: >>> >>> http://driusan.github.io/plan9/basicdrawterm.png >>> >>> Does anyone have any pointers? I don't have much access to a physical >>> Plan 9 machine, so I'm having trouble debugging this since it works >>> under >>> drawterm (or perhaps is buggy under drawterm in a way that makes it seem >>> like it's working..) >>> >>> It would also potentially be helpful if someone who uses Go under 9front >>> could let me know how x/exp/shiny/examples/basic looks with the shiny >>> driver in that branch, but I'm not sure that it matters since it'll most >>> likely be the same as one of the above.. >>> >>> - Dave >>> >> > > > -- > - Dave >