What sort of "event" are you talking about? I see events on the input device that's associated with the jack, though I don't know how that gets routed inside ALSA.
The values of '* Jack' mixers are used by UCM, so you can look at them with amixer. I can never remember the amixer syntax so what I do is list the controls with 'amixer -Dhw:0 controls' and then check their values with 'amixer -Dhw:0 cget num_id=<num_id from list>'
In any case, the module option seems to bring it back to a working state. Any hints as to what to do now for the PulseAudio bug report if I wanted to diagnose and report this is a UCM problem?
ok, that's progress if this is not a codec issue :-)
I only have a limited understanding of jack detection, but all UCM configs for your case should be in [1].
I would check if the value of the controls with amixer and maybe if the control name is wrong. Today 'Headphone Mic Jack' or 'Mic Jack' are used, and I wonder if this is 'Front Headphone Jack' in your case. Maybe you can share the alsa-info results so that we can all check if there's a naming issue.
[1] https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/HDA-Intel/HiF...