[maemo-developers] [maemo-developers] Huge bundle O' year-end questions

[From: Jason Mills]

A rather lengthy list of questions & comments after having played with my
N770 for a few days, and doing a bit of poking around. Not all of these are
for my personal consumption, but all appeared to be missing from the
Developer FAQ as it stands now. I'll be happy to back-integrate the answers
as needed.


OMAP1710:
* How does one get access to the hardware Random Number Generator? (Is that
what /dev/urandom is pinned to?)

* How does one get access to the hardware crypto accelerators? (SHA1/MD5,
DES/3DES)

* How does one get access to the hardware/software Java acceleration?

* Is it possible to get access to the ARM9's "secure" mode to lock down a
segment of memory and processor space for crypto stuff? The processor itself
supports it, but I don't know if Maemo/Hildon do/will.

* Has T.I. delivered all required docs/sample-libraries/what-have-you to
Nokia and the Maemo.org teams so that the N770 and other Maemo/Hildon devices
may take full advantage of this slick bit of silicon?

* Would it, in that context, be advisable to separate the OMAP1710 from the
earlier bretheren (OMAP16xx f'rexample) when dealing with the Linux - ARM9 -
OMAP1xxx kernel branch, since they feature radically different cache sizes
and value-add functionality?

* Why does the hardware currently report that frame-buffer acceleration is
-disabled-? (At least, that's what I'm gathering from the value in that
particular SysFS node)

*****

Kernel/Compiler:
* W/r2 hardware crypto, no crypto modules were enabled for the Linux kernel
(2.6.12.3-omap1) currently in use. Was/is this pending addition of said
hardware crypto support?

* I noticed that the kernel was compiled using "optimize for size" (-Os)
rather than "optimize for speed" (-O2 or -O3), which seems to be the correct
methodology for ARM9, assuming it has the same cache size issues that the
IA-32 Centaur does... "optimize for size" actually yields faster code, since
you end up with fewer cache-misses. Why isn't the same optimization
recommended for ported applications?

* I also noticed that the kernel had a number of debug features set, which
(IIRC!) slow the kernel down and add bloat, no? (CONFIG_DEBUG,
CONFIG_FRAME_POINTER, etc...)

*****

Memory:
* Why does RAM fragment -so- quickly and so badly? I can go from ~5% to ~60%
by just launching a single application.

* Does the ARM9 architecture suffer a large performance penalty for
fragmentation like this? (user perception says yes, but...)

* As an experiment with the 2005 wk 45 build, I set up a 8MB swapfile on the
RS-MMC, enabled laptop_mode, and did some useability tests. Although
performance didn't change much for the middle-case, it was much better for
the high-constraint case (i.e., multiple applications running concurrently).
Perhaps this could be a Control Panel applet of some sort for Power Users?
(FWIW, fragmentation rates still remained very high)

* In addition to the swapfile, adding `ramdefrag` running in a ~5 second loop
with "optimized" defragmentation improved overall perceived responsiveness of
applications.

*****

Time:
* Is there direct RTC access?

* Could "auto wake" be achieved by setting the RTC timer alarm for a future
point in time, and then running a suspend-to-ram operation?

*****

Bluetooth:
* Could someone with some additional insight into the user input paths
determine what about the hardware keys and/or touch-screen cause the OS layer
to determine that the system remains active? (in relation to next question)

* Could that same keepalive mechanism be integrated into the Bluetooth HID
driver layer, rather than the current kludge (as pointed out by the
developer) of hammering on the Hildon-layer keepalive function for every
single keystroke?

* Is there any way to get the Bluetooth HID driver layer to coexist happily
with the on-board HID driver layer, such that the tablet pen and hardware
keys can still be used while a Bluetooth keyboard is active?

* Has anyone tried out the Bluetooth version (with proper HID personality) of
the FrogPad wearable keyboard? (I'm likely ordering one RSN, and willing to
do some proof testing if needed)

*****

User Interface:
* The "Maemo SDK Tutorial" (currently listing a dec' page with versioning
info BTW) seemed to be missing a few bits of information about the UI as it
stands currently. I cobbled together a few sample chunks of HTML showing
various UI scenarios, including those which were missing (Full Screen @ 4:3
with blackout bars, Full Screen @ 16:9 with blackout bars, Normal & Full
Screen with Dual Toolbars visible) as well as a sample page showing which
areas are within the "safe" render-zone given various scenarios running
Maemo/Hildon-ized Opera. Whom should I pass these along to?

* It'd be useful to have a "Power User" mode for the power key operation
menu, including at minimum a "Reboot" function to complement the existing
"Shut Down" function. Adding "Suspend to RAM" and "Suspend to Disk" would
also be nice.

* Since the "Home" key is special, is there a way to make it dual function,
similar to the soft power button on ACPI compliant desktop PCs? That way it
could be co-opted for short-press-duration use as an application cycler
(Alt-Tab behavior), but still used as the failsafe with a
long-press-duration.

* Left-handed mode is a nice-to-have, and the X11 R-and-R 180 degree rotation
appears to take care of the 80% case... but being a hardcore SouthPaw, I'm
-still- more annoyed at the lack of things like a hyphen, underscore, and
pipe character in the default "en_US" virtual keyboard layout (non-Shift'd).

*****

Backups/Flash-Upgrades/Restores:
* Why doesn't the Hildon/Maemo set of specifications require all applications
to simply register their required backup/restore file locations within GConf?
That seems to be the more scalable solution to handling the "how do I
properly back-up, flash-upgrade, and restore my N770 as an end user?"
problem, rather than the shellscripting hacks favored by us geeks.

* Flash upgrades should not -by default- happily blow-away your hardware
security code. This seems like it should be the "last ditch" mode, for
R&D/rescue use.

*****

Applications:
* PIM functionality would be nice, but sync seems to be a BIG sticking point.
Is there some PIM-vendor agnostic set of standards (RFCs, perchance) for
interchange of PIM related data? "Contact" and "Schedule" objects are the
most common ones likely to be required for mobile uses (N770 <-> Phone <->
Laptop/Desktop PC)

* `osso-xterm` needs to be able to selectively ignore the hardware keys...
right now they inject extraneous control characters ("Home" key being the
worst offender).

* `GAIM` needs to stop crashing every time I lose 802.11b/g signal for a
moment. :-) ... and the 802.11b/g driver needs to stop locking up
(literally). I'll be happy to provide dmesg data on the 802.11b/g driver
lockup problem if requested, it looks like some sort of status/watchdog kill.

* `GPass` needs to be ported over as soon as the hardware crypto acceleration
is available. I'm willing to consider bribing people for this one, since the
one -essential- thing for SysEng/SysAdmin is secure PW storage. :-)

*****

That's all for now...

-JMills