From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B6E76138010 for ; Thu, 23 Aug 2012 03:55:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7B58721C017; Thu, 23 Aug 2012 03:54:40 +0000 (UTC) Received: from icp-osb-irony-out9.external.iinet.net.au (icp-osb-irony-out9.external.iinet.net.au [203.59.1.226]) by pigeon.gentoo.org (Postfix) with ESMTP id 481B9E0759 for ; Thu, 23 Aug 2012 03:52:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACuoNVA6B49v/2dsb2JhbABFhgG0UYEHgiABAQEEAQIgZgsNBAMBAgECAiYCAignCBmHfgMLDKYSkxIEgSGJBGOFf4ESA4hNilqIByKKFYJw X-IronPort-AV: E=Sophos;i="4.80,298,1344182400"; d="scan'208";a="25545814" Received: from unknown (HELO moriah.localdomain) ([58.7.143.111]) by icp-osb-irony-out9.iinet.net.au with ESMTP; 23 Aug 2012 11:52:31 +0800 Received: from localhost (localhost [127.0.0.1]) by moriah.localdomain (Postfix) with ESMTP id 431632312BA for ; Thu, 23 Aug 2012 11:52:31 +0800 (WST) X-Virus-Scanned: amavisd-new at lan.localdomain Received: from moriah.localdomain ([127.0.0.1]) by localhost (moriah.lan.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3R8wlM1rnmw for ; Thu, 23 Aug 2012 11:52:27 +0800 (WST) Received: from [192.168.48.1] (troll [192.168.48.1]) by moriah.localdomain (Postfix) with ESMTP id 7E5072312B4 for ; Thu, 23 Aug 2012 11:52:27 +0800 (WST) Message-ID: <1345693947.16849.62.camel@troll> Subject: Re: [gentoo-user] /dev/snd/seq access mode and permission From: Bill Kenworthy To: gentoo-user@lists.gentoo.org Date: Thu, 23 Aug 2012 11:52:27 +0800 In-Reply-To: <20120822203534.518A9C4D@resin03.mta.everyone.net> References: <20120822203534.518A9C4D@resin03.mta.everyone.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 X-Archives-Salt: 5f3a73cd-0bea-47e1-9901-b9122ed2ffce X-Archives-Hash: 88ddc5c5268308395d08718da393b502 Try this (my "fix" is in /lib/udev/rules.d/40-gentoo.rules): moriah ~ # equery f udev * Searching for udev ... * Contents of sys-fs/udev-171-r6: /etc /etc/conf.d /etc/conf.d/udev /etc/init.d ... /lib/udev/rules.d /lib/udev/rules.d/30-kernel-compat.rules /lib/udev/rules.d/40-gentoo.rules /lib/udev/rules.d/42-qemu-usb.rules /lib/udev/rules.d/50-firmware.rules /lib/udev/rules.d/50-udev-default.rules /lib/udev/rules.d/60-cdrom_id.rules /lib/udev/rules.d/60-floppy.rules /lib/udev/rules.d/60-persistent-alsa.rules /lib/udev/rules.d/60-persistent-input.rules ... moriah ~ # grep snd /lib/udev/rules.d/* /lib/udev/rules.d/40-gentoo.rules:SUBSYSTEM=="snd", GROUP="audio" /lib/udev/rules.d/50-udev-default.rules:KERNEL=="seq", GROUP="audio", MODE="0660", OPTIONS+="static_node=snd/seq" /lib/udev/rules.d/50-udev-default.rules:KERNEL=="timer", GROUP="audio", MODE="0660", OPTIONS+="static_node=snd/timer" /lib/udev/rules.d/60-persistent-alsa.rules:ENV{ID_SERIAL}=="?*", ENV{ID_IFACE}=="?*", SYMLINK+="snd/by-id/$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_IFACE}" /lib/udev/rules.d/60-persistent-alsa.rules:ENV{ID_SERIAL}=="?*", ENV{ID_IFACE}=="", SYMLINK+="snd/by-id/$env{ID_BUS}-$env{ID_SERIAL}" /lib/udev/rules.d/60-persistent-alsa.rules:ENV{ID_PATH}=="?*", SYMLINK+="snd/by-path/$env{ID_PATH}" moriah ~ # BillK On Wed, 2012-08-22 at 20:35 -0700, Cinder wrote: > I have tried creating this rule: > > /etc/udev/rules.d/40-seq.rules > KERNEL=="snd/seq", GROUP="audio", MODE="0666" > > ...but I'm not sure about the kernel key pair. I have tried matching "/dev/snd/seq" and just "seq" > aswell. > > The Bug 406871 for sys-fs/udev-171-r5 looks exactly right, butI have sys-fs/udev-171-r6 installed. I''l check my kernel config and try disabling tmpfs. I have read that it helps real time audio performanc with jack(audio-connection-kit)though. > > I have tried removing all the rules in /etc/udev/rules.d. but the mode and permissions on /dev/snd/seq persist. > > Thanks for everyones help. > > --- marcec@gmx.de wrote: > > From: Marc Joliet > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] /dev/snd/seq access mode and permission > Date: Fri, 17 Aug 2012 21:20:08 +0200 > > Am Fri, 17 Aug 2012 11:40:47 +0200 > schrieb Marc Joliet : > > > Am Fri, 17 Aug 2012 01:54:34 -0700 > > schrieb Cinder : > > > > > Hi, how do I make changes to permissions and access mode of device nodes persistent? At the moment I have to chown and chmod the /dev/snd/seq node every boot to make it accessible to my user. the other nodes are fine. Here's the output of ls -l /dev/snd/ > > > > > > total 0 > > > drwxr-xr-x 2 root root 60 Aug 17 18:44 by-path > > > crw-rw----+ 1 root audio 116, 12 Aug 17 18:44 controlC0 > > > crw-rw----+ 1 root audio 116, 11 Aug 17 18:44 hwC0D0 > > > crw-rw----+ 1 root audio 116, 10 Aug 17 18:44 hwC0D3 > > > crw-rw----+ 1 root audio 116, 9 Aug 17 18:44 hwC0D4 > > > crw-rw----+ 1 root audio 116, 8 Aug 17 18:44 hwC0D5 > > > crw-rw----+ 1 root audio 116, 7 Aug 17 18:44 pcmC0D0c > > > crw-rw----+ 1 root audio 116, 6 Aug 17 18:44 pcmC0D0p > > > crw-rw----+ 1 root audio 116, 5 Aug 17 18:44 pcmC0D1p > > > crw-rw----+ 1 root audio 116, 4 Aug 17 18:44 pcmC0D3p > > > crw-rw----+ 1 root audio 116, 3 Aug 17 18:44 pcmC0D7p > > > crw-rw----+ 1 root audio 116, 2 Aug 17 18:44 pcmC0D8p > > > crw------- 1 root root 116, 1 Aug 17 18:44 seq > > > crw-rw----+ 1 root audio 116, 33 Aug 17 18:44 timer > > > > > > I need /dev/snd/seq to look look the others. I can't find the udev rule or configuration that creates these nodes. Many thanks for any consideration. > > > > I have a hack for the same issue in my /etc/local.d/. A comment I put there > > says this: > > > > # this is caused by using devtmpfs, which creates nodes with root:root and 600; > > # I believe this is fixed by udev upstream > > > > So devtmpfs creates the device node before udev runs, but udev does not correct > > the access permissions, which is however fixed by udev upstream (perhaps > > already in ~arch?). Sadly I do not remember where I read this, but google should > > be of help there. > > Ah, yes, I did a quick search on b.g.o and found this: > > https://bugs.gentoo.org/show_bug.cgi?id=406871 > > So my comment is wrong, it doesn't have anything to do with devtmpfs, but udev > upstream did fix it :) . > > HTH