Add into that the datarate of full 10 bit uncompressed 1920x1080/60i HD
is 932Mbit so your 1Ghz clockspeed might not be fast enough to play it :)
Not sure I agree, I think its worse than that:
1920pixels * 1080lines * 30 frames/sec * 20bits/sample in YUV
= 1.244Gbps
Also, if you want to
On Oct 19, 11:50Â am, r...@swtch.com (Russ Cox) wrote:
/bin/sh: uname: cannot execute - Access denied
I believe that if you build a new binary from the sources
instead of using the pre-compiled binary, this bug is fixed.
The binaries are lagging behind the actual source code.
Yes,
the problem is indeed drawterm related, but it's not dt's
fault.
the problem is that devdraw/loadimage.c needs to load
at least 1 scan line at a time. unfortunately, iounit for
drawterm ends up being 8k, so display-bufsize=8k. the
problem is that each scan line is over 9k in my case.
i haven't
Russ Cox wrote:
Hi,
There was no real code to speak of. It was a draft of a draft.
I did some calculations of block-level commonality using a
few trivial programs that hashed each block of every file in
a tree, but you could recreate that in 100 lines of C or shell script.
We never stored
On Tue, Oct 20, 2009 at 5:04 AM, erik quanstrom quans...@quanstro.net wrote:
the problem is that devdraw/loadimage.c needs to load
at least 1 scan line at a time. unfortunately, iounit for
drawterm ends up being 8k, so display-bufsize=8k. the
problem is that each scan line is over 9k in my
i haven't looked yet to see if the kernel can deal with
partial lines, or what could be done about the too-small
iounit. but it would seem to me that something has to
give.
you can handle this in loadimage by turning a single
call with too much data per scan line into multiple
calls,
oh, great. i just didn't know if that was legal.
is it also possible to lock the display and send
more than iounit's data?
devdraw expects the messages to be delivered whole
in each write, so you'd have to introduce a buffer to
hold partial messages or be able to process partial
writes. much
even easier would be to tweak drawterm so that it
ends up with a larger iounit. i'm pretty sure devdraw's
iounit is bigger and also that we bumped up the block
size in cpu (looks like 64 kB) for exactly this reason.
good point. can we just make i/o unit anything we wish?
maybe it's old 9p
good point. can we just make i/o unit anything we wish?
no, because it affects the size of buffer
that gets allocated to hold 9p messages.
the kernel is free to limit the iounit too.
in looking at the code, it might be a lot more efficent
for loadimage to count pixels rather than lines
i don't recall getting these before. this seems
like new behavior. i got 4 of these when downloading
4gb of pictures from a sd card. never in
the same place twice. sb600 ohci controller.
disk... reset: device is detached
it seems that umsrecover - umsreset - usbcmd and
erik quanstrom wrote:
i don't recall getting these before. this seems
like new behavior. i got 4 of these when downloading
4gb of pictures from a sd card. never in
the same place twice. sb600 ohci controller.
disk... reset: device is detached
it seems that umsrecover - umsreset - usbcmd
Anyone in yet?
--
Object-oriented design is the roman numerals of computing -- Rob Pike
I'm wondering if/when fossil might become part of plan9port. I found only a
thread from 2007 mentioning that it had not been ported.
It is of particular interest to me because I'm preparing various machines
(which are not supported by Plan 9) to manage data on dedicated disks. My
thought was
-9fans, +plan9port-dev
On Tue, Oct 20, 2009 at 4:53 PM, Albert Skye mistl...@yahoo.co.uk wrote:
I'm wondering if/when fossil might become part of plan9port. I found only a
thread from 2007 mentioning that it had not been ported.
It is of particular interest to me because I'm preparing
We are in.
Holiday Inn Express.
On Wed, Oct 21, 2009 at 1:13 AM, John Floren slawmas...@gmail.com wrote:
Anyone in yet?
--
Object-oriented design is the roman numerals of computing -- Rob Pike
Can you get the error with the old version of the code?
Nothing really changed, the disk should be asking for timeouts IIRC.
On Tue, Oct 20, 2009 at 9:33 PM, erik quanstrom quans...@quanstro.net wrote:
i don't recall getting these before. this seems
like new behavior. i got 4 of these when
Can you get the error with the old version of the code?
nope.
- erik
I'm here, anyone doing breakfast? Where to go?
ron
On Tue Oct 20 23:51:46 EDT 2009, rminn...@gmail.com wrote:
I'm here, anyone doing breakfast? Where to go?
ron
what time? i can do ~9:00 i think. how about
it's east to the 5-way intersection pm broad and
down the hill to the se (oak st)
http://www.eatatmamasboy.com/pages/base.php
- erik
I think we converged on 8am at this thing on college?
ron
The Grill is on the west side of the first block of college ave.
0xbc
iPhone email
On Oct 21, 2009, at 12:16 AM, ron minnich rminn...@gmail.com wrote:
I think we converged on 8am at this thing on college?
ron
So, floren and I are meeting in the holiday in lobby at 0730 and then
will go find grill.
I will bring laptop and will happily demo TVX and burn sticks for
anyone who cares.
Also bringing sheevaplug.
ron
SOP for some workshops in the evening for me is to find a lobby with
tables
couches
beer
hardware (we supply that)
tolerant hotel staff who don't threaten to throw you out at 2 am for
not renting a conference room (as happened in Hamburg one year)
and having a hack session. don't know if anyone
23 matches
Mail list logo
