1. 12 Jun, 2019 1 commit
  2. 28 Mar, 2019 2 commits
  3. 15 Mar, 2019 6 commits
  4. 08 Mar, 2019 2 commits
  5. 12 Nov, 2018 1 commit
    • spiiroin's avatar
      [event-input] Do not skip volume key processing. JB#43764 · 455073de
      spiiroin authored
      Previously grabbing input devices was used as means for implementing
      touchscreen and volume key policies. This should not be necessary anymore,
      but unless volume key grabbing is allowed, pressing volume keys always
      wakes up display.
      
      Instead of skipping volume key event processing altogether when keypad
      input devices have been grabbed by mce, check keypad policy state when
      processing volume key events to decide whether display wake up is desired
      or not.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      455073de
  6. 02 Nov, 2018 1 commit
    • spiiroin's avatar
      [led] Add proximity sensor debugging patterns. JB#43690 · 5667900c
      spiiroin authored
      Debugging proximity sensor issues is difficult as inspecting logs is
      usually not possible in the situation where the problem is detected,
      or the sensor has failed in distant enough past so that logs have been
      already lost due to log rotation.
      
      Add led patterns that are activated/deactivated as follows:
      - PatternProximityCovered when sensor is reporting closed state.
      - PatternProximityUncovering when sensor is reporting uncovered state, but
        effective state is still covered (uncover hysteresis).
      - PatternProximityUncovered when effective proximity state is uncovered.
      
      The patterns are disabled by default, but can be enabled via:
        mcetool --enable-led-pattern=PatternProximityCovered\
                --enable-led-pattern=PatternProximityUncovering\
                --enable-led-pattern=PatternProximityUncovered
      
      And disabled again with:
        mcetool --disable-led-pattern=PatternProximityCovered\
                --disable-led-pattern=PatternProximityUncovering\
                --disable-led-pattern=PatternProximityUncovered
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      5667900c
  7. 19 Sep, 2018 5 commits
  8. 18 Sep, 2018 3 commits
  9. 15 Aug, 2018 3 commits
  10. 21 Mar, 2018 1 commit
    • spiiroin's avatar
      [tklock] Disable display state restore during bootup. JB#41395 · e61fbd39
      spiiroin authored
      Bootup while device is connected to a charger causes display to blank
      immediately after bootup is finished. Happens on devices lipstick is
      started while display is in "off" state: Display is turned on due
      to charger connected notification - and is then turned back off once
      the notification is removed.
      
      Disable display state restore for ui exceptions raised during bootup.
      
      Also, in case the exception is raised in the middle of a display state
      transition, the state to be restored must be the transition target
      rather than the state we are just about to leave.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      e61fbd39
  11. 16 Mar, 2018 1 commit
  12. 15 Mar, 2018 1 commit
  13. 01 Mar, 2018 2 commits
  14. 28 Feb, 2018 1 commit
    • spiiroin's avatar
      [datapipe] Unify naming. Contributes to JB#22475 · 5fadb870
      spiiroin authored
      Use "datapipe_"  prefix for all functions:
      
       datapipe_add_filter            <- append_filter_to_datapipe
       datapipe_add_input_trigger     <- append_input_trigger_to_datapipe
       datapipe_add_output_trigger    <- append_output_trigger_to_datapipe
       datapipe_exec_filters          <- execute_datapipe_filters
       datapipe_exec_full             <- execute_datapipe
       datapipe_exec_input_triggers   <- execute_datapipe_input_triggers
       datapipe_exec_output_triggers  <- execute_datapipe_output_triggers
       datapipe_free                  <- free_datapipe
       datapipe_init                  <- setup_datapipe
       datapipe_remove_filter         <- remove_filter_from_datapipe
       datapipe_remove_input_trigger  <- remove_input_trigger_from_datapipe
       datapipe_remove_output_trigger <- remove_output_trigger_from_datapipe
      
      Datapipes that are used for solely for requesting state changes (i.e. do not
      themselves have a state) have a verb in the name:
      
       display_state_request_pipe          <- display_state_req_pipe
       led_pattern_activate_pipe           (no change)
       led_pattern_deactivate_pipe         (no change)
       tklock_request_pipe                 <- tk_lock_pipe
      
      Datapipes that are used solely process input events without having a
      persistent state have "event" in the name:
      
       heartbeat_event_pipe                <- heartbeat_pipe
       ignore_incoming_call_event_pipe     <- ignore_incoming_call_pipe
       inactivity_event_pipe               <- device_inactive_event_pipe
       keypress_event_pipe                 <- keypress_pipe
       resume_detected_event_pipe          <- device_resumed_pipe
       touchscreen_event_pipe              <- touchscreen_pipe
       user_activity_event_pipe            <- user_activity_pipe
      
      Datapipes dealing with brightness have "brightness" included in the name:
      
       display_brightness_pipe             (no change)
       key_backlight_brightness_pipe       <- key_backlight_pipe
       led_brightness_pipe                 (no change)
       lpm_brightness_pipe                 (no change)
      
      Datapipes dealing with sensors have "sensor" in name and the one holding
      unfiltered data is called "actual":
      
       lid_sensor_actual_pipe              <- lid_cover_sensor_pipe
       lid_sensor_filtered_pipe            <- lid_cover_policy_pipe
       lid_sensor_is_working_pipe          (no change)
       light_sensor_actual_pipe            <- ambient_light_sensor_pipe
       light_sensor_filtered_pipe          <- ambient_light_level_pipe
       light_sensor_poll_request_pipe      <- ambient_light_poll_pipe
       orientation_sensor_actual_pipe      <- orientation_sensor_pipe
       proximity_sensor_actual_pipe        <- proximity_sensor_pipe
      
      Datapipes that have enumerated state reflect the enumeration type in
      datapipe name:
      
       alarm_ui_state_pipe                 (no change)
       audio_route_pipe                    (no change)
       battery_status_pipe                 (no change)
       bluez_service_state_pipe            <- bluez_available_pipe
       call_state_pipe                     (no change)
       call_type_pipe                      (no change)
       camera_button_state_pipe            <- camera_button_pipe
       charger_state_pipe                  (no change)
       compositor_service_state_pipe       <- compositor_available_pipe
       devicelock_service_state_pipe       <- devicelock_available_pipe
       devicelock_state_pipe               <- device_lock_state_pipe
       display_state_curr_pipe             <- display_state_pipe
       display_state_next_pipe             (no change)
       dsme_service_state_pipe             <- dsme_available_pipe
       jack_sense_state_pipe               <- jack_sense_pipe
       keyboard_available_state_pipe       <- keyboard_available_pipe
       keyboard_slide_state_pipe           <- keyboard_slide_pipe
       lens_cover_state_pipe               <- lens_cover_pipe
       lipstick_service_state_pipe         <- lipstick_available_pipe
       lockkey_state_pipe                  <- lockkey_pipe
       ngfd_service_state_pipe             <- ngfd_available_pipe
       submode_pipe                        (no change)
       system_state_pipe                   (no change)
       thermal_state_pipe                  (no change)
       uiexception_type_pipe               <- exception_state_pipe
       usb_cable_state_pipe                <- usb_cable_pipe
       usbmoded_service_state_pipe         <- usbmoded_available_pipe
      
      Datapipes that have boolean state should answer an
      "is" question:
      
       device_inactive_pipe                <- device_inactive_state_pipe
       interaction_expected_pipe           (no change)
       keypad_grab_active_pipe             (no change)
       keypad_grab_wanted_pipe             (no change)
       master_radio_enabled_pipe           <- master_radio_pipe
       music_playback_ongoing_pipe         <- music_playback_pipe
       osupdate_running_pipe               <- update_mode_pipe
       packagekit_locked_pipe              (no change)
       power_saving_mode_active_pipe       <- power_saving_mode_pipe
       proximity_blanked_pipe              <- proximity_blank_pipe
       shutting_down_pipe                  (no change)
       touch_detected_pipe                 (no change)
       touch_grab_active_pipe              (no change)
       touch_grab_wanted_pipe              (no change)
      
      Datapipes that have integer state should answer
      and "what is" question:
      
       battery_level_pipe                  (no change)
       inactivity_delay_pipe               <- inactivity_timeout_pipe
      
      Rename datapipe related callback functions and variables similarly as what
      was done to datapipes.
      
      Define submode bitmasks as submode_t enumeration instead of using
      gint type and preprocessor constants. Change the value naming from
      MCE_xxx_SUBMODE to MCE_SUBMODE_xxx.
      
      Change call_type_t enumeration value naming from xxx_CALL to
      CALL_TYPE_xxx.
      
      Change system_state_t enumeration value naming from MCE_STATE_xxx
      to MCE_SYSTEM_STATE_xxx.
      
      Fix setting up of power_saving_mode_active_pipe, master_radio_enabled_pipe
      and lens_cover_state_pipe so that initial values of appropriate type are
      used.
      
      Switch lockkey_state_pipe value from gboolean to key_state_t type.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      5fadb870
  15. 23 Feb, 2018 1 commit
  16. 18 Nov, 2017 1 commit
  17. 19 Oct, 2017 1 commit
    • spiiroin's avatar
      [tklock] Do not allow tkunlock while display is blanked. Fixes MER#1831 · 1249e069
      spiiroin authored
      If lockscreen blanking timeout happens while user has finished unlock
      gesture but has not yet lifted the finger off screen, the gesture gets
      finalized due to due to display getting powered off and lockscreen is
      left in deactivated state - or in case the lpm feature is enabled, the
      display can even bounce back on.
      
      As the intent is that deactivating lockscreen should happen only as a
      response to explicit user actions, there should be no need to allow such
      actions to be requested when display is off and such interaction with the
      user is not really possible.
      
      Enforce this intent and do not allow tkunlock requests made while display
      is not in fully powered up state.
      
      Note that this is only protection against accidental unlocking. Applications
      can still request display to be powered on. And if that is allowed, they
      can also request lockscreen deactivation (which can still be denied due to
      other reasons such as device lock being active).
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      1249e069
  18. 02 Jun, 2017 2 commits
    • spiiroin's avatar
      [tklock] Do not blank when dismissing alarm with side swipe. Fixes JB#35239 · a854b9a0
      spiiroin authored
      When the device is locked and display wakes up due to alarm which is then
      dismissed via side swipe, the ui makes transition from alarm ui to device
      unlock view without going through the default lockscreen. This leaves
      display state restore active and display can blank abruptly if the user
      does not immediately start to type the lock code.
      
      Disable display state restore if ui has been left at state where lockscreen
      is active and interaction expected after linger time (not associated with
      calls) finishes.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      a854b9a0
    • spiiroin's avatar
      [tklock] Cancel display blanking on lockscreen interaction. Fixes JB#35376 · 1ee11dd7
      spiiroin authored
      Implicit display power ups due to notifications and such use shorter than
      normal blanking timeouts. If mce sees sufficient user activity during the
      exceptional situation, it cancels the display state restore. However since
      the device unlocking was moved to happen within lockscreen context, mce
      has no way to detect that there is significant user interaction with
      the device and blanks the display while user is entering the lock code.
      
      Listen to lockscreen notifications on D-Bus and cancel display state
      restore when lockscreen signals transition to a state where user
      interaction is expected to happen.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      1ee11dd7
  19. 20 Apr, 2017 1 commit
  20. 18 Jan, 2017 1 commit
  21. 11 Oct, 2016 2 commits
  22. 07 Oct, 2016 1 commit