On Fri, 2009-06-26 at 15:29 -0400, Devin Heitmueller wrote: > On Fri, Jun 26, 2009 at 3:02 PM, Andy Walls<awalls@xxxxxxxxx> wrote: > > All I'm saying is that it is obviously the expected behavior, it the > > specified behavior, and all the userland apps and scripts are written > > with that behavior in mind. > > > > The applications' expectation of that behavior is, of course, why we are > > having this discussion. > > > > Assuming arguendo, maintaing state in the face of power management is a > > hard requirement on the driver; I'll still contend it's harder to change > > the existing base of applications and user scripts. Until the spec and > > all the existing apps change, not adhering to the spec leads to user > > confusion. > > I guess that means that every product that has a tuner which > implements the sleep callback is broken. And yet this is the first > case I've heard a user complain, which makes me wonder how big a > population is out there that is using scripts to control the tuner. I > suspect most people are just using applications like MythTV, xawtv or > tvtime, which won't have these issues. > I don't intend to come across as argumentative, but if we haven't > heard a massive outcry about this by now, maybe nobody actually cares > and thus we shouldn't spend the time to build a whole infrastructure > to preserve the driver state across the low power mode. Devin, I'm not saying we need to fix every broken tuner driver. I would suggest, however, that if you fix the one at hand, you will provide a template which others could follow as the problem crops up with other devices. > Those people > who really do care can just disable the power management with a > modprobe option. I doubt you'll here a massive outcry, as most users use a large monlithic application (e.g. MyhtTV) that keep at least two device nodes open, so even if they momentarily close one, it doesn't matter. Where it hurts not to preserve state is for: 1. development and troubleshooting - small tools that do one thing and can do them in whatever order you want simply are really nice to have work. In this thread I've seen a user trying to troubleshoot being affected by not preserving state. 2. user work arounds or conveniences - a small tool used in a script to twiddle a device setting. Preserving state is often *not* used for saving the last tuned frequency, but for other things like the last used input, volume level, VBI settings, etc. As I wave the V4L2 spec around like a blind follower of some sacred law, I'm begin to feel like Piggy clinging to the conch shell in _The_Lord_of_the_Flies_ , so.... If you think the V4L2 spec is bad, then propose a modification in writing (an RFC) that you think makes sense. Propose exceptions for tuners and/or power management. I'm not trying to be argumentative either. I guess I'm just not a big fan of "kicking the can down the road". We all bear the burden of the spec non-compliance in the power managment design and/or implementation, in the form of additional user support and less flexible troubleshooting steps, until it is resolved. I do, however, appreciate that there is only so much time to do useful work and that one has to prioritize. And I do also appreciate the large amount of enegry you put into v4l-dvb. Regards, Andy > Devin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
