help On Fri, Feb 13, 2009 at 5:00 AM, <[email protected] > wrote:
> Send openmoko-kernel mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openmoko.org/mailman/listinfo/openmoko-kernel > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openmoko-kernel digest..." > > Today's Topics: > > 1. vchanneld (Michael Trimarchi) > 2. Re:Openmoko Bug #1744: Bluetooth don't power up after suspend > (Openmoko Public Trac) > 3. Re:[android-freerunner] vchanneld (Michael Trimarchi) > 4. Re:Openmoko Bug #2180: stable-tracking: 'rxserr' UART > messages (Openmoko Public Trac) > 5. Re:[gta02] Correct alsastatefile fits all Neos (Mark Brown) > > > ---------- Forwarded message ---------- > From: Michael Trimarchi <[email protected]> > To: Android on Freerunner Development < > [email protected]> > Date: Fri, 13 Feb 2009 09:11:56 +0100 > Subject: vchanneld > Hi all, > > I write a daemon like gsmmuxd that virtualize the serial driver and export > a series of terminal for > the rild service, gprs service etc. The rild service start using the > /dev/pts/0 terminal. I grant it to him > when the channel is ready. The daemon is not releated to the rild, it just > give an openchannel. I don't > use an extra channel for unsolicited command, because the android ril don't > use it, but I suppose that a > gprs connection can be initialize on /dev/pts/xxx. Only one question just > to know: > > Have I some license problem if I use a separate daemon for multiplexing? > > Michael > > > > > ---------- Forwarded message ---------- > From: "Openmoko Public Trac" <[email protected]> > To: > Date: Fri, 13 Feb 2009 09:05:16 -0000 > Subject: Re: Openmoko Bug #1744: Bluetooth don't power up after suspend > #1744: Bluetooth don't power up after suspend > > -----------------------------+---------------------------------------------- > Reporter: VDVsx | Owner: openmoko-kernel > Type: defect | Status: assigned > Priority: normal | Milestone: > Component: System Software | Version: GTA02v6 > Severity: normal | Keywords: > Haspatch: 0 | Blockedby: > Estimated: | Patchreview: > Blocking: | Reproducible: > > -----------------------------+---------------------------------------------- > > Comment(by TimoJyrinki): > > This is still an issue in the current stable (2.6.29, quite close to andy- > tracking AFAIK). > > -- > Ticket URL: <https://docs.openmoko.org/trac/ticket/1744#comment:6> > docs.openmoko.org <http://docs.openmoko.org/trac/> > openmoko trac > > > ---------- Forwarded message ---------- > From: Michael Trimarchi <[email protected]> > To: Android on Freerunner Development < > [email protected]> > Date: Fri, 13 Feb 2009 10:17:04 +0100 > Subject: Re: [android-freerunner] vchanneld > Hi, > > David Hicks wrote: > >> >> Michael - if we're talking about that library that came round the other >> day, then probably no problem. If the work originated in Qtopia, and is >> subject to the GPL 2/3 with the extra exemptions, then you're fine. >> > Thanks Michael > > > > > ---------- Forwarded message ---------- > From: "Openmoko Public Trac" <[email protected]> > To: > Date: Fri, 13 Feb 2009 10:44:58 -0000 > Subject: Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART messages > #2180: stable-tracking: 'rxserr' UART messages > > -----------------------------+---------------------------------------------- > Reporter: laforge | Owner: openmoko-kernel > Type: defect | Status: new > Priority: high | Milestone: FSO > Component: System Software | Version: > Severity: major | Keywords: gps s3x24xx_serial rxerr > Haspatch: 0 | Blockedby: > Estimated: | Patchreview: > Blocking: | Reproducible: > > -----------------------------+---------------------------------------------- > > Comment(by Sascha): > > I flashed moko11 beta 1 and the errors in my test case are gone :) > > -- > Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:22> > docs.openmoko.org <http://docs.openmoko.org/trac/> > openmoko trac > > > ---------- Forwarded message ---------- > From: Mark Brown <[email protected]> > To: Joerg Reisenweber <[email protected]> > Date: Fri, 13 Feb 2009 10:51:21 +0000 > Subject: Re: [gta02] Correct alsastatefile fits all Neos > On Fri, Feb 13, 2009 at 06:43:32AM +0100, Joerg Reisenweber wrote: > > > First step would be the name of alsa soundcard devicedriver should > represent > > the differences in hardware. > > That should already be the case, hopefully. > > > Next we could think about a straight way to make alsamixer, alsactl etc > use > > the right alsa.state file (section?) matching the actually loaded > > devicedriver. > > Probably all you need here is to have the config files stored separately > and then set up a symlink pointing at those for the particular device > during boot. At runtime everything just uses the symlink. > > > usually is done via `amixer` cmd. A script comprising a number of amixer > cmds > > would be an alternative way to `alsactl -f scenario.state restore` for > > setting up a mixer route. Advantage would be you could overlap multiple > such > > settings as each script leaves controls untouched that are not involved > in > > the particular setting. > > The secenario API at: > > http://www.slimlogic.co.uk/?p=40 > > is still under development but it's intended to help address issues like > this. It will also deal with things like allowing applications to know > which controls should be presented to end user applications. > > > > _______________________________________________ > openmoko-kernel mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/openmoko-kernel > > -- Sashi
