What I mean is can esd send one set of sounds out to one user's terminal
and another set to another user's terminal? :) I know it doesn't do NAS
yet, but that's what I meant.
> > Yes, all this stuff could be done by retrofitting esd. But that forces
> > people to run one particular daemon, rather than having an interface for
>
> esd is a protocol and a daemon.
So's NAS, I need NAS :) Some people need rplay. Some people just need
/dev/audio.
> > daemons, and allowing developers to just send their stuff to /dev/audio
> > without a second thought. In my particular situation, I don't really want
> > to run esd--I'd rather have a lightweight, custom program that does _only_
> > what I need it to do.
>
> I don't follow you. How can you multiplex audio with other people if you only
> want to do the bits you need. What about the bits _THEY_ need.
What I mean is that by providing an interface as opposed to a policy you
give people the option of using whatever mechanism they like--esd, NAS,
rplay, or their own thing--and they'll all work together, AND they can do
stuff like what I want to do if they want. I am not suggesting forcing
people into one solution. Perhaps an interface like this would be
beneficial though?
> > - Framebuffer forwarding. Another thing I'd like in an X-terminal
> > environment. A device manager could sit there translating
> > framebuffer data to X protocol as it comes in, allowing people to
> > run svga programs over the network (and on the same machine, in
> > X)
>
> Fix svgalib to do X11. Solving the problem is a lot more efficient than
> handling the mess if you dont.
I don't particularly like svga programs and it's not critical to me that
they work. I wouldn't go write this program even if the interface I'm
talking about _were_ in the kernel :) But if I were I'd rather write a
program to do it that runs outside of svgalib. That would save me the
trouble of recompiling all my svgalib programs and figuring out a way I
could still use them to do what they normally do.
-gorky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/