1. 17 May, 2019 1 commit
    • spiiroin's avatar
      [mce] Unify license blurbs. JB#33684 · 091d6e7e
      spiiroin authored
      MCE uses LGPL v2.1 (without "or later") license, but due to missing / use
      of different license blurbs this is not always clear enough.
      
      Replace blurbs referring to "LGPLv2" short form which could be either
      LGPL v2.0 or v2.1 without "or later" with the same blurb that is used
      in mce.c file.
      
      Similarly add blurb to source files that are missing one altogether.
      
      Add all authors that can be derived from git logs.
      
      Update Jolla Ltd. copyright statements to match git activity.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      091d6e7e
  2. 19 Sep, 2018 5 commits
  3. 16 Mar, 2018 1 commit
  4. 15 Mar, 2018 1 commit
    • spiiroin's avatar
      [datapipe] Remove lintisms. JB#22475 · 2d041b7e
      spiiroin authored
      Casting datapipe_exec_xxx() function return values to (void)
      is useful when trying to avoid false positive warnings from
      static analysis tools. When such tools / compiler options
      invoking strict enough checks are not employed they just add
      noise to code base.
      
      Remove return value casting from all datapipe function calls.
      And do the same for the whole mce source tree while at it.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
      2d041b7e
  5. 01 Mar, 2018 1 commit
  6. 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
  7. 06 Oct, 2017 1 commit
  8. 11 Oct, 2016 1 commit
    • spiiroin's avatar
      [datapipe] Elevate logging of display state requests. JB#36274 · c4f0ba6f
      spiiroin authored
      Analyzing reasons for pocket calls and other issues related to unwanted
      display unblanking is next to impossible if reason for the display wakeup
      is not known.
      
      Use a wrapper macro that logs points in mce code base from which display
      state request leading to actually powered up states are made.
      c4f0ba6f
  9. 14 Mar, 2015 1 commit
    • spiiroin's avatar
      Remove SoftOff mode · b6d161ea
      spiiroin authored
      SoftOff mode is basically manual suspend to RAM for pre N900 era maemo
      devices. The logic in MCE side does not work and also support needed by
      it has beed dropped from DSME side ages ago.
      
      Remove all remnants of SoftOff mode that still linger in mce code tree.
      
      [mce] Remove SoftOff mode. Fixes JB#27285
      b6d161ea
  10. 19 Jun, 2014 1 commit
    • spiiroin's avatar
      Unblank display when shutting down/rebooting from act dead or user mode · 1511bc2a
      spiiroin authored
      Previously display was blanked when shutting down from act dead. As there
      is now shutdown animation also for act dead, that is no longer desirable.
      
      Unblanking the display makes the animation visible even if the shutdown
      or reboot happened from display off state without user interaction.
      1511bc2a
  11. 27 May, 2014 1 commit
  12. 23 Jan, 2014 1 commit
  13. 16 Jan, 2014 1 commit
  14. 14 Jan, 2014 1 commit
  15. 26 Aug, 2013 1 commit
    • spiiroin's avatar
      Use single state machine for both display and suspend policy · 3a6eae2e
      spiiroin authored
      As fb suspend and wakeup are not immediate, display state requests
      must be handled separately from actual state transition processing.
      
      A new data pipe display_state_req_pipe is used for making display
      state requests and filtering them.
      
      The state machine takes data from display_state_req_pipe and
      makes changes known to existing triggers via display_state_pipe.
      
      The suspend policy is integrated to display state handling, which
      allows better control over sharing update enable/disable state
      with ui side (lipstick).
      
      [mce] Use single state machine for both display and suspend policy
      3a6eae2e
  16. 11 Aug, 2011 1 commit
  17. 12 May, 2011 1 commit
  18. 28 Jan, 2011 1 commit
  19. 16 Dec, 2010 1 commit