1. 16 Oct, 2019 1 commit
    • spiiroin's avatar
      [display] Retry failing brightness adjustments. Fixes JB#47450 · 2783a90d
      spiiroin authored
      Display brightness control logic has been written with framebuffer
      interface in mind and consequently devices utilizing drm/dri are
      suffering from diagnostic logging noise from incorrectly timed
      adjustment attempts and outright failures to set desired brightness.
      Store desired and successfully activated brightness levels separately
      to ease adjustment failure handling and avoiding unwanted brightness
      pumping for example during compositor switchovers.
      Adjust display state machine so that it performs brightness level
      checkups during unblank also in states relevant for drm/dri logic.
      If brightness adjustment fails after unblank, retry periodically.
      Reduce amount of repetitive diagnostic noise caused by differing
      timing requirements between framebuffer and drm/dri interfaces.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
  2. 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>
  3. 26 Oct, 2018 1 commit
  4. 17 Oct, 2018 1 commit
    • spiiroin's avatar
      [mce-io] Augment resume detection with timerfd source. Fixes JB#43297 · f5e7d2f9
      spiiroin authored
      MCE needs to perform some tasks like rethinking timer expiration when device
      resumes from suspend. The resume detection is built on assumption that some
      input devices will send EV_SYN events on resume. In devices where such events
      are not emitted, on resume tasks can get indefinitely delayed.
      Take advantage on the fact that system time gets updated on resume, and
      use timerfd to trigger resume detection logic whenever system time changes.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
  5. 19 Sep, 2018 3 commits
  6. 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>
  7. 01 Mar, 2018 1 commit
  8. 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
      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
      Switch lockkey_state_pipe value from gboolean to key_state_t type.
      Signed-off-by: spiiroin's avatarSimo Piiroinen <simo.piiroinen@jollamobile.com>
  9. 07 Jan, 2016 1 commit
    • spiiroin's avatar
      [iomon] Provide context pointer for iomon callbacks. JB#33644 · a8c4d461
      spiiroin authored
      The source of input data is not made known to io-monitor callback
      functions. This makes it difficult to use the same functions for
      dealing with input from several similar input device nodes.
      Pass the io-monitor object pointer to the callback functions. Then
      callback functions can utilize custom per device state data attached
      to the io-monitor when needed.
  10. 22 Sep, 2015 1 commit
    • spiiroin's avatar
      [lib] Add utilities for getting 64-bit time stamps. Contibutes to JB#31310 · a3e3626e
      spiiroin authored
      The mce codebase is littered with very similar functions for turning
      clock_gettime() results into 64-bit integer time stamps.
      Add common utility functions for obtaining boot, real and monotonic time
      stamps in to mce-lib module. Use these common utility functions instead
      of locally defined versions.
  11. 16 Jan, 2015 1 commit
    • spiiroin's avatar
      Tune diagnostic logging that happens during mce startup · 49065f8e
      spiiroin authored
      Running "mce -Tv" from command line should not show insignificant info.
      Demote non-interesting diagnostic to INFO level.
      Avoid emitting warnings about illegal display state requests that
      happen due to request filtering.
  12. 23 Dec, 2014 2 commits
    • spiiroin's avatar
      Allow attaching of context specific user data to mce io monitors · 63960dd2
      spiiroin authored
      After io monitor is created, used data can be attached to it via
      The existing notification interface is not changed, i.e. the user
      data is not automatically passed to notification callbacks and
      must be queried via mce_io_mon_get_user_data() function when needed.
      If free callback is provided, the user data is released when the
      io monitor itself gets deleted.
      [mce] Allow attaching of context specific user data to mce io monitors
    • spiiroin's avatar
      Refactor mce io monitor interface · 32a89fa3
      spiiroin authored
      Using abstract gpointer instead of pointer to io monitor structure
      makes following logic from callbacks up to io monitor functionality
      harder than it needs to be.
      Use typed pointer instead of abstact gpointer for io monitor functions.
      Use uniform naming for io monitor functions.
      Remove unused io monitor error callback function type.
      No functional changes.
      [mce] Refactor mce io monitor interface
  13. 28 Oct, 2014 1 commit
    • spiiroin's avatar
      Re-evaluate autolock if device wakes up from suspend · 9efa7db5
      spiiroin authored
      When display is automatically dimmed and then blanked there is a 30 second
      grace period before tklock gets applied. Since the device most likely
      also suspends soon after blanking the screen and we do not want to wake
      up just to toggle the tklock state, the end of grace period is evaluated
      when display is about to be turned on. This can cause ipc timing problems
      if powerkey/doubletap is configured also to remove the tklock.
      Also do opportunistic grace period end detection if the device wakes up
      from suspend due to reasons that would not cause the display to turn on.
      This should make it less likely that both lock and unlock happen at the
      same time.
      [mce] Re-evaluate autolock if device wakes up from suspend
  14. 27 May, 2014 1 commit
  15. 14 Mar, 2014 1 commit
    • spiiroin's avatar
      Handle io watch error conditions gracefully · 7a56637c
      spiiroin authored
      All calls to g_io_add_watch() request error condition reporting, and
      all related callback functions at minimum will not create a virtual
      busyloop by leaving the io watch active and ignoring the error state.
      The mce io monitoring subsystem is modified so that instead of using
      separate io watches for data and error handling + optional error
      recovery callback it now has one io watch that first deals with
      possible errors and then handles possible input via monitor type
      specific logic and enforces delete notification callbacks for making
      clean up at upper level logic. This should allow mce to gracefully
      handle situations like adding/removing bluetooth keyboards.
      [mce] Handle io watch error conditions gracefully
  16. 11 Feb, 2014 1 commit
    • spiiroin's avatar
      Make devel build of mce log important external triggers by default · aeb6c0b1
      spiiroin authored
      Events logged are:
      * Time spent in suspend (via evdev inputs and mono vs boot time diff)
      * Proximity sensor state (from evdev orsensorfw / synthesized within mce)
      * Alarm state (D-Bus signal from alarm ui)
      * Call state (D-Bus signals from ofono)
      * CPU keepalive service (D-Bus method calls from clients)
      * Display blanking pause service (D-Bus method calls from clients)
      * Display blank/unblank alert leds (sysfs and D-Bus ipc with lipstick)
      * Display on/dim/off requests (D-Bus method calls from clients)
      * Display state changes (mce internal)
      * Device lock status (D-Bus signals from lipstick)
      * Tklock status changes (mce internal)
      * Tklock state requests (D-Bus method calls from clients)
      [mce] Make devel build of mce log important external triggers by default
  17. 05 Nov, 2013 1 commit
  18. 10 Jan, 2013 1 commit
  19. 03 Jan, 2013 1 commit
  20. 21 Dec, 2012 1 commit
  21. 11 Dec, 2012 2 commits
  22. 15 Nov, 2012 2 commits
    • spiiroin's avatar
      Fix read buffer size for large chunks · 0d13d657
      spiiroin authored
      Oops, copy paste error slipped through ...
    • spiiroin's avatar
      Improve error logging from mce_write_number_string_to_file() helper · 0dd4d20e
      spiiroin authored
      There should be changes to mce behavior.
      The only purpose of the code changes is to give more informative
      error logging in cases where mce_write_number_string_to_file()
      gets called without properly configured paths (due to hw and/or
      kernel changes), i.e. instead of:
      	(file == NULL) && ((fp == NULL) || (*fp == NULL))!
      	(file == NULL) && ((fp == NULL) || (*fp == NULL))!
      	(file == NULL) && ((fp == NULL) || (*fp == NULL))!
      emit something like this:
      	touchscreen_disable: output->path not configured
      	keypad_disable: output->path not configured
      	brightness: output->path not configured
  23. 08 Nov, 2012 4 commits
  24. 01 Nov, 2012 1 commit
  25. 26 Oct, 2012 1 commit
  26. 23 Aug, 2011 1 commit
    • Jukka Turunen's avatar
      Error callback for I/O monitors · 713f8b89
      Jukka Turunen authored
      Callback can now be called in case of I/O error conditions. Used
      to remove monitors in hangup state so device file is not uselessly
      accessed before input device file list is refreshed.
  27. 12 May, 2011 1 commit
  28. 16 Dec, 2010 1 commit