At Tue, 07 Aug 2012 10:08:54 +0200, David Henningsson wrote:
On 08/07/2012 09:11 AM, Takashi Iwai wrote:
Judging from our last experience, where we had a two-hour session on Sunday and then had to reschedule on Wednesday for two more hours, and yet had to cancel the topic I was about to introduce, because everybody was tired (and waiting for lunch), I certainly beg to differ!
Hrm? Was this Plumbers or the BoF in Prague last year?
The BoF in Prague.
That was the problem of having too long time slot. Discussions tend to be either too deep or too boring when continued for long time.
We'll have to agree to disagree on that.
Heh. Actually it's like a question of CPU scheduler...
Also; we fly across half the world to get there, to spend just a few minutes talking? Better have some margins. Maybe some session will end early, but will it hurt? No. If we miss a topic, or have to cut it short without a conclusion, will it hurt? Yes.
Btw, take "HD Audio cooking recipe" as an example. We will discuss:
- debugging practices for typical problems
- open problems
- jack retasking
- HDMI stream assignment
- missing speaker/mic streams
- better interaction / organization with user-space applications like
PulseAudio
For 15-20 minutes in total, that gives approximately 3 minutes per sub-topic. (!)
So this is a good chance to reconsider what to be discussed.
The first one, for example, can be well merged to another topic "automatic testing using hda-emu". Jack retasking, HDMI streams and missing speaker/mic streams, are things to be discussed from two perspectives: the driver side and the user-space (i.e. PA) side. And for Plumbers, these should be the topics from the latter POV.
Also, the next, the automatic testing topic can be shorter than the former, so we can think of this whole 45 minutes slot as hd-audio slot in practice.
Since I don't seem to get understanding for the need to have 45 min sessions per topic, which I still believe would be the best option, can we split the channel-mapping API topic with a new topic - "simplifying volume set/get on startup and shutdown"?
Sorry, I don't understand what you mean here. The channel-mapping API has nothing to do with volume get/set things... So you are proposing a completely new topic now?
The channel-API topic slot was considered to be an optional one from the beginning. I got the slot lately in case anyone would like to bring up new topics, e.g. use it for lightening talks. So, if you have a new topic proposal, it's fine. Let's assign there.
New topic suggestion:
Simplifying volume setting on startup/shutdown
Currently, on a normal desktop session, volume is set four times on startup - initally by the kernel, then by alsactl, then by PulseAudio in the DM session, then by PulseAudio in the logged in session.
When shutting down, both PulseAudio and alsactl saves volumes to restore them later. And then we also have suspend and hibernate to consider, and that cards can be plugged in at any time.
First, isn't this quite complex for something as simple as setting volumes? Second, can we facilitate new features, such as 1) having a "set this volume as default, for all users, on startup" button in the volume control, or 2) "allow the DM user to introspect different users' volumes"? ===================
This is mostly a problem statement. I don't have a good proposal for how to simplify it.
OK, could you create a blueprint with that content? Then I'll inform plumbers committee about the addition as another (5th) slot at first. Then we can rearrange topics in 5 slots.
And, if needed, we can ask for a slot/room for BoF beforehand in addition.
Can we ensure that the required participants make it to that slot/room then?
Yeah I meant as an official (5th) slot, so people can check it rightly.
Ok, if we can't have 45 minutes per topic, a 5th slot is better than nothing.
Well, I'm not totally against 45 minutes per topic. If the topic is really worth for 45 minutes, then we can assign to a full slot, yes. But one should consider again whether the topics are really mandatory to be discussed at Plumbers. For example, if a topic is way too deeply involved with coding, it isn't. Better discussed on ML.
Takashi