On Tue, Feb 1, 2011 at 17:57, Shane Bryan <[email protected]> wrote: > On Tue, Feb 01, 2011 at 02:00:40PM +0200, Kalle Lampila wrote: >> On Tue, Feb 1, 2011 at 09:31, Thiago Macieira <[email protected]> wrote: >> > On Monday, 31 de January de 2011 22:47:22 Shane Bryan wrote: >> >> On Tue, Feb 01, 2011 at 01:58:36PM +0800, alexguitar wrote: >> >> > Dear All, >> >> > >> >> > I want to develop a app to detect earphone with two features, including >> >> > plug in and plug out earphone jack . >> >> > >> >> > Whether does the Qt and Qt mobility provide the API about earphone >> >> > detection? >> >> >> >> If you get an answer off list, please let us know, as I need to monitor >> >> this >> >> as well. >> > >> > I'm not sure if the info is available elsewhere, but there's a /dev/input >> > interface usually associated with that. Even my Dell laptop has it. >> > >> > Event: time 1296545363.867189, type 5 (EV_SW), code 2 (Headphone insert), >> > value 1 >> > Event: time 1296545363.867201, -------------- Report Sync ------------ >> > Event: time 1296545370.850146, type 5 (EV_SW), code 2 (Headphone insert), >> > value 0 >> > Event: time 1296545370.850155, -------------- Report Sync ------------ >> > >> > There might be a daemon already listening to this event and reporting it in >> > contextkit. >> >> Hi, >> >> Resouce policy framework has accessories plugin for ohmd to detect >> headpohones etc. That information is used to route audio, but probably >> that is not reported forward to contexkit. >> >> Btw. Why you need that information on application? > > In the dialer app, I have a multi-state button allowing the user to > select the output path, and it needs to be aware of the available > devices to the appropriate button state options can be presented. So > I need to know, when the all of the following are connected or > disconnected: > - Jack headset > - USB headset > - BT headset > > I can get the BT HSP info now, but am still missing the wired jack > and USB headset info. > > Honestly, I've not dug into it much yet, as I've had other work that > is taking priority, but since the question was asked, I cast in my > vote for more info too ;)
Idea is that resource policy fw is corresponding of audio routing not applications. If some application touch directly audio routing that probably break the resource policy fw and hole system. Application not need to know what kind of audio route there is available, only tell the policy what type audio stream it is playing. If there is accessories plugged then policy use it. That is quite natural if user plug accessories he want use it and user don't want make much selection in handset devices (ringtone etc. are route both speaker and headset so user hear them even headset is not in ears). Only exception is that dialer should have button for speaker phone on/off and report that to policy framework. There is Application Developer Guide for Policy Framework http://wiki.meego.com/images/Meego-policy-framework-developer-guide.pdf -- Kalle Lampila _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
