"Alexandre Ratchov" <a...@caoua.org> wrote:
> On Sun, Apr 19, 2020 at 09:11:16AM +0200, zeurk...@volny.cz wrote:
>>
>> > Now programs connect to sndiod which does the hardware access for
>> > them, this has other advantages as well:
>> > - programs control the volume of the right device on systems with
>> > multiple audio devices (ex. usb head sets)
>> > - there's always a volume control, even if the hardware lacks one, as
>> > may usb devices.
>> > - unified view of hardware and software controls, network
>> > transparency, etc
>>
>> That may all be, but like xenodm(1), memight find (future tense, as me's
>> not running -current or snapshots) the above proposed solution
>> inadequate for me needs.
>
> Hi,
>
> I'm curious, what use-case is not handled and still requires access to
> the device nodes?
To begin w/, some ports (such as emulators/snes9x) doesn't support sndio
(as of 6.6). But in general, read "memight" as "mecan imagine that
me'd" :) Stay tuned until megets to confront the new situation (prolly
when meupgrades to 6.7 when it's out).
On the X front: duplicating the functions of login(1) and getty(8), but
then w/in the pile of bloat that is X, is a flagrant layer violation
that mecannot support.
The two issues have in common, for me, that audio and video belong in
the terminal; instead, after all this time, they are *still* treated
specially, and it shows. No wayland or NeWS or w/ever is going to help:
they are incompatible w/ the textual nature of UNIX. What *would* help
is to treat {audio samples,pixels,...} as mere characters (yet another
sensible development that is obstructed by the Unicode "Pit of Babel"),
thereby making {audio,video,...} an integral part of the system -- just
like it should be in 2020 (for fsck's sake).
Until then, the use case "UNIX" remains unhandled.
--zeurkous.
--
Friggin' Machines!
