fix for Rotary encoder

[Blaubart]

The rotary encoder is now working again to control the respective items in the menu. Solves this problem:

#89

[linuxianer99]

@MaxKellermann: Does this patch make sense ??
Or is there a better way to fix this problem ?

[MaxKellermann]

Somewhat related bug report: XCSoar/XCSoar#625

This change is a dirty kludge, which undoes a side effect of https://github.com/Openvario/meta-openvario/blob/warrior/recipes-apps/xcsoar/files/0007-Disable-touch-screen-auto-detection.patch ... which already was a dirty kludge. So it's one dirty kludge stacked on top of another dirty kludge.
Such things don't make me happy. I must admit that the XCSoar input code is very far from perfect, but this isn't a proper solution. This may be short-term ok to merge for OpenVario only, but OpenVario should keep its set of patches as small as possible, and we better search for a general solution for all targets.

[linuxianer99]

OK ... think i got the point.
As there is already an open issue in the XCSoar project (XCSoar/XCSoar#625), we can merge this for the moment.

@Blaubart can you please work on XCSoar/XCSoar#625 to find a better solution ??

@kedder Think we can merge ...

[kedder]

@MaxKellermann, I agree, these patches are not great. The reason they exist is nobody could come up with a generic solution to these problems that would fit into mainline XCSoar. I can see how changes in this behavior can affect users on devices I might not even know about.

OV kinda have a pointing device, but it is not primary way of input and it is there for "backup" (when navigating with arrows is not possible). The joystick emulates a mouse, but actually expected to behave more like a touch input (less precise), because precise clicks are very hard to do in flight.

This breaks assumptions made in XCSoar, but I suppose these assumption are not made for no reason and some users depend on them.