I have never found any CAL documentation personally, so I don't know if this is actually documented somewhere, but while coding a command-line tool for editing the R&D flags on device, I discovered that a garbage (one that doesn't match an existing R&D mode flag, as far as I can tell) string written to the "r&d_mode" CAL area through the libcal-dev function cal_write_block will cause, of all things, the "Enter lock code" screen to break (upon entering the correct code, it freezes the device when you press the key to enter the code and unlock the device. I haven't bothered to test what happens if the code is wrong or if the state of the program that wrote to the cal area at the time of screen lock/unlock changes the result).

Far less interestingly, it also causes libcal using programs (mine and qwerty12's, from which I learned the way to actually use libcal in lieu of find-able documentation) to hang when trying to access the R&D mode CAL area - but that's at least predictable. The lock screen makes less sense to me. Anyone know why/how the lock code entry screen has anything to do with CAL?

I don't know if this info is useful to anyone out there at ALL, but I figured I might as well post it if anyone cares to know.

The good-news part is that writing a bad value to the R&D Mode CAL area will cause issues only until you've shut down the device - so far, all wrong writers (through the cal_write_block function, granted, which probably has safeguards) I've done were half-ignored upon rebooting (the wrong string was still in there, but you can access CAL again and override it once more).

The lock-code is stored in cal (encrypted on the N900, the key, not cal)

I love you MohammadAG. You, with your knowledge I can never find on my own.

On a related note, does getbootstate read the R&D flags (if those who know feel that's something I should be able to find by digging into the code or various components, feel free to smack me)? Or something else? Because I know /sbin/preinit has an if-then it it dealing with r&d mode being on, but I haven't looked further; obviously that means something before that /sbin/preinit line checks R&D flags. Which suggests getbootstate would be the likely candidate.

I ask because I'm using pali's opensource getbootstate backport from MeeGo on my N900 instead of the closed-source stock one, and that might be what's letting me get away with messed up strings in the r&d_mode CAL area.

I've also deduced that the reason I was getting freezes was probably NOT the actual string written to CAL being bad, but because I was getting bad strings due to errors in my code, which cause my program to error out before it could run "cal_finish", which presumably made other programs unable to run "cal_init" properly. The reboot would leave cal no longer under the impression it was open, thus 'fixing' the issue.