| Submitter | Joshua Lock |
|---|---|
| Date | Jan. 13, 2012, 7:10 p.m. |
| Message ID | <cover.1326481387.git.josh@linux.intel.com> |
| Download | mbox |
| Permalink | /patch/19341/ |
| State | New |
| Headers | show |
Pull-request
git://git.openembedded.org/openembedded-core-contrib josh/devicesComments
On 01/13/2012 11:10 AM, Joshua Lock wrote: > The small series which follows introduces the alsa-state recipe from oe-classic. > The reason for doing so is to remove the requirement for recipes like the > beagleboard-audio recipe in meta-yocto, which ensures the beagleboards sound > device has the volume turned up. > > Long term I'd like to implement something more generic for handling device > quirks, but alsa-state is a simple fix for an immediate need that should > standardise how alsa configuration is handled in layers. > > Since v1 I added an extra commit which: > a) defaults to /var/lib/alsa/ for state files, as this is the directory > alsactl writes to by default. > b) sed's the path to the state files into the init script, rather than hard > coding them. > > Since v2 I've modified the task-base commit to add VIRTUAL-RUNTIME_alsa-state > rather than hard code the alsa-state recipe per suggestion from Martin Jansa > and added an extra commit to move the defintion of VIRTUAL-RUNTIME_apm from > task-base to default-providers.inc > > Cheers, > > Joshua > > The following changes since commit bd047935305c872b565f30b46c94b7077e5fb3a2: > > patch.bbclass: Ensure the DATE and SRCDATE variable exclusions apply to the correct function (2012-01-13 16:56:20 +0000) > > are available in the git repository at: > git://git.openembedded.org/openembedded-core-contrib josh/devices > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/devices > > Joshua Lock (4): > task-base: move default definition of VIRTUAL-RUNTIME_apm > alsa-state: add alsa-state from oe classic > alsa-state: move state files to localstatedir > task-base: add VIRTUAL-RUNTIME_alsa-state to task-base-alsa > > meta/conf/distro/include/default-providers.inc | 2 + > meta/recipes-bsp/alsa-state/alsa-state.bb | 59 ++++++++++++++++++++ > meta/recipes-bsp/alsa-state/alsa-state/alsa-state | 29 ++++++++++ > meta/recipes-bsp/alsa-state/alsa-state/asound.conf | 12 ++++ > .../recipes-bsp/alsa-state/alsa-state/asound.state | 1 + > meta/recipes-core/tasks/task-base.bb | 8 +-- > 6 files changed, 106 insertions(+), 5 deletions(-) > create mode 100644 meta/recipes-bsp/alsa-state/alsa-state.bb > create mode 100755 meta/recipes-bsp/alsa-state/alsa-state/alsa-state > create mode 100644 meta/recipes-bsp/alsa-state/alsa-state/asound.conf > create mode 100644 meta/recipes-bsp/alsa-state/alsa-state/asound.state > Merged into OE-Core Thanks Sau!
Op 13 jan. 2012, om 20:10 heeft Joshua Lock het volgende geschreven: > The small series which follows introduces the alsa-state recipe from oe-classic. > The reason for doing so is to remove the requirement for recipes like the > beagleboard-audio recipe in meta-yocto, which ensures the beagleboards sound > device has the volume turned up. > > Long term I'd like to implement something more generic for handling device > quirks, but alsa-state is a simple fix for an immediate need that should > standardise how alsa configuration is handled in layers. FWIW, alsa-lib itself includes initscripts to do this. I dropped asound.state in /var/lib/alsa and it just worked since alsactl also installs systemd units to handle this. So alsa-state can just hold the config files and drop the initscripts by the looks of it. regards, Koen
On 24/01/12 07:02, Koen Kooi wrote: > > Op 13 jan. 2012, om 20:10 heeft Joshua Lock het volgende geschreven: > >> The small series which follows introduces the alsa-state recipe from oe-classic. >> The reason for doing so is to remove the requirement for recipes like the >> beagleboard-audio recipe in meta-yocto, which ensures the beagleboards sound >> device has the volume turned up. >> >> Long term I'd like to implement something more generic for handling device >> quirks, but alsa-state is a simple fix for an immediate need that should >> standardise how alsa configuration is handled in layers. > > FWIW, alsa-lib itself includes initscripts to do this. I dropped asound.state in /var/lib/alsa and it just worked since alsactl also installs systemd units to handle this. So alsa-state can just hold the config files and drop the initscripts by the looks of it. Thanks for raising this, I hadn't seen that alsa-utils provides some extras with alsactl. Taking a quick look I see that they ship systemd units for state save and restore and a udev rule for restoring the state. I can't see any initscript, so I think switching to what's provided by alsa-utils would mean losing state saving for non-systemd folk but systemd users can probably just set VIRTUAL-RUNTIME_alsa-state = "alsa-utils-alsactl". I am an alsa newb so if I'm missing something please point me at it. Cheers, Joshua
On Tue, Jan 24, 2012 at 21:15, Joshua Lock <josh@linux.intel.com> wrote: > I can't see any initscript, so I think switching to what's provided by > alsa-utils would mean losing state saving for non-systemd folk but systemd > users can probably just set VIRTUAL-RUNTIME_alsa-state = > "alsa-utils-alsactl". > You still needs the state. So I think we'd need to have a specific -systemd version of it when the configs and the units.
Op 27 jan. 2012, om 00:09 heeft Otavio Salvador het volgende geschreven: > On Tue, Jan 24, 2012 at 21:15, Joshua Lock <josh@linux.intel.com> wrote: > I can't see any initscript, so I think switching to what's provided by alsa-utils would mean losing state saving for non-systemd folk but systemd users can probably just set VIRTUAL-RUNTIME_alsa-state = "alsa-utils-alsactl". > > You still needs the state. So I think we'd need to have a specific -systemd version of it when the configs and the units. I was thinking of splitting the existing recipe into alsa-state-conf for the conf files and keep the init stuff in ${PN}. As a follow on patch we can have alsa-utils-alsactl RRECOMMEND alsa-state-conf. thoughts? regards, Koen
On 27/01/12 00:00, Koen Kooi wrote: > > Op 27 jan. 2012, om 00:09 heeft Otavio Salvador het volgende geschreven: > >> On Tue, Jan 24, 2012 at 21:15, Joshua Lock<josh@linux.intel.com> wrote: >> I can't see any initscript, so I think switching to what's provided by alsa-utils would mean losing state saving for non-systemd folk but systemd users can probably just set VIRTUAL-RUNTIME_alsa-state = "alsa-utils-alsactl". >> >> You still needs the state. So I think we'd need to have a specific -systemd version of it when the configs and the units. Quite right, we should separate the state files. I wasn't thinking straight there. > > I was thinking of splitting the existing recipe into alsa-state-conf for the conf files and keep the init stuff in ${PN}. As a follow on patch we can have alsa-utils-alsactl RRECOMMEND alsa-state-conf. > > thoughts? Sounds good to me. I'd like to see what Martin thinks, as he rose the initial concern re: the VIRTUAL_RUNTIME. Hopefully SHR would also like the state files separate and more centrally maintained. Cheers, Joshua