Linux-Development-Sys Digest #887, Volume #6 Fri, 25 Jun 99 21:14:19 EDT
Contents:
Sound development in linux (Kimberly Doring)
Re: Framebuffer device why doesn't it work? - again.... (Tristan Wibberley)
linux parallel port program (Ho Lee)
Re: Why we are still holding on to X Windows (Tristan Wibberley)
Re: Why not C++ (Johan Kullstam)
Re: PCI driver blues (Emile van bergen)
Re: grap utility and man page??? (Scott Lanning)
Re: Why we are still holding on to X Windows (Tristan Wibberley)
Re: Why we are still holding on to X Windows (Chris Hedley)
Re: Why not C++ (Bruce Hoult)
Re: TAO: the ultimate OS (Dave Platt)
Re: PCI driver blues (Alexander Viro)
Re: Why we are still holding on to X Windows (Joe Pfeiffer)
Idea: on-demand c.switch of (x86?) i/o perm. map - was Re: Need help (Emile van
bergen)
----------------------------------------------------------------------------
From: Kimberly Doring <[EMAIL PROTECTED]>
Subject: Sound development in linux
Date: Fri, 25 Jun 1999 14:42:55 -0700
Reply-To: [EMAIL PROTECTED]
I need to write some code that will play a sound file in linux. Is
there an audio library for linux, or do I just write to /dev/audio
directly? Can anyone direct me to some documentation on this topic?
Thanks!
Kim
--
Kimberly Doring
Software Developer
BioTools Incorporated
Email: [EMAIL PROTECTED]
http://www.biotools.com
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Framebuffer device why doesn't it work? - again....
Date: Thu, 24 Jun 1999 18:08:38 +0100
Reply-To: [EMAIL PROTECTED]
Craig Graham wrote:
>
> Craig Graham <[EMAIL PROTECTED]> wrote:
> > I've asked this before, and still got nowhere.....anyway.
> >
> > How do I get the framebuffer consoles to work (/dev/fb0, etc).
> > I have an S3 Virge video card, and I'm running kernal 2.2.9.
>
> I followup to my own post - can I just add:
> o Yes, I am aware that you have to recompile the kernel with the
> framebuffer enabled.
> o Yes, it is enabled.
> o Yes I have read all the relevant howto's - there seem's to be a bit of "and
> then a miracle occurs" going on there somewhere, between compile,
> mknod and reboot.
>
> This post is as a result of the one unhelpful mail I got which said
> "you gotta recompile the kernel"
> - wow. very informative that was
>
> Anyone who has the faintest idea what's going on please get in touch
> (preferably someone who's compiled 2.2.9 with framebuffer support and had
> it actually work on an S3 Virge card).
I did it with 2.2.3.
Use the VESA driver. Don't forget to read what boot options (in the
Documentation dir in the kernle source). Some Virge hardware doesn't
have VESA capabilities by default either, but there is a dos program
that comes with them to load it into the hardware.
If you have one of these slightly broken cards, you need a small dos
partition which config.sys or autoexec.bat loads the Virge VESA driver
into the hardware, then start linux.
Note, *some* VESA modes may not work right.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Ho Lee <[EMAIL PROTECTED]>
Subject: linux parallel port program
Date: Fri, 25 Jun 1999 16:40:01 -0400
Hello,
I am new to this usernet and I am looking for help from someone. I hope
someone can help me out.
I am writing a program that allows the user to read an 8-bit input from
and write an 8-bit output to the parallel port.
I found in a driver function in /usr/src/linux/drivers/char/lp.c
static int lp_write(struct inode * inode, struct file * file, const
char * buf, int count)
and I think it deals with writing to the parallel port. So is this
function the one I need?
Another thing is that I couldn't find the read function for the parallel
port. So what is the best way and easiest way that I can write the
program to allow the user to read from the parallel port? Is there any
places that I can find such read function? Or I have to write the
driver function myself and compile it to the kernel?
I don't know much about device driver programming and I really need
help.
Thanks for your attention.
Ho Lee
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Thu, 24 Jun 1999 18:45:19 +0100
Reply-To: [EMAIL PROTECTED]
Cameron Hutchison wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
>
> >As for Audio, what the hell does a GUI have to do with audio? Yes, Linux
> >needs a standard networked streaming audio spec, but that is not "X."
>
> >You may be confusing X with the Window manager. X is conceptually a
> >display driver/interface.
>
> It is/should be more than that. It's the user interface.
No, it's the windowing system *part* of the whole user interface, which
is far bigger and much more complicated.
The user interface includes windowing system, toolkits, WM's, Task
managers, sound interfaces, and much more. X is a very, very, very small
part of that.
> It's important from a practical perspective too. It's quite likely an
> application would want to synchronise sound and video. With separate
> display and audio servers this would be much more difficult, perhaps
> impossible without some sort of communication between the display server
> and the audio server.
Window system events and other events do need to be syncronised, so X
needs syncronisation support, not sound support. X is so well designed,
of course, that this can be added *easily*.
> It comes down to the question of where the boundaries for X should be. I've
> often seen it written that X handles the display and nothing else - it's up
> to other servers to handle sound.
This is a slightly limited view, see below...
> X should be thought of as a user I/O service, not just a display service.
X's full name is The X Window System. It is not a general IO service, it
does _Window_System_ stuff. Sound is not window system stuff, input is
(input is redirected around the windows according to window system
behaviour). You really need to think component based - you need to
understand how it works and understand *Big* program design - then you
can start redesigning it and expect the results to be any good.
UNIX didn't become so good by making everything depend on stuff that it
doesn't depend on. "Component independance" that's the phrase of the
day.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 25 Jun 1999 17:39:51 -0400
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] writes:
> >
> > > In article <[EMAIL PROTECTED]>,
> > > Johan Kullstam <[EMAIL PROTECTED]> wrote:
> > > > "Ralph Glebe" <[EMAIL PROTECTED]> writes:
> > > [&<]
> > > >
> > > > yes. the C part is very mature. the code produced is solid.
> > > >
> > > > the C++ standard keeps changing. for example, i had to recode a
> lot
> > > > of my applications in my transition from gcc-2.7.2.* to egcs. the
> > > > egcs libstdc++ seems highly volatile. i'd rather keep as little
> > > > dependent upon it as possible. at least, now, if C++ libs break,
> i
> > > > can at least recompile what i have without the catastrophe of
> > > > missing/broken libc.
> > >
> > > The C++ standard is no longer changing, period. The compilers and
> > > library implementations are changing because they are still catching
> up,
> > > but the standard has been finished for over a year.
> >
> > the standard may be out, but the libraries and implementations are
> > still catching up and they will be doing so for a good while longer.
> > even conforming implementations may well have conflicting binaries.
> > in effect, it's almost as annoying as a moving standard. despite a
> > standard, i still have 4 incompatible versions of libstdc++.
> >
> > > Please be careful not to fud.
> >
> > standards are always being revised. fortran has had how many
> > revisions? there are at least iv, 66, 77 and 90. C has had K&R, ANSI
> > and is getting a new revision called C9X although X seems to be likely
> > to exceed 9. there will be a new C++ along in a few years. just you
> > wait.
> >
>
> First you say C++ isn't used because that standard is changing. I say
> the standard is changing but the implementations are (to catch up). Then
> you say the C++ standard isn't changing, C++ isn't used 'cause the
> implementation is still changing and that, furthermore, standards change
> and just you wait the C++ standard will change soon. Sounds like fud to
> me.
my point is that it's a bit early to start basing important system
tools on C++ because the implementation is less than stable. changing
libc is a pain in the ass. if everything were C++, then just imagine
the pain. it'd be silly to redo `cat', 'ld' and `gcc' in C++.
iirc the original question was to the effect of why don't we port all
the existing C programs to C++. well, this is why.
i said earlier in this thread that i *do* use C++. i use it on much
of the software i develop myself. when the library changes (which it
has done multiple times in the last year while i follow egcs), i can
recompile. by all means, use C++ where it makes sense. do not redo
existing programs. just think carefully about the choice between C
and C++.
reading the egcs mailing lists, it seems that there is a new function
name munging scheme in the works. it doesn't matter if the standard
is fixed or not. there will be movement in the implementation for a
good while yet. you can have multiple incompatible libstdc++
implementations which both conform to the standard.
in light of the fact that there certainly *will* be continuing
changes, i think it is very important to keep a core system done in C
to allow migration to new C++ development. this isn't unreasonable
fear, uncertainty or doubt. this is based on egcs/gcc C++ experience
over the last year or two and the information from egcs mailing list.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: PCI driver blues
Date: Sat, 26 Jun 1999 00:55:13 +0200
On Wed, 23 Jun 1999, Frank McGirt wrote:
[SNIP]
>pci617Data[pciIndex].IoMemMapRegisterKernelVirtualAddressMappedLength
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=
>
>pci617Data[pciIndex].ioMemMapRegisterPhysicalAddressSize;
Boy, are you a typing masochist? I mean, I know the slogan 'it's better
to create a bit longer identifiers _if that makes them more
descriptive_'. But this is beyond... anything! ;-)
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: grap utility and man page???
Date: 25 Jun 1999 23:19:42 GMT
M Sweger ([EMAIL PROTECTED]) wrote:
: I'm looking for the "grap" utility and associated man page.
: Does anybody know where it may be? What s/w pkg it'd be in.
I'd send the source, but they seem to've hidden most source files
on this system...
Man page follows. A bit ugly as I was lazy with the word wrapping.
Otherwise, pretty spiffy considering I denroffed it with my very
own denroff script:
#!/usr/local/bin/perl -p
s/(.)\cH\1/$1/g; s/(.)\cH\1/$1/g; #twice?? :)
s/[-\[\]_]\cH//g;
s/^ {7}//;
s/^\t//;
-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-
GRAP(1) GRAP(1)
NAME
grap - pic preprocessor for drawing graphs
SYNOPSIS grap [-Ttty_type ] [ - ] [ -- ]
OPTIONS
-T specifies tty_type as grap's output device. Currently
supported
devices are aps (Autologic APS-5) and di10 (Imagen Imprint 10).
-Taps is default.
-l Stops grap from looking for a library file of macro
defines,
/usr/lib/dwb/grap.defines.
DESCRIPTION
grap is a language for typesetting graphs. It is also the name
of the
preprocessor that feeds input to pic(1). Thus, a typical
command line
would appear as follows:
grap file(s) | pic | troff | typesetter
Graphs are surrounded by the troff "commands" .G1 and .G2. Data
that is
enclosed is scaled and plotted, with tick marks supplied
automatically.
Command exist to modify the frame, add labels, override the
default
ticks, change the plotting style, define coordinate ranges and
transformations, and include data from files. In addition,
grap provides
the same loops, conditionals and macro processing that pic does.
FILES
/usr/lib/dwb/grap.defines: definitions fo standard plotting
characters,
e.g. bullet.
SEE ALSO
pic(1).
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"I do believe God gave me a spark of genius, but he quenched it
in misery." --Edgar Allan Poe
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Thu, 24 Jun 1999 22:53:38 +0100
Reply-To: [EMAIL PROTECTED]
Joe Pfeiffer wrote:
>
> Tristan Wibberley <[EMAIL PROTECTED]> writes:
>
> > David Fox wrote:
> > >
> > > I must say that this thread has changed my mind on this point. X
> > > handles screen output, but it also handles mouse and keyboard input.
> > > Why? Because they are part of the user interface - the "UI" in "GUI",
>
> My mind hasn't been changed... but it has certainly been opened. I'm
> not nearly as positive that sound doesn't belong there as I once was.
The important argument on sound is "Does it help any to integrate it
into the X protocol?". I would say that the X protocol is extremely
inappropriate for any streamed media.
> > No, It's only because they are part of the window system - the "Window
> > System" in "The X Window System". Sound is not a part of the window
> > system.
>
> Keyboards and mice are also not part of a window system. The window
> system is only the display, not the input. But to not include
> keyboard and mouse input in X would seem perverse (at best).
I agree that the boundary here is more blurred.
Input events (eg mouse) need to be filtered according to the state of
the window system. If I put my mouse pointer at a point on the screen,
events which indicate that should be sent to the app which owns the
window that the pointer is in, not to all windows. So the input events
are deeply involved. It couldn't really be handled separately without
ugly negotiation between subsystems - they are that tightly involved,
also, the same protocol that's ideal for simple general 2d drawing
operations is ideal for input events and font support.
There are definately things which could be changed to make X more
mathematically elegant, but it would be pointless, and even detrimental.
That mathematical elegance would involve distilling X even more - and
not adding sound support into a totally inappropriate protocol.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: [EMAIL PROTECTED] (Chris Hedley)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 25 Jun 1999 18:30:03 GMT
In article <7ku7il$ss8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Scott Lanning) writes:
> I argue that Linux/X is designed for computer professionals only.
Depends on how it's configured. It's flexible enough to pander to
the whims of the terminal systems hacker just as well as the complete
novice.
Chris.
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 26 Jun 1999 11:53:08 +1200
In article <7l0c0f$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Don Waugaman) wrote:
> >Now consider references:
> >
> > int x;
> > x = 1;
> > some_function (x);
> >
> >what will be x's value after the call to some_function? Will it be
> >altered? In C, I know immediately know the answer to the question and
> >do not have to look further. This kind of syntactic sugar disturbs me
> >as one who reads a lot of software that I did not write.
>
> Reference semantics can be abused, true. Of course, would you really
> feel comfortable reading this code and not knowing a thing about what
> some_function() does?
Exactly. It depends on what "some_function" is, and should be obvious
from the semantics of what "some_function" means to you. And if you
forget, then that super-fancy editor that add's /* */ pairs for him in a
keystroke probably lets him see the prototype and/or source for
some_function() in a keystroke as well.
As a counter-example to his:
struct {
// lots'o'stuff
} foo;
some_function(&foo);
What will be foo's value after the call to some_function? Will it be
altered? In C he has no way of knowing because C programmers often pass
structs by reference even when they don't intend to change them.
If he's worried about separating the in from the out paramters then
perhaps he will prefer Dylan, where you write things like...
let (x, y, z) = some_function(a, b)
.. and it's completely clear which are the input and which the output.
> Of course, the point that Bruce was making was that one need not use the
> "advanced" C++ features such as templates, exception handling, rtti and
> the like to gain the benefits that the language offers. (I would have
> added function overloading, stronger argument typechecking (even during
> the link step, thanks to name mangling) and the C++ Standard Library,
> particularly iostreams, to his list, but it's a solid starting point.)
Oops -- meant to point out the link-time benefits of function name mangling.
But you're absolutely correct. Even when I'm programming essentially in
C, I can't see any point in not using the C++ compiler to do it. It's
just more comfortable.
-- Bruce
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 25 Jun 1999 19:24:35 GMT
In article <7l0ke9$74c$[EMAIL PROTECTED]>,
Graffiti <[EMAIL PROTECTED]> wrote:
>If you've ever tried to write software according to "What the customer
>wants", you'll find you're in a losing battle.
A "Programmer's Lament" rhyme I read a couple of decades ago ends with
the verse
"This program is garbage!"
sneered the user with a taunt,
"It's just what I asked for,
but it's not what I want."
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: PCI driver blues
Date: 25 Jun 1999 19:55:29 -0400
In article <[EMAIL PROTECTED]>,
Frank McGirt <[EMAIL PROTECTED]> wrote:
> // locate devices on PCI bus and get their configuration data
^^ ahem...
> pciAll617BusData.number617Present = 0;
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
hmm...
[snip]
>pciAll617BusData.pciSlotNumber[pciIndex],pciAll617BusData.baseMinorNodeNumber[pciIndex]);
Holy shit, where the hell did you pick that ghoulish style?
(a) underscore is there for purpose.
(b) It's Not A PaScAl to Use RanDom Capitals. It's not even ++C-1
(c) lines longer than 80 characters are generally considered as shootable
offense.
(d) identifiers of such length are *not* good.
(e) it's absofsckinglutely unreadable.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 25 Jun 1999 13:46:56 -0600
Tristan Wibberley <[EMAIL PROTECTED]> writes:
> David Fox wrote:
> >
> > I must say that this thread has changed my mind on this point. X
> > handles screen output, but it also handles mouse and keyboard input.
> > Why? Because they are part of the user interface - the "UI" in "GUI",
My mind hasn't been changed... but it has certainly been opened. I'm
not nearly as positive that sound doesn't belong there as I once was.
> No, It's only because they are part of the window system - the "Window
> System" in "The X Window System". Sound is not a part of the window
> system.
Keyboards and mice are also not part of a window system. The window
system is only the display, not the input. But to not include
keyboard and mouse input in X would seem perverse (at best).
> How many times does it need to be said? X is *NOT* a user interface! It
> is only a specifically limited *part* of one.
Agreed. And a good point for discussion is whether the limits are the
best possible, or if they should be expanded -- specifically, to
include sound.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Idea: on-demand c.switch of (x86?) i/o perm. map - was Re: Need help
Date: Sat, 26 Jun 1999 02:47:57 +0200
On Thu, 24 Jun 1999, Dave Platt wrote:
[SNIP]
>The actual program would be able to use the function library. It
>would use the inb() and outb() or similar functions (compiled with the
>-O2 option) to generate real input and output instructions.
>
>Each port access will fault, because the port I/O instructions are
>privileged. The kernel will check the port address against the port
>numbers which had been enabled via ioperm(), see that there's a match,
>execute the I/O from within the kernel, and then return to the user
>program.
You know, that brings me on an idea I once had: why not treat the (x86
specific(?) I don't know any other processor with a separate i/o space)
I/O-permission map (in the process TSS structure) analogue to the NDP
regs, i.e. after a context switch, set the tasks IOPL (in eflags) to 0,
thus trapping the first I/O access (as the tasks CPL is obviously 3).
When a trap occurs, copy the tasks own i/o permission to the user-TSS
and set the task's iopl to 3, thus allowing further I/O based on the
permission map, i.e. without traps.
Just like the NDP, where the TS flag is used for the same purpose as the
iopl in this example.
Of course (haven't checked /usr/src/linux-2.0.36, I admit), if each task
already has its own TSS structure (and there's no general user TSS
using a custom context switch, which can be significantly faster
according to intel's 386 programmers manual (esp. if pusha/popa are
'abused' I guess)), then there's no point in the whole story above.
But in that case, the next question would be: why fault on each I/O
access when we (well, the processor line I know with separate i/o /
memory address spaces) have an I/O permission map??
Hope someone can answer that... Thanks!
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
