[Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

[Ed Leaver]

Thanks Thiago, Jani, Kevin.

Some testing revealed the 5.8.0 and 5.9.0-beta431 sources all compile 
and install just fine when given the -no-evdev configure switch, which 
disables evdev gamepads plugin. So I opened the bug against Packaging 
and Installation instead:  QTBUG-59740.

Basically, the offline qt-opensource-linux-x64-5.7.1.run installs it's 
default selections without issue, and starts it's QtCreator 4.2.0 on 
CentOS 6.8, but subsequent qt-opensource-linux-x64-5.8.0.run, 
qt-unified-linux-x64-2.0.5-online.run, and 
qt-unified-linux-x64-2.0.5-1-online.run all fail to install any 
Qt-5.7.1, Qt-5.8.0, or 5.9.0-beta431 on CentOS 6.8

While I could open an evdev bug, it appears at this point as though that 
issue has already been addressed.

Ed Leaver


On 03/23/2017 05:42 PM, Thiago Macieira wrote:
> On quinta-feira, 23 de março de 2017 14:54:20 PDT Ed Leaver wrote:
>> Hi Thiago,
>>
>> BTN_TRIGGER_HAPPYxy are a group of kernel #defines, apparently for
>> drivers not supported by the 2.6 kernels. Here are my dev notes:
>>
>>        ... Qt-5.8.0 then compiled against gcc-5.4.0 with only one minor
>>      problem:
>>     
>> qt-everywhere-opensource-src-5.8.0/qtgamepad/src/plugins/gamepads/evdev/qev
>> devgamepadbackend.cpp does not compile on CentOS-6.8 (apparently) because
>> the
>>      2.6.32-642.el6.x86_64 kernel is too old
>>      and does not define BTN_TRIGGER_HAPPYn (n=1,2,3,4). On Fedora 25
>>      these are in
>>     
>> /lib/modules/4.9.14-200.fc25.x86_64/build/include/dt-bindings/input/linux-e
>> vent-codes.h I patched qevdevgamepadbackend.cpp with those values:
>>      #ifndef BTN_TRIGGER_HAPPY1
>>               #define BTN_TRIGGER_HAPPY1 0x2c0
>>               #define BTN_TRIGGER_HAPPY2 0x2c1
>>               #define BTN_TRIGGER_HAPPY3 0x2c2
>>               #define BTN_TRIGGER_HAPPY4 0x2c3
>>      #endif
>>      directly above QEvdevGamepadDevice::resetConfiguration(), and then
>>      the whole Qt-5.8.0 source compiles
>>      just fine (gcc-5.4.0), although there is a minor issue with final
> Please report this issue up to here. The developer will determine whether the
> #define is acceptable or not.
>