#
# Microphone/Speaker LED handling seems like an easy task, but
# the expectations are different:
#
# Main question: Which state should LEDs follow (devices)?
#
# Case 1) set LEDs only for internal resources (speaker/microphone)
# Case 2) set LEDs according the current stream (input/output)
# Case 3) like case 1, but add analog headphones connected to laptop (analog jack)
#
# Discussion for Case 2: It is not possible to handle this in driver
# (kernel). Usually, the sound server knowns the current stream (which may be routed to
# bluetooth or a USB device, for example). Additionally, there is a security flaw if the
# sound server directly controls the LEDs.
#
# Discussion for Case 3: Note that we have currently also USB/Bluetooth headphones which
# do not follow this scenario. In this case, there is no clear LED mapping. It seems
# that this case is somewhat controversional. Thus, analog headphones may be treated as
# an external device.
#
# Result: For safety, simplicity and understable behaviour, only Case 1 should be
# followed - LEDs should respond only to the internal (build-in) speaker output and
# internal (build-in) microphone input in UCM.
#

#
# Macro SetLED - attach or detach speaker or microphone LED to given control element
#
# Arguments:
#   LED    - LED selection - "speaker" or "mic"
#   Action - action for given control - "attach" or "detach"
#   CtlId  - control identifier (as for amixer, e.g. "Capture Switch" or "name='CaptureSwitch',index=1")
#

DefineMacro.SetLED {
	If.0 {
		Condition {
			Type String
			Empty "${var:-SndCtlLedModprobe}"
		}
		True {
			FixedBootSequence [
				exec "-/sbin/modprobe snd_ctl_led"
			]
			Define.SndCtlLedModprobe ok
		}
	}
	If.1 {
		Condition { Type AlwaysTrue }
		True.FixedBootSequence [
			sysw "-/class/sound/ctl-led/${var:__LED}/card${CardNumber}/${var:__Action}:${var:__CtlId}"
		]
	}
}

#
# Macro CtlNew - helper to create new control elemend
#
# Arguments:
#   Arg    - string for cset-new
#

DefineMacro.CtlNew.FixedBootSequence [
	cset-new "${var:__Arg}"
]