[Nook HD, HD+ Android Development] Jon Lee:
Perhaps in a way. This requires a huge writeup.

In a tangible sense. I've noticed no more touch screen "jitters" (a real but random phenomenon), also the "four tap test" when scrolling from apps through widgets very quickly works perfectly every time now (stuttered before). Also no more kxtf9 IRQ wuf dmesg logs.

Also, like Mike, I'm noticing graphical glitches.... but MY touchscreen hasn't crashed yet... (which is what/why I wanted testers for).

Ok, the touchscreen issues have been with us since forever. When I first started with this it would crash every few hours (constantly). I've been aware of it from the beginning. Early on I made some improvements by changing the I2C bus core, which helped considerably. Also, for whatever reasons, the older "non fuzz" driver was slightly more stable than the newer fuzz driver. This second time around for touchscreen issues, I decreased the word length and doubled the output data rate (on parts of) the touchscreen driver to the I2C bus. Ok, the kernel is not crashing. The touchscreen firmware itself is crashing (obviously has its own microcontroller). All indications are this is due to I2C bus conflicts with the kxtf9 accelerometer. If one thinks about how the I2C bus is a low level service that the kernel must devote resources to, then one can see how this would affect system wide performance (IE graphical glitches).

It's obvious BN had troubles with this from the beginning. It appears that a lot of effort was spent trying to solve it. The touchscreen driver is the "dirtiest" driver in our kernel. It has tons of debugging code and leftover fragments. It appears they hired an independent expert to come in and audit the code.

If the I2C bus is bottlenecked, then the whole system is bottlenecked trying to serve it and push the data from the I2C clients. That's why the second touchscreen "fixes" made a difference.

So, my theory is that a bottleneck/data collisions on the I2C bus with the kxtf9 accellerometer, are causing a firmware crash of the ft5xo6 touchscreen (and kxtf9 IRQ wuf's). This becomes worse when the system has less resources to devote to the I2C bus.

So, although not immediately obvious, the kxtf9 driver I2C parameters will affect the system and touchscreen.

In proof, the kxtf9 driver has a snippet of changed code.

err = i2c_smbus_write_byte_data(tf9->client, CTRL_REG1, buf[0]);
//	err = kxtf9_i2c_write(tf9, CTRL_REG1, buf, 1);

I didn't make that change, someone else did. If you revert that change, the touchscreen problem becomes worse.

So looking at this, trying to figure out what one can do (short of touchscreen firmware upgrade)...

This third time around, I altered the output data rate of the kxtf9 driver.

the parameter is in mach-omap2/board-ovation.c

struct kxtf9_platform_data kxtf9_platform_data_here = {
.min_interval = 1,
.poll_interval = 1000,

.g_range	= KXTF9_G_8G,
.shift_adj	= SHIFT_ADJ_2G,

/* Map the axes from the sensor to the device */
.axis_map_x	= 0,
.axis_map_y	= 1,
.axis_map_z	= 2,
.negate_x	= 0,
.negate_y	= 0,
.negate_z	= 0,
.data_odr_init	= ODR200F,
.ctrl_reg1_init	= KXTF9_G_8G | RES_12BIT | TDTE | WUFE | TPE,
.int_ctrl_init	= KXTF9_IEN | KXTF9_IEA | KXTF9_IEL,
.int_ctrl_init	= KXTF9_IEN,
.tilt_timer_init	= 0x03,
.engine_odr_init	= OTP12_5 | OWUF50 | OTDT400,
.wuf_timer_init	= 0x16,
.wuf_thresh_init	= 0x28,
.tdt_timer_init	= 0x78,
.tdt_h_thresh_init	= 0xFF,
.tdt_l_thresh_init	= 0x14,
.tdt_tap_timer_init	= 0x53,
.tdt_total_timer_init	= 0x24,
.tdt_latency_timer_init	= 0x10,
.tdt_window_timer_init	= 0xA0,

.gpio	= KXTJ9_GPIO_IRQ,
};

namely the data_odr_init register. The corresponding output data rate table is in the kxtf9 driver.

} kxtf9_odr_table[] = {
{
3,	ODR800F}, {
5,	ODR400F}, {
10,	ODR200F}, {
20,	ODR100F}, {
40,	ODR50F}, {
80,	ODR25F}, {
0,	ODR12_5F},
};

our original setting was 12.5 x frequency. If you take a look at an older, more complete, driver (in some ways), the 12.5 register isn't even coded for.

https://github.com/crewrktablets/rk3x_kernel_3.0.36/blob/master/drivers/input/gsensor/kxtf9.c

That should be a hint right there. OK, I changed it to 400 x frequency, which as is apparent with the graphical glitches is way too high.

The idea that I can improve system wide performance, eliminate the kxtf9 IRQ wuf dmesg logs, eliminate touchscreen jitters through a simple "magic bullet" setting had me excited... although, obviously, I'm interested in solving the touchscreen crashing bug. Through the changes I have made, mine doesn't crash but every several days to a week. This is a considerable difference from the beginning, but also makes it hard to test changes (working on subtleties).

Obviously I need to find the right setting, so I should probably drop it to 100 or 50f. Also, in looking at this, the poll interval could also have some impact for us as well (although I haven't messed with it yet).

Whew! That was wordy.

edit: Oh, also less bluetooth audio dropouts, which is also I2C related. Although, TBH, the second LS version which had the omnirom kitkat bluetooth stack had me spoiled. Behind the scenes, I've played with the bluetooth stack considerably... (replacing bluedroid with buez to get hcitool for fm work). I have come very, very close to getting it working (pairing, but no audio). I reverted back to bluedroid for this build...