9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] More about /dev/draw
@ 2016-05-28 17:23 Dave MacFarlane
  2016-05-28 17:34 ` Skip Tavakkolian
  2016-05-29 10:50 ` Charles Forsyth
  0 siblings, 2 replies; 27+ messages in thread
From: Dave MacFarlane @ 2016-05-28 17:23 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2805 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-28 17:23 [9fans] More about /dev/draw Dave MacFarlane
@ 2016-05-28 17:34 ` Skip Tavakkolian
  2016-05-28 17:49   ` Dave MacFarlane
  2016-05-29  5:40   ` jfmxl
  2016-05-29 10:50 ` Charles Forsyth
  1 sibling, 2 replies; 27+ messages in thread
From: Skip Tavakkolian @ 2016-05-28 17:34 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

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 <driusan@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 3339 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-28 17:34 ` Skip Tavakkolian
@ 2016-05-28 17:49   ` Dave MacFarlane
  2016-05-28 18:04     ` hiro
  2016-05-28 18:28     ` Steve Simon
  2016-05-29  5:40   ` jfmxl
  1 sibling, 2 replies; 27+ messages in thread
From: Dave MacFarlane @ 2016-05-28 17:49 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]

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 <driusan@gmail.com>
> 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

[-- Attachment #2: Type: text/html, Size: 4318 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-28 17:49   ` Dave MacFarlane
@ 2016-05-28 18:04     ` hiro
  2016-05-28 18:28     ` Steve Simon
  1 sibling, 0 replies; 27+ messages in thread
From: hiro @ 2016-05-28 18:04 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

it's easier to just get a thinkpad that's listed on
http://fqa.9front.org/fqa3.html

On 5/28/16, Dave MacFarlane <driusan@gmail.com> 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 <driusan@gmail.com>
>> 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
>



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

* Re: [9fans] More about /dev/draw
  2016-05-28 17:49   ` Dave MacFarlane
  2016-05-28 18:04     ` hiro
@ 2016-05-28 18:28     ` Steve Simon
  1 sibling, 0 replies; 27+ messages in thread
From: Steve Simon @ 2016-05-28 18:28 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]

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 MacFarlane <driusan@gmail.com> 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 <driusan@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 4726 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-28 17:34 ` Skip Tavakkolian
  2016-05-28 17:49   ` Dave MacFarlane
@ 2016-05-29  5:40   ` jfmxl
  2016-05-29  5:50     ` Steve Simon
  2016-05-31  8:14     ` Richard Miller
  1 sibling, 2 replies; 27+ messages in thread
From: jfmxl @ 2016-05-29  5:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I see an image at bell labs for the raspberry pi.
http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz

I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs
for sale. Will either one work with that image?

I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI'
connection, I believe. Am I good to go?



On 2016-05-29 00:34, 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.
>
> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driusan@gmail.com>
> 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




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

* Re: [9fans] More about /dev/draw
  2016-05-29  5:40   ` jfmxl
@ 2016-05-29  5:50     ` Steve Simon
  2016-05-29  5:59       ` jfmxl
  2016-05-31  8:41       ` Richard Miller
  2016-05-31  8:14     ` Richard Miller
  1 sibling, 2 replies; 27+ messages in thread
From: Steve Simon @ 2016-05-29  5:50 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I use the Pi 2 version daily at work with an hdmi monitor.

there seem to be a couple of lurking bugs in the sub driver which
generate spurious grumbles and seem to prevent sub serial adapters
from working, which is a minor annoyance. Other than that it works like a charm.

audio out is still broken too which is a continuous source of guilt to me - 
I will fix that one day.

-Steve


> On 29 May 2016, at 06:40, jfmxl <jfmxl@SDF.ORG> wrote:
> 
> I see an image at bell labs for the raspberry pi. http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
> 
> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs for sale. Will either one work with that image?
> 
> I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI' connection, I believe. Am I good to go?
> 
> 
> 
>> On 2016-05-29 00:34, 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.
>> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driusan@gmail.com>
>> 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
> 




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

* Re: [9fans] More about /dev/draw
  2016-05-29  5:50     ` Steve Simon
@ 2016-05-29  5:59       ` jfmxl
  2016-05-29  6:19         ` jfmxl
  2016-05-31  8:41       ` Richard Miller
  1 sibling, 1 reply; 27+ messages in thread
From: jfmxl @ 2016-05-29  5:59 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Thanks for the answer, Steve.

Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a 'sub
driver'? not 'usb driver', or is it? The audio out is broken, but it's
your fault? How is that?

On 2016-05-29 12:50, Steve Simon wrote:
> I use the Pi 2 version daily at work with an hdmi monitor.
>
> there seem to be a couple of lurking bugs in the sub driver which
> generate spurious grumbles and seem to prevent sub serial adapters
> from working, which is a minor annoyance. Other than that it works like
> a charm.
>
> audio out is still broken too which is a continuous source of guilt to
> me -
> I will fix that one day.
>
> -Steve
>
>
>> On 29 May 2016, at 06:40, jfmxl <jfmxl@SDF.ORG> wrote:
>>
>> I see an image at bell labs for the raspberry pi.
>> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>>
>> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model
>> Bs for sale. Will either one work with that image?
>>
>> I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI'
>> connection, I believe. Am I good to go?
>>
>>
>>
>>> On 2016-05-29 00:34, 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.
>>> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driusan@gmail.com>
>>> 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
>>




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

* Re: [9fans] More about /dev/draw
  2016-05-29  5:59       ` jfmxl
@ 2016-05-29  6:19         ` jfmxl
  2016-05-29  8:05           ` hiro
  2016-05-29 17:25           ` trebol55555
  0 siblings, 2 replies; 27+ messages in thread
From: jfmxl @ 2016-05-29  6:19 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Actually, looking at the back of the monitor, it has an analog vga
plug-in and a similar sized digital plug-in, but no HDMI. Can I still
use it with Raspberry Pi Plan 9?

On 2016-05-29 12:59, jfmxl wrote:
> Thanks for the answer, Steve.
>
> Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a
> 'sub driver'? not 'usb driver', or is it? The audio out is broken, but
> it's your fault? How is that?
>
> On 2016-05-29 12:50, Steve Simon wrote:
>> I use the Pi 2 version daily at work with an hdmi monitor.
>>
>> there seem to be a couple of lurking bugs in the sub driver which
>> generate spurious grumbles and seem to prevent sub serial adapters
>> from working, which is a minor annoyance. Other than that it works
>> like a charm.
>>
>> audio out is still broken too which is a continuous source of guilt to
>> me -
>> I will fix that one day.
>>
>> -Steve
>>
>>
>>> On 29 May 2016, at 06:40, jfmxl <jfmxl@SDF.ORG> wrote:
>>>
>>> I see an image at bell labs for the raspberry pi.
>>> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>>>
>>> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model
>>> Bs for sale. Will either one work with that image?
>>>
>>> I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI'
>>> connection, I believe. Am I good to go?
>>>
>>>
>>>
>>>> On 2016-05-29 00:34, 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.
>>>> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driusan@gmail.com>
>>>> 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
>>>




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

* Re: [9fans] More about /dev/draw
  2016-05-29  6:19         ` jfmxl
@ 2016-05-29  8:05           ` hiro
  2016-05-29 17:25           ` trebol55555
  1 sibling, 0 replies; 27+ messages in thread
From: hiro @ 2016-05-29  8:05 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

jfmxl, this mailing list is not a hardware store. how are we supposed
to know what "digital plug-in" means?
if you still have the package of your TV or the manual it might give a
hint. Otherwise I'm sure you know how to google.

On 5/29/16, jfmxl <jfmxl@sdf.org> wrote:
> Actually, looking at the back of the monitor, it has an analog vga
> plug-in and a similar sized digital plug-in, but no HDMI. Can I still
> use it with Raspberry Pi Plan 9?
>
> On 2016-05-29 12:59, jfmxl wrote:
>> Thanks for the answer, Steve.
>>
>> Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a
>> 'sub driver'? not 'usb driver', or is it? The audio out is broken, but
>> it's your fault? How is that?
>>
>> On 2016-05-29 12:50, Steve Simon wrote:
>>> I use the Pi 2 version daily at work with an hdmi monitor.
>>>
>>> there seem to be a couple of lurking bugs in the sub driver which
>>> generate spurious grumbles and seem to prevent sub serial adapters
>>> from working, which is a minor annoyance. Other than that it works
>>> like a charm.
>>>
>>> audio out is still broken too which is a continuous source of guilt to
>>> me -
>>> I will fix that one day.
>>>
>>> -Steve
>>>
>>>
>>>> On 29 May 2016, at 06:40, jfmxl <jfmxl@SDF.ORG> wrote:
>>>>
>>>> I see an image at bell labs for the raspberry pi.
>>>> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>>>>
>>>> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model
>>>> Bs for sale. Will either one work with that image?
>>>>
>>>> I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI'
>>>> connection, I believe. Am I good to go?
>>>>
>>>>
>>>>
>>>>> On 2016-05-29 00:34, 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.
>>>>> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driusan@gmail.com>
>>>>> 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
>>>>
>
>
>



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

* Re: [9fans] More about /dev/draw
  2016-05-28 17:23 [9fans] More about /dev/draw Dave MacFarlane
  2016-05-28 17:34 ` Skip Tavakkolian
@ 2016-05-29 10:50 ` Charles Forsyth
  2016-05-29 12:44   ` Dave MacFarlane
  1 sibling, 1 reply; 27+ messages in thread
From: Charles Forsyth @ 2016-05-29 10:50 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

On 28 May 2016 at 18:23, Dave MacFarlane <driusan@gmail.com> wrote:

> Does anyone have any pointers?


I'd check that the image you're drawing with S over D isn't filled with a
completely transparent value
if the image has got an alpha channel.

[-- Attachment #2: Type: text/html, Size: 577 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-29 10:50 ` Charles Forsyth
@ 2016-05-29 12:44   ` Dave MacFarlane
  2016-05-29 12:58     ` Charles Forsyth
  0 siblings, 1 reply; 27+ messages in thread
From: Dave MacFarlane @ 2016-05-29 12:44 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

Why would the alpha channel work differently with the same image from the
same code with the same hardware
depending on the driver? (I've already tried setting it to a 50% alpha just
in case it was something like a bug
in drawterm not honouring the alpha channel and I was doing something
stupid. The 50% alpha worked fine
in drawterm but didn't change anything locally..)

On Sun, May 29, 2016 at 6:50 AM, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 28 May 2016 at 18:23, Dave MacFarlane <driusan@gmail.com> wrote:
>
>> Does anyone have any pointers?
>
>
> I'd check that the image you're drawing with S over D isn't filled with a
> completely transparent value
> if the image has got an alpha channel.
>



--
- Dave

[-- Attachment #2: Type: text/html, Size: 1514 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-29 12:44   ` Dave MacFarlane
@ 2016-05-29 12:58     ` Charles Forsyth
  2016-05-30  0:30       ` Dave MacFarlane
  0 siblings, 1 reply; 27+ messages in thread
From: Charles Forsyth @ 2016-05-29 12:58 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On 29 May 2016 at 13:44, Dave MacFarlane <driusan@gmail.com> wrote:

> Why would the alpha channel work differently with the same image from the
> same code with the same hardware
> depending on the driver?
>

Because there might be a difference in the way the components inside the
pixel word are being interpreted or used by memdraw.

[-- Attachment #2: Type: text/html, Size: 650 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-29  6:19         ` jfmxl
  2016-05-29  8:05           ` hiro
@ 2016-05-29 17:25           ` trebol55555
  1 sibling, 0 replies; 27+ messages in thread
From: trebol55555 @ 2016-05-29 17:25 UTC (permalink / raw)
  To: 9fans

> Actually, looking at the back of the monitor, it has an analog vga
> plug-in and a similar sized digital plug-in, but no HDMI. Can I still
> use it with Raspberry Pi Plan 9?

If you are talking about DVI, you can use something like this (without loss):

	http://www.aliexpress.com/item/DVI-D-Dual-link-Male-24-1-to-HDMI-Female-Adapter-HDMI-to-DVI-Gold-Connector/32598419270.html?s=p&spm=2114.01010208.6.2.I4W7d9

One of this is very usefull, too, and the quality of the image is very good (with a little, little loss):

	http://www.aliexpress.com/item/HDMI-to-VGA-Adaptor-Micro-HDMI-Mini-HDMI-Male-Adapter-to-VGA-Female-Built-in-1080p/32628751085.html

trebol.




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

* Re: [9fans] More about /dev/draw
  2016-05-29 12:58     ` Charles Forsyth
@ 2016-05-30  0:30       ` Dave MacFarlane
  2016-05-30  9:20         ` Richard Miller
  0 siblings, 1 reply; 27+ messages in thread
From: Dave MacFarlane @ 2016-05-30  0:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

Well, that led me down a rabbit hole where I found two problems and now I'm
having a third that I need advice on. The main problem was that I was
forgot to set the draw op to src when doing the final draw of the window,
so it was defaulting to SoverD. Second, unrelatedly, the alpha masks were
being doubled (or halved, I guess) when filling an alpha channel because I
was using the same id as the src and the mask since they have the same
bounds, so the mask was getting multiplied through a second time, but that
wasn't affecting the background disappearing since they were opaque colours.

Now, after setting the drawop to src, I'm getting a black background
instead of a dark blue one. I tried changing the colours arbitrarily to see
if black was just how it represents an alpha channel when there's nothing
under it, and with lighter colours it's drawing a yellow background on
drawterm and a pink one on the Pi. I've narrowed it down to the fact that
the the screen channel descriptor on the Pi is different. When I do cat
/dev/draw/new, it's telling me it's an r6g5b6 channel while in drawterm
it's x8r8g8b8. I'm not sure how that's possible though, because I'm fairly
sure I remember reading in a man page that channels had to be multiples of
8, though I can't find where I read that now.

Is there anything I can do about this? I'm fairly sure an r6g5b6 channel
should be able to represent yellow as a combination of red and green, but
the the format of colours in a draw operation is irrespective of the
channel format, so I can't be doing anything wrong there. Oddly, the places
where I'm directly replacing pixels in the buffer with 'y', where the
channel format *does* matter seem to be fine, but I think that might just
be luck because the gradient is mostly red and green.

On Sun, May 29, 2016 at 8:58 AM, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 29 May 2016 at 13:44, Dave MacFarlane <driusan@gmail.com> wrote:
>
>> Why would the alpha channel work differently with the same image from the
>> same code with the same hardware
>> depending on the driver?
>>
>
> Because there might be a difference in the way the components inside the
> pixel word are being interpreted or used by memdraw.
>



--
- Dave

[-- Attachment #2: Type: text/html, Size: 3080 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-30  0:30       ` Dave MacFarlane
@ 2016-05-30  9:20         ` Richard Miller
  2016-05-30  9:27           ` cinap_lenrek
  2016-05-30 10:08           ` Richard Miller
  0 siblings, 2 replies; 27+ messages in thread
From: Richard Miller @ 2016-05-30  9:20 UTC (permalink / raw)
  To: 9fans

> When I do cat
> /dev/draw/new, it's telling me it's an r6g5b6 channel while in drawterm
> it's x8r8g8b8. ...
>
> Is there anything I can do about this?

You can set the screen depth to 24 on the pi instead of the default 16.
Set vgasize=WxHx24 in cmdline.txt where W and H are your screen dimensions.

When I tried this the colours were reversed.  I think the videocore
firmware must have changed from BGR to RGB some time since I last
looked.  I will look into this.  Meanwhile a quick fix is

diff /n/dump/2016/0530/sys/src/9/bcm/screen.c /sys/src/9/bcm/screen.c
342c342
< 		chan = BGR24;
---
> 		chan = RGB24;




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

* Re: [9fans] More about /dev/draw
  2016-05-30  9:20         ` Richard Miller
@ 2016-05-30  9:27           ` cinap_lenrek
  2016-05-30 13:11             ` Dave MacFarlane
  2016-05-30 10:08           ` Richard Miller
  1 sibling, 1 reply; 27+ messages in thread
From: cinap_lenrek @ 2016-05-30  9:27 UTC (permalink / raw)
  To: 9fans

6+5+6 is 17, not 16 bit. is this a typo or was r5g6b5 ment?

--
cinap



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

* Re: [9fans] More about /dev/draw
  2016-05-30  9:20         ` Richard Miller
  2016-05-30  9:27           ` cinap_lenrek
@ 2016-05-30 10:08           ` Richard Miller
  2016-05-30 12:37             ` Richard Miller
  1 sibling, 1 reply; 27+ messages in thread
From: Richard Miller @ 2016-05-30 10:08 UTC (permalink / raw)
  To: 9fans

> I think the videocore
> firmware must have changed from BGR to RGB some time since I last
> looked.  I will look into this.

Yes, someone on the netbsd mailing list noticed (Jan 2015):

> Newer Raspberry Pi firmware has changed the framebuffer from BGR to RGB.
> The method we use to set the pixel order (vcprop set pixel order) does not
> seem to work, nor does querying the pixel order (vcprop get pixel order).
>
> The firmware passes this information to the kernel by adding a
> "bcm2708_fb.fbswap" kernel cmdline arg. 0=BGR, 1=RGB. ...

It turns out that the interface 9pi used for querying framebuffer depth
is also now broken.  Setting framebuffer_depth=N in config.txt used to
work for changing the pixel format, now it doesn't.

Sadly there's been a history of the pi firmware interface quietly changing
behind the scenes.  Making a corresponding quiet change to their linux
kernel seems to be considered sufficient documentation.  Sigh.




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

* Re: [9fans] More about /dev/draw
  2016-05-30 10:08           ` Richard Miller
@ 2016-05-30 12:37             ` Richard Miller
  2016-05-30 13:13               ` Dave MacFarlane
  0 siblings, 1 reply; 27+ messages in thread
From: Richard Miller @ 2016-05-30 12:37 UTC (permalink / raw)
  To: 9fans

> It turns out that the interface 9pi used for querying framebuffer depth
> is also now broken.  Setting framebuffer_depth=N in config.txt used to
> work for changing the pixel format, now it doesn't.

OK, new 9pi and 9pi2 kernels in /n/sources/contrib/miller should now do
the right thing for 24bpp, which can be requested with framebuffer_depth=24
in config.txt or vgasize=WxHx24 in cmdline.txt




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

* Re: [9fans] More about /dev/draw
  2016-05-30  9:27           ` cinap_lenrek
@ 2016-05-30 13:11             ` Dave MacFarlane
  0 siblings, 0 replies; 27+ messages in thread
From: Dave MacFarlane @ 2016-05-30 13:11 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

Probably a typo, I was going from memory. I thought it was a multiple of 8
bits per component, not for the whole thing, so that (and a typo) would
explain it.

But the bigger problem was that even if you only have 1 bit for r, g, and b
you should be able to represent yellow as 110, so any r>1g>1b>1 should be
able to handle it.

On Mon, May 30, 2016 at 5:27 AM, <cinap_lenrek@felloff.net> wrote:

> 6+5+6 is 17, not 16 bit. is this a typo or was r5g6b5 ment?
>
> --
> cinap
>
>


--
- Dave

[-- Attachment #2: Type: text/html, Size: 941 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-30 12:37             ` Richard Miller
@ 2016-05-30 13:13               ` Dave MacFarlane
  2016-05-30 13:53                 ` Richard Miller
  0 siblings, 1 reply; 27+ messages in thread
From: Dave MacFarlane @ 2016-05-30 13:13 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

On Mon, May 30, 2016 at 8:37 AM, Richard Miller <9fans@hamnavoe.com> wrote:

> > It turns out that the interface 9pi used for querying framebuffer depth
> > is also now broken.  Setting framebuffer_depth=N in config.txt used to
> > work for changing the pixel format, now it doesn't.
>
> OK, new 9pi and 9pi2 kernels in /n/sources/contrib/miller should now do
> the right thing for 24bpp, which can be requested with framebuffer_depth=24
> in config.txt or vgasize=WxHx24 in cmdline.txt
>

I was pretty sure it was either a kernel or libmemdraw bug, but I don't
know how you can possibly
track these things down so quickly without even getting a proper bug
report.

- Dave

[-- Attachment #2: Type: text/html, Size: 1139 bytes --]

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

* Re: [9fans] More about /dev/draw
  2016-05-30 13:13               ` Dave MacFarlane
@ 2016-05-30 13:53                 ` Richard Miller
  0 siblings, 0 replies; 27+ messages in thread
From: Richard Miller @ 2016-05-30 13:53 UTC (permalink / raw)
  To: 9fans

> I was pretty sure it was either a kernel or libmemdraw bug, but I don't
> know how you can possibly
> track these things down so quickly without even getting a proper bug
> report.

All I did was to recover the ability to set r8g8b8 mode on 9pi, after
a firmware change broke it.  I don't know whether this will actually
help with your bug or not.




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

* Re: [9fans] More about /dev/draw
  2016-05-29  5:40   ` jfmxl
  2016-05-29  5:50     ` Steve Simon
@ 2016-05-31  8:14     ` Richard Miller
  2016-05-31 14:18       ` jfmxl
  1 sibling, 1 reply; 27+ messages in thread
From: Richard Miller @ 2016-05-31  8:14 UTC (permalink / raw)
  To: 9fans

> I see an image at bell labs for the raspberry pi.
> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>
> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs
> for sale. Will either one work with that image?

They will now.  Also the Raspberry Pi Zero.




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

* Re: [9fans] More about /dev/draw
  2016-05-29  5:50     ` Steve Simon
  2016-05-29  5:59       ` jfmxl
@ 2016-05-31  8:41       ` Richard Miller
  1 sibling, 0 replies; 27+ messages in thread
From: Richard Miller @ 2016-05-31  8:41 UTC (permalink / raw)
  To: 9fans

steve@quintile.net:
> there seem to be a couple of lurking bugs in the sub driver which
> generate spurious grumbles and seem to prevent sub serial adapters
> from working, which is a minor annoyance. Other than that it works like a charm.

I've made some tweaks to usb which eliminated one spurious "port resumed"
message.  You might try updating your kernel if you haven't done so recently.
Dan Cross found a bug in the ftdi usbserial driver (not specific to 9pi)
which is fixed by /n/sources/patch/usbserial-ftdi-writelen - could that
be relevant for you?




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

* Re: [9fans] More about /dev/draw
  2016-05-31  8:14     ` Richard Miller
@ 2016-05-31 14:18       ` jfmxl
  0 siblings, 0 replies; 27+ messages in thread
From: jfmxl @ 2016-05-31 14:18 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs; +Cc: Richard Miller

Thanks!

On 2016-05-31 15:14, Richard Miller wrote:
>> I see an image at bell labs for the raspberry pi.
>> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>>
>> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model
>> Bs
>> for sale. Will either one work with that image?
>
> They will now.  Also the Raspberry Pi Zero.




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

* Re: [9fans] More about /dev/draw
  2016-05-29 19:24 ` Brian L. Stuart
@ 2016-05-29 22:47   ` jfmxl
  0 siblings, 0 replies; 27+ messages in thread
From: jfmxl @ 2016-05-29 22:47 UTC (permalink / raw)
  To: Brian L. Stuart, Fans of the OS Plan 9 from Bell Labs

Thanks very much - and to trebol and eric - for taking the time to help.

On 2016-05-30 02:24, Brian L. Stuart wrote:
> I'll try to answer several questions here together.
>
>> I see an image at bell labs for the raspberry pi.
>> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>>
>> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model
>> Bs
>> for sale. Will either one work with that image?
>
> I might be mistaken, but I don't thnk that image has the few little
> changes necessary for the Pi3.  The kernel file contrib/miller/9pi2
> might have the update, but the sources in contrib/miller/9/bcm
> are the most current.
>
>> Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a
>> 'sub
>> driver'? not 'usb driver', or is it? The audio out is broken, but it's
>> your fault? How is that?
>
> Feel free to correct me, Steve, if I get anything wrong here.  I think
> it
> was a typo referring to USB.  I'm not sure if it's the same one that's
> causing problems with serial adapters, but I've run into one that I
> keep intending to track down when I've tried to use USB 802.11
> adapters.  As for the audio, I'm pretty sure it's the same position
> many
> of us are in.  We intend to do some work on supporting it, but in the
> words of the late Prince, this thing we call life gets in the way.
>
>> Actually, looking at the back of the monitor, it has an analog vga
>> plug-in and a similar sized digital plug-in, but no HDMI. Can I still
>> use it with Raspberry Pi Plan 9?
>
> As trebol said, if it's a DVI interface, then a simple adapter from
> HDMI
> to DVI will work.  That's the way I run one of my Pis as the office
> every day.  A typical DVI connector on a monitor looks like this:
>
> http://www.publicdomainpictures.net/view-image.php?image=12589
>
>> On another tack ... I have installed plan 9 from user space on my
>> debian
>> machine, and sam and acme seem to open and work ok. But when I type
>> rio,
>> I get ...
>>
>> $ rio
>> rio: it looks like there's already a window manager running;  rio not
>> started
>>
>> So, rio under plan 9 from user space (p9port?) wants the the whole
>> display?
>>
>> I cannot run xfce and have rio in a window?
>
> Correct.  The design of the Plan 9 windowing system is such that the
> ability to run another instance of the windowing system in a window
> falls out very elegantly.  The same is not true of X.  There, each
> display
> has a single window manager.  As Erik noted, there's xnest that allows
> a display to be nested in a window of another display, though I've
> never really played with it.  I got scared enough the last time I
> looked
> at the internals of a regular X server.  I'm not sure my old brain
> could
> handle xnest.
>
> BLS




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

* Re: [9fans] More about /dev/draw
       [not found] <1927218855.974253.1464549855538.JavaMail.yahoo.ref@mail.yahoo.com>
@ 2016-05-29 19:24 ` Brian L. Stuart
  2016-05-29 22:47   ` jfmxl
  0 siblings, 1 reply; 27+ messages in thread
From: Brian L. Stuart @ 2016-05-29 19:24 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I'll try to answer several questions here together.

> I see an image at bell labs for the raspberry pi.
> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>
> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs
> for sale. Will either one work with that image?

I might be mistaken, but I don't thnk that image has the few little
changes necessary for the Pi3.  The kernel file contrib/miller/9pi2
might have the update, but the sources in contrib/miller/9/bcm
are the most current.

> Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a 'sub
> driver'? not 'usb driver', or is it? The audio out is broken, but it's
> your fault? How is that?

Feel free to correct me, Steve, if I get anything wrong here.  I think it
was a typo referring to USB.  I'm not sure if it's the same one that's
causing problems with serial adapters, but I've run into one that I
keep intending to track down when I've tried to use USB 802.11
adapters.  As for the audio, I'm pretty sure it's the same position many
of us are in.  We intend to do some work on supporting it, but in the
words of the late Prince, this thing we call life gets in the way.

> Actually, looking at the back of the monitor, it has an analog vga
> plug-in and a similar sized digital plug-in, but no HDMI. Can I still
> use it with Raspberry Pi Plan 9?

As trebol said, if it's a DVI interface, then a simple adapter from HDMI
to DVI will work.  That's the way I run one of my Pis as the office
every day.  A typical DVI connector on a monitor looks like this:

http://www.publicdomainpictures.net/view-image.php?image=12589

> On another tack ... I have installed plan 9 from user space on my debian
> machine, and sam and acme seem to open and work ok. But when I type rio,
> I get ...
>
> $ rio
> rio: it looks like there's already a window manager running;  rio not
> started
>
> So, rio under plan 9 from user space (p9port?) wants the the whole
> display?
>
> I cannot run xfce and have rio in a window?

Correct.  The design of the Plan 9 windowing system is such that the
ability to run another instance of the windowing system in a window
falls out very elegantly.  The same is not true of X.  There, each display
has a single window manager.  As Erik noted, there's xnest that allows
a display to be nested in a window of another display, though I've
never really played with it.  I got scared enough the last time I looked
at the internals of a regular X server.  I'm not sure my old brain could
handle xnest.

BLS



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

end of thread, other threads:[~2016-05-31 14:18 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-28 17:23 [9fans] More about /dev/draw Dave MacFarlane
2016-05-28 17:34 ` Skip Tavakkolian
2016-05-28 17:49   ` Dave MacFarlane
2016-05-28 18:04     ` hiro
2016-05-28 18:28     ` Steve Simon
2016-05-29  5:40   ` jfmxl
2016-05-29  5:50     ` Steve Simon
2016-05-29  5:59       ` jfmxl
2016-05-29  6:19         ` jfmxl
2016-05-29  8:05           ` hiro
2016-05-29 17:25           ` trebol55555
2016-05-31  8:41       ` Richard Miller
2016-05-31  8:14     ` Richard Miller
2016-05-31 14:18       ` jfmxl
2016-05-29 10:50 ` Charles Forsyth
2016-05-29 12:44   ` Dave MacFarlane
2016-05-29 12:58     ` Charles Forsyth
2016-05-30  0:30       ` Dave MacFarlane
2016-05-30  9:20         ` Richard Miller
2016-05-30  9:27           ` cinap_lenrek
2016-05-30 13:11             ` Dave MacFarlane
2016-05-30 10:08           ` Richard Miller
2016-05-30 12:37             ` Richard Miller
2016-05-30 13:13               ` Dave MacFarlane
2016-05-30 13:53                 ` Richard Miller
     [not found] <1927218855.974253.1464549855538.JavaMail.yahoo.ref@mail.yahoo.com>
2016-05-29 19:24 ` Brian L. Stuart
2016-05-29 22:47   ` jfmxl

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).