[dialer] + [sound] Can't use earphone to answer or disconnect a call

<rsalveti> tiagosh: bfiller: I think it depends on the device, would still need to investigate what is the generic way to get such event
<rsalveti> on mako I know that is a pure input event
<rsalveti> we need a similar functionally for multimedia playback (play/pause)
<rsalveti> so first task there would be to understand how to generically retrieve such event, and then hook that up somewhere in the telephony stack

according to rsalveti, we need a generic way to retrieve headset events (probably at android layer), and then hook that up somewhere in the telephony stack. This functionality is needed for media playback as well for play/pause

Status changed to 'Confirmed' because the bug affects multiple users.

Once https://code.launchpad.net/~rsalveti/qtmir/wired_hs_keys/+merge/243720 is merged you'll be able to retrieve such events at the Qt level (in our case I think the shell is the one responsible for handling the input stack and taking actions).

On QML you should look for both Qt.Key_MediaPlay and Qt.Key_MediaTogglePlayPause (a similar logic would need to be in place for multimedia playback, and also checking if there is an income call in place, but not yet done).

<Saviq> I'd like us to list all the usecases we can think of before we decide on how to approach this (and possibly confirm a few cases with UX design)

This is because we first want to better understand the use cases in order to decide which component should handle such logic.

Basically we need to be able to react to input events coming from the wired headset, on the following scenarios:
1 - Media playback: play and pause
2 - Calls: accept when ringing (or waiting), hang up when the call is active
3 - Avoid music playback play/pause then the event should be driving the telephony stack (media-hub already got the logic to pause when there is an active/incoming call)

For media playback we can deliver such events to media-hub, probably using the indicator (when we enable the mpris interface again). Now for telephony, I don't know who should be the bridge.

Is there value/desire to providing the play/pause event to the foreground app if it's not playing audio?

In my mind the events (all those that originate from the headset, be it wired or bluetooth) should just follow the audio stream (if any) to its source (media playback - media-hub; ringtone - telephony-service; during a call - telephony-service as well; playing a game - the foreground app; etc.). I know you can post feedback events on audio streams and that feels to me like the most natural way to deliver those.
We should only have a fallback policy in place for when there's no audio playback - deliver to media hub to resume the most recently played stream? To voice recognition on long press?

Headphone (dis)connection (again, wired or otherwise) falls into the same group of events, if possible.

On Fri, Dec 5, 2014 at 1:24 PM, Michał Sawicz
<email address hidden> wrote:
> Is there value/desire to providing the play/pause event to the
> foreground app if it's not playing audio?
>
> In my mind the events (all those that originate from the headset, be it wired or bluetooth) should just follow the audio stream (if any) to its source (media playback - media-hub; ringtone - telephony-service; during a call - telephony-service as well; playing a game - the foreground app; etc.). I know you can post feedback events on audio streams and that feels to me like the most natural way to deliver those.
> We should only have a fallback policy in place for when there's no audio playback - deliver to media hub to resume the most recently played stream? To voice recognition on long press?
>
> Headphone (dis)connection (again, wired or otherwise) falls into the
> same group of events, if possible.

Yes, and in every case you described media-hub is involved (the only
one atm that is not yet covered is video playback using the browser).

I think a question for design is that if we should only care to send
events for multimedia specific applications, such as music-app and
mediaplayer-app. This is just because a game running in foreground
shouldn't necessarily need to care when we get such event from the
bt/wired headset.

This bug was fixed in the package qtmir - 0.4.4+15.04.20141205-0ubuntu1

---------------
qtmir (0.4.4+15.04.20141205-0ubuntu1) vivid; urgency=low

  [ CI Train Bot ]
  * Resync trunk
  * Resync trunk
  * Resync trunk
  * Resync trunk
  * Resync trunk

  [ Ricardo Salveti de Araujo ]
  * qteventfeeder: adding bt and wired headset multimedia keys (LP:
    #1398427)
 -- Ubuntu daily release <email address hidden> Fri, 05 Dec 2014 11:04:29 +0000

We need design input and some architecting to shut this bug, ww05-2015 would be my estimate.

I'm sorry I don't understand this bug report, and Google isn't helping.

A. What is a MO call?
B. What is DUT?
C. What is a hook key?

On Thu, Dec 18, 2014 at 3:03 PM, Matthew Paul Thomas <email address hidden> wrote:
> I'm sorry I don't understand this bug report, and Google isn't helping.
>
> A. What is a MO call?

In this case just a normal phone call (from another headset).

> B. What is DUT?

Device under test, which in this case is the ubuntu phone.

> C. What is a hook key?

Hook key is the multimedia key available in some wired headsets.

So the bug is basically to cover the use case when someone calls your
ubuntu phone and you want to answer/hangup the call with the button
available in your wired headset.

Okay. I'm skeptical that that requires design work at all. (What else would the hook key be for?) But if it does, it's telephony design, not sound design.

The one thing the hook key should be used for is for pausing/resuming media playback (especially as there's often volume up/down keys as well). There's a bit of UX design here, too (which one to resume - most probably the most recently paused? Or maybe the most recently paused *by the* hook key?).

Now the design question is whether we want to allow apps getting the event, and if so - when (when they're playing audio only, or also when there's no audio playing? always when the app is focused?). Basically, the floor is open to think of additional use cases for that button.

In a meeting today we agreed that short-term unity8 will just call a particular method on telephony whenever one of the interesting keys is pressed.

Longer-term we still need to work out the exact process, but we'll need the shell to talk to (in order of precedence) telephony, media, app if any is interested in this event. Details TBD.

This bug was fixed in the package qtmir - 0.4.4+15.04.20150112.3~rtm-0ubuntu1

---------------
qtmir (0.4.4+15.04.20150112.3~rtm-0ubuntu1) 14.09; urgency=medium

  [ Nick Dedekind ]
  * Compatibility for Mir 0.8.1
  * Notify prompt sessions that sessions have been suspended/resumed.
    (LP: #1355173, #1384950)

  [ Ricardo Salveti de Araujo ]
  * qteventfeeder: adding bt and wired headset multimedia keys (LP:
    #1398427)
 -- Ubuntu daily release <email address hidden> Mon, 12 Jan 2015 13:38:21 +0000

This bug was fixed in the package telephony-service - 0.1+15.04.20150116-0ubuntu1

---------------
telephony-service (0.1+15.04.20150116-0ubuntu1) vivid; urgency=low

  [ Tiago Salem Herrmann ]
  * Expose HandleMediaKey(bool doubleClick) to DBus. (LP: #1398427)
 -- Ubuntu daily release <email address hidden> Fri, 16 Jan 2015 10:28:07 +0000

This bug was fixed in the package unity8 - 8.02+15.04.20150121.2-0ubuntu1

---------------
unity8 (8.02+15.04.20150121.2-0ubuntu1) vivid; urgency=low

  [ Michael Terry ]
  * Don't show any power dialogs while the screen is off. This is a
    band-aid to avoid the symptom, while we still investigate the source
    of why the screen doesn't turn on (and why we seem to not handle the
    power-button-release event). (LP: #1409003, #1410830)
  * Don't refocus the dialer-app when a call is started by the user.
    Because of how qtmir works, this would cause the dialer-app to
    unfocus momentarily, causing interface oddities for the user. (LP:
    #1413065)

  [ CI Train Bot ]
  * Resync trunk

  [ Albert Astals Cid ]
  * Build with ninja
  * Fixes for Table Preview Widget (LP: #1410420)

  [ Michael Zanetti ]
  * Add support for earpiece media buttons (LP: #1398427)
  * Add a WindowMoveResizeArea and tests for it
 -- Ubuntu daily release <email address hidden> Wed, 21 Jan 2015 18:33:18 +0000

This bug was fixed in the package unity8 - 8.02+15.04.20150122.2~rtm-0ubuntu1

---------------
unity8 (8.02+15.04.20150122.2~rtm-0ubuntu1) 14.09; urgency=medium

  [ Michael Terry ]
  * Don't show any power dialogs while the screen is off. (LP: #1409003,
    #1410830)
  * Don't refocus the dialer-app when a call is started by the user. (LP:
    #1413065)

  [ Michael Zanetti ]
  * Add support for earpiece media buttons (LP: #1398427)

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Thu, 22 Jan 2015 20:47:05 +0000

This bug was fixed in the package telephony-service - 0.1+15.04.20150122.1~rtm-0ubuntu1

---------------
telephony-service (0.1+15.04.20150122.1~rtm-0ubuntu1) 14.09; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Gustavo Pichorim Boiko ]
  * Expose HandleMediaKey(bool doubleClick) to DBus (LP: #1398427)
 -- Ubuntu daily release <email address hidden> Thu, 22 Jan 2015 20:51:23 +0000