I worry that this is just adding more thrash to a historically unstable
implementation. How long do we users have to wait for a swsusp
implementation where we don't have to worry about breaking from one
kernel release to the next?
I agree with this post http://lkml.org/lkml/2005/9/15/125 and note that
making too large of a change thrashes the users a lot and if it doesn't
solve a real problem or enable something critical, why make the changes?
--mgross
>-----Original Message-----
>From: [email protected]
[mailto:[email protected]]
>On Behalf Of Pavel Machek
>Sent: Wednesday, November 16, 2005 12:56 AM
>To: Dave Jones; kernel list; Rafael J. Wysocki; Linux-pm mailing list
>Subject: Re: [linux-pm] [RFC] userland swsusp
>
>Hi!
>
>> > > Even it were not for this, the whole idea seems misconcieved to
me
>> > > anyway.
>> >
>> > ...but how do you provide nice, graphical progress bar for swsusp
>> > without this? People want that, and "esc to abort", compression,
>> > encryption. Too much to be done in kernel space, IMNSHO.
>>
>> I'll take "rootkit doesnt work" over "bells and whistles".
>
>It moves bunch of code from kernelspace to userspace. You don't have
>to add bells and whistles at the same time. That's normally called
>good thing. If Fedora has special needs, fine.
> Pavel
>--
>Thanks, Sharp!
On Wed, Nov 16, 2005 at 08:10:19AM -0800, Gross, Mark wrote:
> I worry that this is just adding more thrash to a historically unstable
> implementation. How long do we users have to wait for a swsusp
> implementation where we don't have to worry about breaking from one
> kernel release to the next?
Never, you are hereby consigned to always have a broken swsusp
implementation on your machines.
There, feel better? Or perhaps you could join in and help with the
current effort to make things better...
> I agree with this post http://lkml.org/lkml/2005/9/15/125 and note that
> making too large of a change thrashes the users a lot and if it doesn't
> solve a real problem or enable something critical, why make the changes?
Ok, so you are happy with what we currently have in the kernel tree
today? Great, use that, I know it works for me and I'm happy with it...
Please, everyone realize that Nigel's code is not going to be merged
into mainline as it is today. He knows it, and everyone else involved
knows it. Nigel also knows the proper procedure for getting his changes
into mainline, if he so desires, as we all sat in a room last July and
discussed this (lwn.net has a summary somewhere about it too...)
So, here's Pavel trying to make things better and people are complaining
about it. Argue that the technical points are invalid (like Dave did.)
But don't just sit around and kvetch, that doesn't help out anyone.
thanks,
greg k-h
Hi!
> I worry that this is just adding more thrash to a historically unstable
> implementation. How long do we users have to wait for a swsusp
> implementation where we don't have to worry about breaking from one
> kernel release to the next?
What unstable implementation? swsusp had very little regressions over past
year or so. Drivers were different story, but nothing changes w.r.t. drivers.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi.
On Thu, 2005-11-17 at 03:44, Greg KH wrote:
> Please, everyone realize that Nigel's code is not going to be merged
> into mainline as it is today. He knows it, and everyone else involved
> knows it. Nigel also knows the proper procedure for getting his changes
> into mainline, if he so desires, as we all sat in a room last July and
> discussed this (lwn.net has a summary somewhere about it too...)
Do you mean "as it was in July"? I haven't been sitting on my hands
since July :) My wife will testify to that!
I've been working on implementing the last new features I want in,
fixing bugs and generally making it as stable and reliable as I can.
(Sorry Andrew, but I'm being a perfectionist). At the same time, many of
the parts that made Suspend2 be considered huge and ugly have been
merged. The pm_message_t stuff, for example, was adopted early by
Suspend2 and part of those stats you saw in July. The patch currently
still includes the workqueue nofreeze patch, Christoph's todo list
freezer modifications. These account for virtually all of the changes
outside of kernel/power.
I've also split the one patch that most people see into what is
currently about 225 smaller patches, each adding only one small part, am
writing descriptions for them all and am preparing to build a git tree
from it.
Hopefully that shows that I am working toward merging, just maybe not in
the way that you were imagining. You'll remember that I've argued before
that trying to patch swsusp into Suspend2 is infeasible. I'm not even
trying to do it.
Regards,
Nigel
> So, here's Pavel trying to make things better and people are complaining
> about it. Argue that the technical points are invalid (like Dave did.)
> But don't just sit around and kvetch, that doesn't help out anyone.
>
> thanks,
>
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Hi!
> > Please, everyone realize that Nigel's code is not going to be merged
> > into mainline as it is today. He knows it, and everyone else involved
> > knows it. Nigel also knows the proper procedure for getting his changes
> > into mainline, if he so desires, as we all sat in a room last July and
> > discussed this (lwn.net has a summary somewhere about it too...)
>
> Do you mean "as it was in July"? I haven't been sitting on my hands
> since July :) My wife will testify to that!
...
> I've also split the one patch that most people see into what is
> currently about 225 smaller patches, each adding only one small part, am
> writing descriptions for them all and am preparing to build a git tree
> from it.
I'm not sure that gets suspend2 any closer to merging. 225 small
patches is still awful lot of code :-(. Now... if something can be
done in userspace, it probably should. And I'm trying to show that
suspend2 functionality can indeed be done in userspace.
So... to get 225 patches in, you'll need to explain that
userland-swsusp can't work. If you can do that, please be nice and do
it soon, so that I don't waste too much time on userland-swsusp.
Pavel
--
Thanks, Sharp!
Hi.
On Thu, 2005-11-17 at 09:05, Pavel Machek wrote:
> Hi!
>
> > > Please, everyone realize that Nigel's code is not going to be merged
> > > into mainline as it is today. He knows it, and everyone else involved
> > > knows it. Nigel also knows the proper procedure for getting his changes
> > > into mainline, if he so desires, as we all sat in a room last July and
> > > discussed this (lwn.net has a summary somewhere about it too...)
> >
> > Do you mean "as it was in July"? I haven't been sitting on my hands
> > since July :) My wife will testify to that!
> ...
> > I've also split the one patch that most people see into what is
> > currently about 225 smaller patches, each adding only one small part, am
> > writing descriptions for them all and am preparing to build a git tree
> > from it.
>
> I'm not sure that gets suspend2 any closer to merging. 225 small
> patches is still awful lot of code :-(. Now... if something can be
> done in userspace, it probably should. And I'm trying to show that
> suspend2 functionality can indeed be done in userspace.
>
> So... to get 225 patches in, you'll need to explain that
> userland-swsusp can't work. If you can do that, please be nice and do
> it soon, so that I don't waste too much time on userland-swsusp.
I thought Dave already did that.
Regards,
Nigel
On Thu, Nov 17, 2005 at 07:20:45AM +1100, Nigel Cunningham wrote:
>
> I've also split the one patch that most people see into what is
> currently about 225 smaller patches, each adding only one small part, am
> writing descriptions for them all and am preparing to build a git tree
> from it.
That's great, I didn't know you were doing this.
I'd recommend using quilt instead of git for something like this,
because the odds that you will need to change something in patch number
132 out of 225 is pretty good :)
thanks,
greg k-h
Hi.
On Thu, 2005-11-17 at 09:10, Greg KH wrote:
> On Thu, Nov 17, 2005 at 07:20:45AM +1100, Nigel Cunningham wrote:
> >
> > I've also split the one patch that most people see into what is
> > currently about 225 smaller patches, each adding only one small part, am
> > writing descriptions for them all and am preparing to build a git tree
> > from it.
>
> That's great, I didn't know you were doing this.
>
> I'd recommend using quilt instead of git for something like this,
> because the odds that you will need to change something in patch number
> 132 out of 225 is pretty good :)
Yeah. :) I actually wrote my own 'makepatch' script long before I ever
heard of quilt, and am still using that. It lets me do the same sort of
thing. Unfortunately I tend to accumulate further changes at the end of
the series and then have to shift them back into the right place. It
would be nice to be able to automate that :)
Nigel
Hi,
On Wednesday, 16 of November 2005 22:13, Nigel Cunningham wrote:
> On Thu, 2005-11-17 at 09:05, Pavel Machek wrote:
}-- snip --{
> > So... to get 225 patches in, you'll need to explain that
> > userland-swsusp can't work. If you can do that, please be nice and do
> > it soon, so that I don't waste too much time on userland-swsusp.
>
> I thought Dave already did that.
Not as far as I'm concerned. He criticised the implementation,
which I generally agree with, but IMO the overall idea is not wrong.
BTW, you don't need to export the page flags, use /dev/kmem etc. to implement
it. The only concern that I have wrt it is the writing of the image _after_ the
system has been snapshotted.
Greetings,
Rafael
Hi!
> > > I've also split the one patch that most people see into what is
> > > currently about 225 smaller patches, each adding only one small part, am
> > > writing descriptions for them all and am preparing to build a git tree
> > > from it.
> >
> > I'm not sure that gets suspend2 any closer to merging. 225 small
> > patches is still awful lot of code :-(. Now... if something can be
> > done in userspace, it probably should. And I'm trying to show that
> > suspend2 functionality can indeed be done in userspace.
> >
> > So... to get 225 patches in, you'll need to explain that
> > userland-swsusp can't work. If you can do that, please be nice and do
> > it soon, so that I don't waste too much time on userland-swsusp.
>
> I thought Dave already did that.
No, I do not think so. He did not like the user<->kernel interface;
but that can be changed (and Rafael has plans to do that). I think we
can present nicer interface to userland without much code. Or maybe
not; but we can certainly limit /dev/kmem for suspend only -- and that
should make it acceptable security-wise.
Pavel
--
Thanks, Sharp!
On Thu, 2005-11-17 at 08:25 +1100, Nigel Cunningham wrote:
> Hi.
>
> On Thu, 2005-11-17 at 09:10, Greg KH wrote:
> > On Thu, Nov 17, 2005 at 07:20:45AM +1100, Nigel Cunningham wrote:
> > >
> > > I've also split the one patch that most people see into what is
> > > currently about 225 smaller patches, each adding only one small part, am
> > > writing descriptions for them all and am preparing to build a git tree
> > > from it.
> >
> > That's great, I didn't know you were doing this.
> >
> > I'd recommend using quilt instead of git for something like this,
> > because the odds that you will need to change something in patch number
> > 132 out of 225 is pretty good :)
>
> Yeah. :) I actually wrote my own 'makepatch' script long before I ever
> heard of quilt, and am still using that. It lets me do the same sort of
> thing. Unfortunately I tend to accumulate further changes at the end of
> the series and then have to shift them back into the right place. It
> would be nice to be able to automate that :)
patch-utils have a 'movepatch' option... which flips 2 patches in order,
even when they overlap.
On Wed, Nov 16, 2005 at 07:10:52PM +0000, Pavel Machek wrote:
> What unstable implementation? swsusp had very little regressions over past
> year or so. Drivers were different story, but nothing changes w.r.t. drivers.
Do you mean swsusp is actually supposed to work? Suspend-to-ram,
suspend-to-disk or both?
OG.
On Thu, Nov 17, 2005 at 05:54:37PM +0100, Olivier Galibert wrote:
> On Wed, Nov 16, 2005 at 07:10:52PM +0000, Pavel Machek wrote:
> > What unstable implementation? swsusp had very little regressions over past
> > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
>
> Do you mean swsusp is actually supposed to work? Suspend-to-ram,
> suspend-to-disk or both?
Both. -to-ram depends on your video chip, but to-disk should work just
fine. If not, please report bugs.
thanks,
greg k-h
On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> Now... if something can be
> done in userspace, it probably should.
And that usually means it just isn't done. Cases in point:
multichannel audio software mixing, video pixel formats conversion.
OG.
On Thu, 17 Nov 2005, Greg KH wrote:
> On Thu, Nov 17, 2005 at 05:54:37PM +0100, Olivier Galibert wrote:
> > On Wed, Nov 16, 2005 at 07:10:52PM +0000, Pavel Machek wrote:
> > > What unstable implementation? swsusp had very little regressions over past
> > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> >
> > Do you mean swsusp is actually supposed to work? Suspend-to-ram,
> > suspend-to-disk or both?
>
> Both. -to-ram depends on your video chip, but to-disk should work just
> fine. If not, please report bugs.
swsusp has nothing to do with suspend-to-ram. swsusp is a
platform-independent implementation of suspend-to-disk. STR is
very-platform dependent. Please see the file:
Documentation/power/states.txt
for more info.
Pat
On Thu, Nov 17, 2005 at 08:44:51AM -0800, Greg KH wrote:
> Both. -to-ram depends on your video chip,
i855GM with xorg-6.8.2 (-r6 gentoo) ?
i830CGC with xorg-6.8.2 (-r4 gentoo) ?
> but to-disk should work just fine.
Ok.
> If not, please report bugs.
I shall.
Is the acpi problem with PWRF used over PWRC and PWRF not sending
events (hence no wakeup) solved?
OG.
On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
> On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> > Now... if something can be
> > done in userspace, it probably should.
>
> And that usually means it just isn't done. Cases in point:
> multichannel audio software mixing, video pixel formats conversion.
What are you talking about? ALSA does mixing in userspace, it works
great.
Lee
Greg KH wrote:
> > > What unstable implementation? swsusp had very little regressions over past
> > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> > Do you mean swsusp is actually supposed to work? Suspend-to-ram,
> > suspend-to-disk or both?
> Both. -to-ram depends on your video chip, but to-disk should work just
> fine. If not, please report bugs.
Thanks, I've just realized, that I probably forgot to CC anyone last time...
:)
So, may I kindly ask to look on:
http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1863.html ?
Thanks!
--
Jacek Kawa
On Thu, Nov 17, 2005 at 02:57:11PM -0500, Lee Revell wrote:
> On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
> > On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> > > Now... if something can be
> > > done in userspace, it probably should.
> >
> > And that usually means it just isn't done. Cases in point:
> > multichannel audio software mixing, video pixel formats conversion.
>
> What are you talking about? ALSA does mixing in userspace, it works
> great.
You have an interesting definition of "great".
1- It doesn't work without an annoyingly complex, extremely badly
documented user configuration. To the point that it doesn't work in
either an out-of-the-box, updated Fedora Core 3 nor an
out-of-the-box gentoo.
2- It doesn't work for programs that do not use the annoyingly complex
and horribly documented alsa library, which includes everything
that still uses OSS[1].
You call that great? Multiple audio streams is such a basic feature
it should work, period. No if, no buts, and no obligatory library.
Which doesn't preclude having it in userspace, mind you. But it
should never have been the _application_'s responsability.
OG.
[1] Which is so easier to use for normal programs' audio it's not
funny.
On Thu, 2005-11-17 at 21:12 +0100, Olivier Galibert wrote:
> On Thu, Nov 17, 2005 at 02:57:11PM -0500, Lee Revell wrote:
> > On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
> > > On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> > > > Now... if something can be
> > > > done in userspace, it probably should.
> > >
> > > And that usually means it just isn't done. Cases in point:
> > > multichannel audio software mixing, video pixel formats conversion.
> >
> > What are you talking about? ALSA does mixing in userspace, it works
> > great.
>
> You have an interesting definition of "great".
>
> 1- It doesn't work without an annoyingly complex, extremely badly
> documented user configuration. To the point that it doesn't work in
> either an out-of-the-box, updated Fedora Core 3 nor an
> out-of-the-box gentoo.
>
File a bug report with your distro then. This is supposed to work OOTB.
> 2- It doesn't work for programs that do not use the annoyingly complex
> and horribly documented alsa library, which includes everything
> that still uses OSS[1].
>
There's plenty of ALSA documentation. Anyway mixing for OSS apps does
work, they just have to use the aoss wrapper.
Lee
On Thu, Nov 17, 2005 at 03:20:55PM -0500, Lee Revell wrote:
> On Thu, 2005-11-17 at 21:12 +0100, Olivier Galibert wrote:
> > On Thu, Nov 17, 2005 at 02:57:11PM -0500, Lee Revell wrote:
> > > On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
> > > > On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> > > > > Now... if something can be
> > > > > done in userspace, it probably should.
> > > >
> > > > And that usually means it just isn't done. Cases in point:
> > > > multichannel audio software mixing, video pixel formats conversion.
> > >
> > > What are you talking about? ALSA does mixing in userspace, it works
> > > great.
> >
> > You have an interesting definition of "great".
> >
> > 1- It doesn't work without an annoyingly complex, extremely badly
> > documented user configuration. To the point that it doesn't work in
> > either an out-of-the-box, updated Fedora Core 3 nor an
> > out-of-the-box gentoo.
>
> File a bug report with your distro then. This is supposed to work OOTB.
I don't know about other distros, but here's how that usually goes for Fedora users..
1. user installs new release, and sound doesn't work.
2. user blames ALSA, bug gets filed against kernel.
3. I take a look, sometimes we get to play "ping pong the bug between
userspace & kernel component" for a while
4. I throw my hands in the air and say "tell the upstream ALSA developers"
5. user does so
6. user comes back to Fedora bugzilla with the response
"Alsa people told me its a Fedora bug".
So, given we ship unpatched[1] ALSA, my faith in the
possibility of ALSA working "OOTB" is somewhat lacking.
These bugs usually sit in our bugzilla, every so often
I'll ping them after I've rebased to a new release, and
surprise surprise, they magically get fixed.
(Although every release we seem to trade one set of
working sound drivers for a new set of broken ones).
Colour me jaded.
Dave
[1] kernel sound/ is unpatched. alsa-utils is unpatched. alsa-lib carries
one patch from alsa cvs.
On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> I don't know about other distros, but here's how that usually goes for Fedora users..
>
> 1. user installs new release, and sound doesn't work.
> 2. user blames ALSA, bug gets filed against kernel.
> 3. I take a look, sometimes we get to play "ping pong the bug between
> userspace & kernel component" for a while
> 4. I throw my hands in the air and say "tell the upstream ALSA developers"
> 5. user does so
> 6. user comes back to Fedora bugzilla with the response
> "Alsa people told me its a Fedora bug".
>
> So, given we ship unpatched[1] ALSA, my faith in the
> possibility of ALSA working "OOTB" is somewhat lacking.
>
> These bugs usually sit in our bugzilla, every so often
> I'll ping them after I've rebased to a new release, and
> surprise surprise, they magically get fixed.
> (Although every release we seem to trade one set of
> working sound drivers for a new set of broken ones).
The process would work a lot faster if the Fedora project would
contribute anything at all to ALSA development. It's a lot of work! I
haven't seen a line of sound driver code from anyone at Red Hat since
the OSS->ALSA transition, years ago. Meanwhile the vendors keep getting
cheaper and cheaper, which means more functionality that used to be in
hardware has to be done in the drivers.
For example the Debian people are very helpful, they have someone who
filters out the real bug reports from their users and pushes them into
the ALSA bug tracker. Fedora just points clueless users at the ALSA bug
tracker and tells them "good luck".
Lee
On Thu, 2005-11-17 at 21:12 +0100, Olivier Galibert wrote:
> You call that great? Multiple audio streams is such a basic feature
> it should work, period. No if, no buts, and no obligatory library.
> Which doesn't preclude having it in userspace, mind you. But it
> should never have been the _application_'s responsability.
Um, it really belongs in HARDWARE like it used to be, but vendors are
way too cheap for that now. Keep in mind the whole mixing discussion
amounts to "how do we deal with these broken devices".
Lee
On Thu, 2005-11-17 at 21:12 +0100, Olivier Galibert wrote:
> 1- It doesn't work without an annoyingly complex, extremely badly
> documented user configuration. To the point that it doesn't work in
> either an out-of-the-box, updated Fedora Core 3 nor an
> out-of-the-box gentoo.
It's badly documented and complex because .asoundrc was never intended
to be user visible. If the end user ever needs to edit their ALSA
config files for a standard setup there's a bug somewhere.
Anyway please provide the details of your sound hardware and ALSA driver
& alsa-lib version so we can determine why software mixing does not work
for you.
Lee
On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> (Although every release we seem to trade one set of
> working sound drivers for a new set of broken ones).
Because the ALSA project does not have access to the wide variety of
hardware required to regression test every sound driver change. People
like Red Hat and OSDL do, but they don't help. I always figured that
this was because those entities consider audio support a low priority.
Lee
On Thu, Nov 17, 2005 at 03:46:07PM -0500, Lee Revell wrote:
> The process would work a lot faster if the Fedora project would
> contribute anything at all to ALSA development. It's a lot of work! I
> haven't seen a line of sound driver code from anyone at Red Hat since
> the OSS->ALSA transition, years ago.
Sorry, but that's complete uninformed bullshit.
Dave
On Thu, Nov 17, 2005 at 03:54:11PM -0500, Lee Revell wrote:
> On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> > (Although every release we seem to trade one set of
> > working sound drivers for a new set of broken ones).
>
> Because the ALSA project does not have access to the wide variety of
> hardware required to regression test every sound driver change. People
> like Red Hat and OSDL do, but they don't help.
Maybe you could let me know where we keep all that hardware ?
I'd really like to know, and you seem more informed on what
Red Hat have/do than I am.
Perhaps you could tell the OSDL people too.
Thanks,
Dave
* Lee Revell ([email protected]) wrote:
> On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> > (Although every release we seem to trade one set of
> > working sound drivers for a new set of broken ones).
>
> Because the ALSA project does not have access to the wide variety of
> hardware required to regression test every sound driver change. People
> like Red Hat and OSDL do, but they don't help. I always figured that
> this was because those entities consider audio support a low priority.
Haven't seen these heaps of audio hardware yet. It's not an audio only
issue, it's pervasive across many device classes. And hardware alone is
not quite sufficient. Need ability to automate testing as well.
Dave Jones <[email protected]> wrote:
> I don't know about other distros, but here's how that usually goes for Fedora users..
It Works in Ubuntu(TM)[0]. More seriously: recent alsa-libs should
provide a pile of stuff in /usr/share/alsa/cards which switches dmix on
by default in most cards[1]. Obviously, for this to work usefully, your
application needs to be using libalsa (either natively or using the aoss
wrapper).
[0] The only patch is to enable symbol versioning
[1] Not ones with hardware mixing
--
Matthew Garrett | [email protected]
On Thu, 2005-11-17 at 13:06 -0800, Chris Wright wrote:
> * Lee Revell ([email protected]) wrote:
> > On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> > > (Although every release we seem to trade one set of
> > > working sound drivers for a new set of broken ones).
> >
> > Because the ALSA project does not have access to the wide variety of
> > hardware required to regression test every sound driver change. People
> > like Red Hat and OSDL do, but they don't help. I always figured that
> > this was because those entities consider audio support a low priority.
>
> Haven't seen these heaps of audio hardware yet. It's not an audio only
> issue, it's pervasive across many device classes. And hardware alone is
> not quite sufficient. Need ability to automate testing as well.
>
OK I should not single out Red Hat or OSDL, it just seems like we get a
lot more general gripes about ALSA regressions than we see good bug
reports. All I am saying is that maybe someone from a distro with
access to bug reports from a huge user base has some ideas for how we
could better deal with these regressions. The ALSA project does not get
many good bug reports because we are farther from the users.
Lee
On Thu, 2005-11-17 at 21:09 +0000, Matthew Garrett wrote:
> Dave Jones <[email protected]> wrote:
>
> > I don't know about other distros, but here's how that usually goes for Fedora users..
>
> It Works in Ubuntu(TM)[0]. More seriously: recent alsa-libs should
> provide a pile of stuff in /usr/share/alsa/cards which switches dmix on
> by default in most cards[1]. Obviously, for this to work usefully, your
> application needs to be using libalsa (either natively or using the aoss
> wrapper).
>
> [0] The only patch is to enable symbol versioning
> [1] Not ones with hardware mixing
[1] is already done for most of the hardware that needs it. No user
configuration at all should be required. Please, let us know if you
find a device it does not work that way for.
Lee
* Lee Revell ([email protected]) wrote:
> OK I should not single out Red Hat or OSDL, it just seems like we get a
> lot more general gripes about ALSA regressions than we see good bug
> reports. All I am saying is that maybe someone from a distro with
> access to bug reports from a huge user base has some ideas for how we
> could better deal with these regressions. The ALSA project does not get
> many good bug reports because we are farther from the users.
Yeah, bad bug reports are indeed a pain. One thing that may help ALSA is
more frequent merging with mainline. Then the delta between ALSA cvs
(and hence ALSA developers) and mainline (users) is smaller.
El Thu, 17 Nov 2005 13:18:56 -0800,
Chris Wright <[email protected]> escribi?:
> Yeah, bad bug reports are indeed a pain. One thing that may help ALSA is
> more frequent merging with mainline. Then the delta between ALSA cvs
> (and hence ALSA developers) and mainline (users) is smaller.
What about using kernel's bugzilla? Alsa has a (weird) bug tracker but
some people reports bugs in bugzilla.kernel.org aswell (just a suggestion,
it seems weird to have two places to report bugs and I bet that's not good
for users)
On Thu, Nov 17, 2005 at 09:15:09PM +0100, Jacek Kawa wrote:
> Greg KH wrote:
>
> > > > What unstable implementation? swsusp had very little regressions over past
> > > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> > > Do you mean swsusp is actually supposed to work? Suspend-to-ram,
> > > suspend-to-disk or both?
> > Both. -to-ram depends on your video chip, but to-disk should work just
> > fine. If not, please report bugs.
>
> Thanks, I've just realized, that I probably forgot to CC anyone last time...
> :)
>
> So, may I kindly ask to look on:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1863.html ?
Care to file this in bugzilla.kernel.org and assign it to Pavel?
thanks,
greg k-h
Greg KH wrote;
> > > > > What unstable implementation? swsusp had very little regressions over past
> > > > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> > > > Do you mean swsusp is actually supposed to work? Suspend-to-ram,
> > > > suspend-to-disk or both?
> > > Both. -to-ram depends on your video chip, but to-disk should work just
> > > fine. If not, please report bugs.
> > Thanks, I've just realized, that I probably forgot to CC anyone last time...
> > :)
> > So, may I kindly ask to look on:
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1863.html ?
> Care to file this in bugzilla.kernel.org and assign it to Pavel?
Sure :)
http://bugzilla.kernel.org/show_bug.cgi?id=5626
Thanks
--
Jacek Kawa
Hi!
> > What unstable implementation? swsusp had very little regressions over past
> > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
>
> Do you mean swsusp is actually supposed to work? Suspend-to-ram,
> suspend-to-disk or both?
Read the docs. swsusp is suspend-to-disk, of course.
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms