The messages from the new driver code are:
TSC2301: Pen down data with no irq
TSC2301: Data available after penup timer
(N810 messages are TSC2005:...)
They will be produced if the driver detects lost data, which may or not may happen in your (or even any) N800 (in my N810 it happens for sure). But even if there is no hardware failure for the driver to correct, the new code shouldn't cause any harm.

The new kernel works perfectly, I tried drawing for quite a while but did not get any messages, though it feels better but it can be also placebo effect =), anyway thanks for all these, I still use my n800 almost daily and sadly I have been hit by the dsme bug so I have to buy a new battery as it reboots constantly when charging but otherwise it is still as good as new and works perfectly when not charging.

maacruz
Some people (from n8xx.com) (and me as well) found Diablo-Turbo drains battery MUCH faster. Usually I charge my n810 once per two days, last night I charged it and in the end of the next day with 2 hours music listening and 1 hour BT + Opera my n810 was a bit less then dead.

There are only two things that may have an impact in battery life:
1- The dsp_op state: If the cpu is configured at 400 MHZ instead of 333, battery life will be shortened when playing music. By default it is at 333, but you can check it; play some music and "sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq"
2- The touchscreen driver has a 75 ms poll, but I doubt it has much an impact in battery life, since it lasts microseconds, but I use the device very heavily so may be I don't notice it. I could make it tunable so it can be altered or switched off.
You should make a testing protocol to make sure the change in battery life is for real and how much it is. I find opera to be a big battery drainer, in particular if javascript is enabled.

EDIT: If the dsp is not in use, the cpu governor also has a say in battery life. The SD scheduler makes small changes to the nice load definition, so may be this could affect how much time the cpu is in each op state. Make sure that in your test protocol you check /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state before and after.

Does the SSU kernel poll the touchscreen? If not, does the DT kernel continue to poll at this rate while the screen is off or locked?

--

Do you know how to tell if the DSP is active? I'm thinking about displaying something in ASUI when it is and also add a toggle to easily change the op_dsp state.

In the Opera thread it is stated that the browser do not let the system sleep while the browser is open, much the same issue that was had with the terminal at one time (and may still have, dunno).

The SSU kernel relies only on the irq, so no, it doesn't poll. The DT continues polling at this rate even if the screen is locked or turned off (the poll isn't actually for touchscreen data but just a check to see if there is data available). While I haven't specifically tested it, I think that the touchscreen is never disabled, and the data is simply discarded at a higher layer when the screen is off.

Anyway, I can make a test kernel with tunable polling, then we can meassure if it has any impact by leaving the device alone for some hours with and without polling after a full charge.

Sure!
/sys/devices/platform/dsp/state is 0 if the dsp is not active.
Having such a toggle would be great, I was about to ask you the same. Beware that the op_dsp can only be changed if the dsp is not active, otherwise it throws a device busy error. I'll see if I can modify the op_dsp patch to allow changes on the fly, since the current op state can be modified by writting to /sys/power/op_active even with the dsp active.

[uncloaking...]
I wonder if this might be because of ramzez. I thought I noticed decreased battery before with the vanilla n810 kernel and ramzez installed when I tried it before.

- John
[cloak on..]

Well there will be some extra cpu activity compressing and decompressing the swapped out data.

If the tablet is locked, it should be - "1" is written to /sys/devices/platform/omap2_mcspi.1/spi1.0/disable_tp by MCE/SystemUI AFAIK. My understanding of the kernel is rudimentary but if the sysfs interface is anything like the procfs one, isn't a function (via a pointer) invoked when a file is written/to be written to, so even if it's not "disabled" (i.e. events are still picked up but not acted upon), you can still get notification and stop the polling accordingly?