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 wil
st...@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 spuri
> 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.
> 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 whe
On Mon, May 30, 2016 at 8:37 AM, Richard Miller <9f...@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
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
> 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
> 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
6+5+6 is 17, not 16 bit. is this a typo or was r5g6b5 ment?
--
cinap
> 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 dimensi
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
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 th
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
> 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/D
On 29 May 2016 at 13:44, Dave MacFarlane 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
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. Th
On 28 May 2016 at 18:23, Dave MacFarlane 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.
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 wrote:
> Actually, looking at the back of the monit
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? W
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 moni
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 broke
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 'H
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 wrote:
>
> That's exactly what I'm doing. I don't have a monitor with HDMI within
> network-cabl
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 to
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 fo
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
> doe
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
27 matches
Mail list logo
