unsubscribe
Sashi
jsashikala at gmail.com
Fri Feb 13 14:44:32 CET 2009
help
On Fri, Feb 13, 2009 at 5:00 AM, <openmoko-kernel-request at lists.openmoko.org
> wrote:
> Send openmoko-kernel mailing list submissions to
> openmoko-kernel at lists.openmoko.org
>
> 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
> openmoko-kernel-request at lists.openmoko.org
>
> You can reach the person managing the list at
> openmoko-kernel-owner at lists.openmoko.org
>
> 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 <trimarchi at gandalf.sssup.it>
> To: Android on Freerunner Development <
> android-freerunner at android.koolu.org>
> 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" <bugs at docs.openmoko.org>
> 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 <trimarchi at gandalf.sssup.it>
> To: Android on Freerunner Development <
> android-freerunner at android.koolu.org>
> 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" <bugs at docs.openmoko.org>
> 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 <broonie at opensource.wolfsonmicro.com>
> To: Joerg Reisenweber <joerg at openmoko.org>
> 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
> openmoko-kernel at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/openmoko-kernel
>
>
--
Sashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20090213/dd090706/attachment-0001.htm
More information about the openmoko-kernel
mailing list
