From mboxrd@z Thu Jan 1 00:00:00 1970 References: From: Steve Simon Content-Type: multipart/alternative; boundary=Apple-Mail-AC2B06F6-43F0-45E8-BEFE-F47CEF38F074 In-Reply-To: Message-Id: Date: Sat, 28 May 2016 19:28:07 +0100 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [9fans] More about /dev/draw Topicbox-Message-UUID: 950075fe-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-AC2B06F6-43F0-45E8-BEFE-F47CEF38F074 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable worth remembering that hdmi and DVI are equivalent in terms of what is neede= d for a computer monitor. hence hdmi to DVI adopters are very cheap. -Steve > On 28 May 2016, at 18:49, Dave MacFarlane wrote: >=20 > That's exactly what I'm doing. I don't have a monitor with HDMI within net= work-cable and power-cable reach to hook it up to, and the last time I hooke= d it up to my TV my toddler tore the usb/power cable of the Pi in two, so I c= an only try debugging it when he's not around.. >=20 > (And Go 1.6 or later for Plan9, but 1.7 or later for ARM, for the record..= ) >=20 >> On Sat, May 28, 2016 at 1:34 PM, Skip Tavakkolian 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= . >>=20 >>=20 >> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane wrot= e: >>> Either I'm going insane, the default Plan 9 /dev/draw in-memory implemen= tation >>> doesn't implement draw(3), or possibly both. >>>=20 >>> When I do the following, it works as expected under both drawterm and a l= ocally 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' >>>=20 >>> 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 o= r without the repl bit) >>> 4a. (Optional, doesn't seem to make a difference) set the compositing op= erator with 'O' >>> 4b. Draw the new image over a portion of the window image from step 2 wi= th 'd' >>> 5. Go to step 3-4 from the first variation. >>>=20 >>> (I don't have a 9front instance to test on.) >>>=20 >>> 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 y= et.) >>>=20 >>> Basically, I can only get any variation of this code: https://github.com= /driusan/exp/blob/18a78a1549541d46d26cb6088a904585c386d812/shiny/driver/devd= rawdriver/uploadimpl.go#L50 >>>=20 >>> to work under drawterm. >>>=20 >>> The end result is that under a local Plan 9 instance the basic sample sh= iny test looks like this: >>>=20 >>> http://driusan.github.io/plan9/basicmem.png >>>=20 >>> Instead of this: >>>=20 >>> http://driusan.github.io/plan9/basicdrawterm.png >>>=20 >>> Does anyone have any pointers? I don't have much access to a physical Pl= an 9 machine, so I'm having trouble debugging this since it works under draw= term (or perhaps is buggy under drawterm in a way that makes it seem like it= 's working..) >>>=20 >>> 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 drive= r in that branch, but I'm not sure that it matters since it'll most likely b= e the same as one of the above.. >>>=20 >>> - Dave >=20 >=20 >=20 > --=20 > - Dave --Apple-Mail-AC2B06F6-43F0-45E8-BEFE-F47CEF38F074 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
worth remembering that hdmi= and DVI are equivalent in terms of what is needed for a computer monitor.

hence hdmi to DVI adopters are very cheap.
-Steve


On 28 May 2016, at 18:49, Dave MacFarla= ne <driusan@gmail.com> wrote:=

That's exactly what I'm doing. I don't have a monitor with H= DMI within network-cable and power-cable reach to hook it up to, and the las= t 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 AR= M, for the record..)

On Sat, May 28, 2016 at 1:34 PM, Skip Tavakkolian = <skip.tav= akkolian@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 f= or plan9/arm.

On Sat, May 28, 2016 at 10:24 A= M Dave MacFarlane <driusan@gmail.com> wrote:
Either I'm going insane, the default Plan 9 /dev/draw in-memor= y implementation
doesn't implement draw(3), or possibly both.
=
When I do the following, it works as expected under both draw= term 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 windo= w with a 'd' message
4. Flush the buffer with 'v'

When I do the following, it works under drawterm, but not with a lo= cal /dev/draw implementation:
Steps 1-2 above
3. Allocat= e another image of some arbitrary fill colour with 'b' (with or without the r= epl bit)
4a. (Optional, doesn't seem to make a difference) set the= compositing operator with 'O'
4b. Draw the new image over a porti= on 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 i= nstance to test on.)

On the other hand, replacing a= portion of the image from step 2 with 'y' works under either. (I haven't go= tten around to using 'Y' when appropriate yet.)


to work under drawter= m.

The end result is that under a local Plan 9 inst= ance the basic sample shiny test looks like this:

<= a href=3D"http://driusan.github.io/plan9/basicmem.png" target=3D"_blank">htt= p://driusan.github.io/plan9/basicmem.png

In= stead of this:


Does anyone have any pointers? I= don't have much access to a physical Plan 9 machine, so I'm having trouble d= ebugging this since it works under drawterm (or perhaps is buggy under drawt= erm in a way that makes it seem like it's working..)

It would also potentially be helpful if someone who uses Go under 9front c= ould let me know how x/exp/shiny/examples/basic looks with the shiny driver i= n that branch, but I'm not sure that it matters since it'll most likely be t= he same as one of the above..

- Dave



--
<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">- Dave = --Apple-Mail-AC2B06F6-43F0-45E8-BEFE-F47CEF38F074--