Ticket #2243 (new enhancement)

Opened 10 years ago

Last modified 10 years ago

[Xglamo] some motion events are thrashed

Reported by: Richard.Kralovic Owned by: openmoko-devel
Priority: normal Milestone:
Component: unknown Version: FSO-MS2
Severity: normal Keywords: Xglamo
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: yes PatchReviewResult:


When the xserver is busy, it tries to "optimize" consecutive movement events. In particular, it throws away some events that has not been processed. This is very unpleasant behaviour when input method based on gesture recognition (e.g., qwo) is used. In this case, quality of the recognition is severly degraded.

As a workaround, it is sufficient to comment out lines 100-106 in mi/mieq.c, as indicated by the attached patch (tested on xserver-kdrive-glamo-1_1.3.0.0+gitr9b28d998424c77fbc057dd3a022ccbb122793a52-r3, FSO milestone 5).


mieq.c.patch (470 bytes) - added by Richard.Kralovic 10 years ago.
linux-openmoko-2.6.28.patch (1007 bytes) - added by Richard.Kralovic 10 years ago.
xserver-kdrive-glamo.patch (692 bytes) - added by Richard.Kralovic 10 years ago.

Change History

Changed 10 years ago by Richard.Kralovic

comment:1 Changed 10 years ago by Richard.Kralovic

To further improve the quality of gesture recognition, it is imho helpful to enlarge the event queues in the touchscreen kernel driver and Xglamo (as in linux-openmoko-2.6.28.patch and xserver-kdrive-glamo.patch). On my system, it helped to avoid losing movement events under heavy load and writing recognition was much more reliable. Is there any reason why the default event queues are so small?

Changed 10 years ago by Richard.Kralovic

Changed 10 years ago by Richard.Kralovic

comment:2 follow-up: ↓ 3 Changed 10 years ago by arhuaco

Warning: Sleepy human typing. Grammar glitches expected.

Hi there.

I do not know about xglamo but in s3c2410_ts.c this buffer does not have to be that big.

I will explain what should happen in case it helps you with what you are trying to track.

In event_send_timer_f (timer callback) a call to s3c2410_ts_start_adc_conversion is issued right before reporting the coordinate to the input layer. This call tells the hardware to start a conversion and it should take it about 0.45ms(IIRC) with current settings. Since event_send_timer_f is a timer callback ts_input_report is not allowed to sleep.

Thus we get something like...


  • schedules hardware conversion
  • gets coordinates from buffer
  • reports to the input layer

... do more things if we have more data in the FIFO but return ASAP.

At some moment the stylus_action IRS should be called, most likely after we have already sent the previous event to the input layer.

Unless you are actually getting the "event_send_timer_f failed" message in dmesg things should be OK on s3c2410_ts.c side. I don't think it will happen but if you ever get this message it is a bug ... if you get this bug please let us know.

comment:3 in reply to: ↑ 2 Changed 10 years ago by Richard.Kralovic

Many thanks for clarifying the function of the buffer. I was not sure about this one, I'll put it back to the old size and test it. I am quite sure that the QUEUE_SIZE in mieq.c in Xglamo is relevant. I am still not sure about the buffer size in evdev (kernel), but it seems to me that if this is small, then slow clients (Xglamo) must miss some events.

comment:4 follow-up: ↓ 5 Changed 10 years ago by arhuaco

Are many of them trashed?
About half?

I guess that a good way to start is rule out kernel interference.

You might want to try two things:

1) Enable CONFIG_TOUCHSCREEN_S3C2410_DEBUG in your config.
2) Try with this app (which also prints messages, you might want to modify to measure what you need to). http://svn.openmoko.org/developers/tick/touchtest/touch_test.py

This way you see if something is actually getting lost and you will check what the kernel actually sends.

When you move the stylus fast the TS driver might send points at half of the rate it usually sends them it I think. Perhaps this is what you're seeing.

comment:5 in reply to: ↑ 4 Changed 10 years ago by Richard.Kralovic

I think the kernel driver works fine. My major concern is the way how Xglamo handles movement events. I'll make some more tests if the kernel modifications are necessary at all, maybe this is not the case. I am not sure about how exactly the in-kernel evdev framework works, but if I understood the source correctly, then at least the queue size in evdev.c (EVENT_BUFFER_SIZE) needs to be larger. Otherwise, if there is a slow client (such as Xglamo), some events (correctly reported by the neo touchscreen driver) are forgotten due to queue overfull before Xglamo actually reads them from /dev/input/eventX.

comment:6 Changed 10 years ago by Richard.Kralovic

After some more testing, it seems that no kernel modifications are necessary. Modifying the motion event handling (as in the attached xglamo patch) solves the problem completely (at least for me).

Note: See TracTickets for help on using tickets.