frameworkd: performance problems in /dev/input handling

[Harald Welte]

Hi!

The Swisscom guys told me that the current FSO images consume _tons_ (close
to 90%) of CPU time in frameworkd whenever you keep the touchscreen touched
down (e.g. for scrolling or things like moving objects around on the screen)

The problem seems to be the fairly suboptimal way how it currently deals with
input devices.

First of all, it opens all input event devices (except those in ignoreinput)
and receives all events on those devices.  While this might work for button
presses and headphone insert/remove events, it doesn't work that well for
the touchscreen, which emits ABS_X/ABS_Y events at a rate of 
(PCLK/PRESCAL/5/OVERSAMPLING) = (66MHz/66/5/32) = 6250 reports per second [*]

Secondly, it opens all those devices twice, one time for the
Device.IdleNotifier, and another time for the Device.Input class. I don't
know if there is a specific reason why the IdleNotifier could not just use
the API provided by the Input class, thus avoiding to process every input
event twice.

In any case, I see significant shortcomings, i.e.

1) As to my knowledge, frameworkd should not be interested at al in the
   absolute position of the touchscreen device.  They're not useful to
   interpret without tslib anyway.  All frameworkd cares is the stylus
   touch-down and release events. 

   This could be solved in a number of ways

   a) provide a second kernel-level device that provides only the BTN_TOUCH
      events but doesn't report the ABS_X / ABS_Y values.  There are a number
       of potential solutions for this, all don't look very good to me

   b) not open the input event devices and rather periodically poll something
      like /proc/interrupts.  On the S3C24xx we actually have two different
      interrupts, one for touch events and one for ADC sample events.  This
      is obviously ugly and device-specific, but would be a quick userland
      solution without touching the kernel

2) I think it's very expensive to open all event devices and keep them opened
   all the time without knowing if any application is actually interested in
   those events.  Kernel drivers will possibly power up particular input
   devices that you're not even interested in.  And in the current framework/zhone
   system, all I can see is the on_power_key handling.

   Also, input device can actually be programmed to only report those
   keys/events that userspace is interested in.  This is done by the 
   keymap.  Events that you are not interested in can be disabled by
   setting the keymap entry for that particular key to KEY_RESERVED, AFAIK.

   However, that keymap is global for the hardware device, so if multiple
   processes open the same input device, they will have to be cooperative
   about this

3) What about things like the user later hot-plugging bluetooth and/or
   USB keyboards or mice?  Those events will be missed by frameworkd,
   since it only opens event devices that are present at daemon startup
   time.  Sure, you could hook into udev/hotplug.. but is this really what you
   want?  Isn't there anoter part of the system that inevitably has to care
   about all those input events anyway, like the X server (in systems that run
   X)?

4) The X server already has very sophisticated power management based on the
   screen blanking / DPMS interface.  It knows for how long time there were
   no input events, and can support the screen blanking.  Actually, since xglamo
   just uses the fbdev-IOCTL based blanking, and the glamo kernel driver
   uses the notifier_chain to send an event to the pcf50633 driver, I belive
   the screen blanking/unblanking should already work, even without the
   frameworkd.  You can also adjust the time until blanking.

[*] yes, the touchscreen should not report that many samples. I think setting
    it to the highest prescaler (resulting in 258kHz GCLK and thus 52kHz sampling
    rate, oversampling by 256 and resulting in a 201Hz event rate should be
    sufficient - but this is an independent problem of the kernel driver and
    i think frameworkd should not even have to parse those.

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone