On 01/31/2011 02:34 AM, Carsten Munk wrote:
Hi,
After the xinput2 patches came into qt, we have seen problems on IVI
(BMC# 12777 ) and N900 (http://bugs.meego.com/show_bug.cgi?id=10147)
regarding input not working. The problem seems to be that all presses
are seen as constantly held down. On N900 we've even tried to see if
upgrading evdev to latest upstream worked (xinput2 support included),
but no remedy.
Normal X applications work fine, but Qt apps don't work properly.
What is the story here and what is timeframe for it being fixed? I'm a
bit tired of seeing very low % QA reports in acceptance for 4 days in
a row :)
It appears there is a bug with the evtouch (at least) X input driver
such that button labels atoms are not being set correctly in the
XIButtonClassInfo structure provided by X -- which results in Qt not
being able to map the button presses to ButtonLeft. Those atoms are set
correctly when a USB mouse is used or the mtev input driver.
To confirm the above, you can enumerate the configured button labels for
input devices via xinput
$ xinput list --long "Virtual core pointer"
On a good system, you will see all of the button labels being displayed
for the aggregate set of input devices bound to the virtual core
pointer. Names like "Button Left" etc.
With the evtouch driver on IVI, you will see X complain about various
bad Atoms being provided when it attempts to enumerate the button labels.
Within Qt, the atoms provided by X are mapped to known values to
correspond to ButtonLeft, ButtonRight, etc. The code logic breaks down
in Qt's src/gui/kernel/qapplication_x11.cpp's
mapXI2ButtonToButtonLabel() since the label provided by X is bogus it
can't be mapped to a Qt button label, resulting in no button being
identified.
James
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
