Given Hugo comment re: PWM decoding in the Consumer IR kernel code,

How difficult would it be to simply take the incoming PWM bitstream from the Onstar interface and simply turn that bitstream into a button code - I think there are 16 to 21 (variable) bits per 'packet' sent on this interface according to the previously published info.

That way we don't need to necessarily 'decode' the bitstream messages, just make it a button code and feed it into the Hijack kernel as now [i.e. pretend the Mute input is a IR bit stream input].

That would then let Rtundo get some button codes from his Onstar system and then he can make a map.

For OBD-II systems interfaces, this data stream would have to be decoded correctly (and maybe written to a device/fifo like the RDS stream is, so that userland apps can get at it),

The user could then be able to set in Hijack which of the modes the Mute Input was running in - normal [i.e. Cellphone toggle input], Onstar bitstream [PWM raw data treated as button codes], or OBD-II (decoded serial data stream ) feed to fifo/character device

I guess you could do something similar for Dimmer input - to allow both Onstar and OBD-II monitoring at the same time,
[with the correct wiring to the docking sled of course].

Hmm, this is starting to sound promising - I just wish I had a car with OBD.