No subject

talking about two separate conditions.  In the first (where I presume the
module is loaded without any parameters you say there's no sound from the
speaker.  Do other aspects of the card work correctly in this case?

The second situation is where "model=will" is specified as a module
parameter.  Here you say you can get audio from the headphone, but again
what about other aspects of the soundcard - do they work normally?

At a rough guess, it sounds like there are two underlying issues.  The first
is that this system requires some model-specific handing in order to map
chip outputs correctly.  The second is that if such model-specific details
are required then the driver preferrably would activate these automatically
without the need to specify "model=will".

Another possibility is that there is something about this laptop system
which is confusing the auto-probing of the alc260 codec code.

I'm not sure what is the best way of proceeding here.  I suspect other more
active developers will have a streamlined approach to help rectify the
trouble.  In the first instance I would tend to load the module with
"model=test" and experiment with the resulting alsamixer controls to
determine what chip outputs are connected to which pins.  However, this is
quite "old school" now - while it's the approach I used when getting my
system working, my impression is that its use has been mostly deprecated by
the automatic parser which is now present.

In the above-referenced launchpad report the question is asked about the
ALC260 datasheet.  This is readily available on the net.  I doubt it is all
that necessary now since I think the base infrastructure is pretty solid,
but if you do need it and have difficulty finding it please contact me
off-list.

Regards
  jonathan