Disons que c'est le moyen complique ;) La pluspart des audio drivers de maintenant supportent l'ouverture multiple de /dev/dsp et ces audio daemon machin sont en fait un gros patch pour faire marcher le tout.
Pour ton probleme, c'est simplement un droit d'acces: sous debian (et toutes les autees, souvent) : [EMAIL PROTECTED]:~$ ls -lisa /dev/dsp 17336 0 crw-rw---- 1 root audio 14, 3 Nov 5 2001 /dev/dsp donc, ajoute tes users dams le group 'audio' JeF On Tue, 2003-03-04 at 09:32, Pascal Bleser wrote: > Dominique VALLET wrote: > > Il y a quelques temps sur cette liste s'est développé un thread > > concernant l'ouverture d'une deuxième session graphique, ce que ma > > compagne a trouvé hyper-génial, puisqu'elle peut maintenant bidouiller > > dans son propre environnement tandis que le mien reste ouvert et que je > > suis occupé ailleurs pour une raison quelconque... > > Mais il y a un petit os assez désagréable : pas de son avec la deuxième > > session. Au démarrage, KDE dit qu'il ne peut utiliser /dev/dsp : > > permission denied. > > Armés des droits du superutilisateur, on a été voir ce /dev/dsp. On a > > constaté qu'il pointait en fait sur /etc/sound/dsp à qui on a activé les > Tu utilises quelle distribution ? > > > bits SUID et SGID. Ca n'a rien changé du tout au problème. > Non, ces bits n'aideront en rien. > > > Alors, l'un(e) de vous aurait une idée ? > > Ta compagne utilise également KDE dans l'autre console graphique (session) ? > > Bon, déjà, KDE permet de "partager" le device /dev/dsp entre plusieurs > applications grâce à son démon "artsd" (l'équivalent sous GNOME étant > "esound"). > Ce qui se passe: tu ouvres ta session à toi, KDE se lance, artsd se > lance et "prend" /dev/dsp à son compte afin de gérer les entrées/sorties > audio. Ce faisant, /dev/dsp appartient à ton utilisateur et ton groupe. > > Le problème est donc que lorsque ta compagne ouvre sa session, le démon > artsd qui se lance dans celle-ci ne peut prendre /dev/dsp car il > appartient déjà à ton utilisateur à toi (qui plus est en mode 600, ce > qui signifie aucun accès au groupe ni aux autres). > > Maintenant, comment résoudre ce problème... > Il faudrait que l'artsd lancé dans la 2ème session utilise l'artsd qui > est déjà en éxécution. > > Ou alors configurer artsd de telle manière à ce qu'il "relache" /dev/dsp > après un certain temps d'inactivité (esound sait faire cela). > > C'est de la bidouille, mais une idée est d'ajouter la commande suivante > dans le .xinitrc de l'utilisateur de ta compagne (~tafemme/.xinitrc > ;-)), avant la ligne > exec $WINDOWMANAGER > : > > sudo -u toi artsshell terminate > > ce qui va arrêter ton processus artsd avant que KDE ne soit lancé > (essaye d'abord avec "suspend" au lieu de "terminate"). > > Tu dois également installer "sudo" (livré avec toutes les bonnes > distributions (tm) ;-)) et le configurer comme ceci (à l'aide de la > commande "visudo", comme root): > > User_Alias ELLE=tafemme > ELLE ALL=(toi) NOPASSWD:artsshell > > Remplace évidemment "toi" par ton user et "tafemme" par celui de ta > compagne ;-) > > -- > -o) Pascal Bleser http://guru.unixtech.be | > /\\ <[EMAIL PROTECTED]> | > _\_v <[EMAIL PROTECTED]> | > ---------------------------------------------| > Jesus saves,Buddha makes incremental backups : > ---------------------------------------------' > > _______________________________________________________ > Linux Mailing List - http://www.unixtech.be > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > Archives: http://www.mail-archive.com/[EMAIL PROTECTED] > IRC: efnet.unixtech.be:6667 - #unixtech _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: efnet.unixtech.be:6667 - #unixtech
