/sys/src/cmd/usb/ether/ether.c says
* BUG: This should use /dev/etherfile to
* use the kernel ether device code.
Which sounds promising, but I can't seem to find any references to
etherfile anywhere else.
Does it exist?
tristan
--
All original matter is hereby placed immediately under the
Anyone working on or have a simple SIP router/proxy for Plan9? As of
today I will no longer waste days of my life dealing with the
abomination that is Asterisk.
I would also love to see a SIP implementation for Plan 9, I've
contemplated it a number of times, but the sheer volume of SIP RFCs is
(right, sorry erik for the double)
i hate to be pedantic,
By all means, please be pedantic, I was flat wrong.
ifs is not a list; it is a set of characters like strpbrk(2).
And it matches [$ifs]+ which is the other piece I always forget.
for(line in `{ifs=$nl cat}){...}
That is exactly
One thing that has come to concern me about rc(1) is that read(1) is
not a builtin command.
The general idea here is that forking a new process is not usually
(ever?) the bottleneck, if you have a script that needs to run faster,
there's other overhead to trim first, and if you really need to,
To start with, audio(3) seems to support soundblaster-16-compatibles.
What about others?
to my knowledge you have: soundblaster comptibles, usb thingys, and
kirkwood. (the kirkwood driver is in my contrib, it's my 1½st driver, so
beware. oh, and record isn't tested (and I would guess doesn't
multiple inputs or outputs? if so, my first pass would be do something
like what #l does: #l0, #l1, c.
Wouldn't it be better to use #A0, #A1, ... for the case of multiple
audio devices instead of multiple in/outs in one device?
that would make sense to me, though if there's a ethernet card
Changing a device's file format in a backwards-incompatible way
is not something to be done lightly. In addition to changing all
drivers you'd have to change every user program that reads from
or writes to them, even ones that you don't know exist.
i am not offering to change the interface,
- why do you assume that the old interface was not considered
sufficient?
if volume were sufficient, there was no reason to add audioctl.
- if you read usb(4) the first sentence on usb audio notes the
interface is backwards compatable.
it notes that the names are backwards compatable, but
Anthony:
The one for audioctl is reasonably regular and comprehensive; it'd be
nice to standardize our audio interfaces around that.
my concern with audioctl is multiple channels. for now control-left and
control-right are fine (if clunky), with 5.1 (or 7.1) audio that becomes
control^(1 2 3 4
i've been working on an an audio driver for the kirkwood for a while now,
indeed it's been working well for a while now. at this point i'm mostly
struggling to figure out the mixer/controls/codec filesystem interface.
if any of this is incorrect, please correct me.
the soundblaster driver has
Mouse and keyboard support should be trivial to add and will come once (if)
video is working on the Guruplug Display or OpenRD. This could take a long
while, since the video controller is undocumented (there isn't even Linux
driver source available).
There is (or maybe are two) X11 drivers
eric quanstrom:
if i read the marvell specification correctly, it uses i²s, not i²c.
wikipedia has a pointer to the phillips specification.
It uses i²s to for the data (sound) transport. the control for the codec
is seperate, the codec is a cs42l51, which has an i²s interface for data
and either
I'm working on a audio driver for kw (openrd) as a warmup for other more
useful drivers (do something easy before something hard), and I've come
to the point where to do anything more requires talking to the audio
codec. According to various linux patches, this is done over I²C. Has
anyone done
Is there any way to take a plot(6) file and output to a file? plot(1)
seems not to do that (except maybe something to do with troff?) and
nothing else appears to read them.
Something along the lines of creating a big window, plotting, and catting
n/window and trimming the border could work, but
I'm working on (re)writing some utilies for geospatial work on Plan9,
there are lots of floating point numbers (a file outlining the USGS
quadrangles for the state of Maine has about 60k). With the current
implementation this takes a long time. Maybe I should switch to a binary
format (but that's
I'm porting PROJ4.3.3 (the cleanest version of proj I could find), and
it's a little ugly.
One thing leading to another, I am currently centralizing constants, and
found that enums can hold doubles (which is quite nice), but I have no
way of defining NaN or Inf as a constant, is there such a way?
NaN(2) and Inf(2) are not constant functions. the result depends on
the settings of the fcr (getfcr(2)).
Really? My reading of /sys/src/libc/port/nan.c makes me think NaN(2)
returns a uvlong value of 0x7ff1, miss I something?
On the other hand, the assignment of NaN to a double
Is anybody else currently using the ethervgbe driver? I'm had some
problems with it which don't seem to be caused by my hardware.
After receiving 256 packets I was getting:
panic: freeb: ref -1; caller pc 0xf01b1754
panic: freeb: ref -1; caller pc 0xf01b1754
Turns out calling freeb was messing
I've several Intel PRO/1000 XF cards that I would like to use. I remember
these cards working before, but they don't now. Looking at etherigbe.c, I
see 'intergrate fiber stuff back in' in the todo list. Has anybody looked
at this recently and know what would be involved? I can muddle around and
19 matches
Mail list logo
