I have more complex event processing logic now that handles every possible condition (including "reserved" events), and I am very certain now that the swapped coordinates when you rotate across a 90-degree boundary is caused by a firmware bug. There is nothing more that I can do in my event processing except ignore the "slot" assignment events (that tell which finger the coordinates belong to) and just assign them to the last known finger position that was the closest to the four possible positions when swapping the new X or Y coordinate between finger positions.
This workaround should work fine as long as the distance between fingers is greater than the distance between sample points on a pair of fast-moving fingers. It would be a problem if the values near each other got swapped, but luckily, it is the OTHER coordinate that gets swapped, so this should be a reliable workaround.
All I did by rewriting my event handling logic was to become absolutely convinced that it is a firmware bug, even though I cannot find it in the GPL source code (yet)...
P.S. I am even handling the touchscreen "relative coordinate" mode (i.e. "mouse" mode) events now, so when I figure out how to switch the driver to relative mode (it looks like it uses a /proc for that), then we can let the driver do it instead of simulating it at the application level.
