All,
Qt 5.5 on Jessi Raspberry Pi with Pi2.
One of the screens has a flickable QListWidget item with a QScroller. The list widget allows for drag and drop arrangement.
Touch screen shows up as follows:
udevadm info --name=/dev/input/event3 --attribute-walk
looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:0457:1072.0003/input/input3':
KERNELS=="input3"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{name}=="USBest Technology SiS HID Touch Controller"
ATTRS{phys}=="usb-3f980000.usb-1.3/input0"
ATTRS{uniq}==""
ATTRS{properties}=="2"
udevadm info --name=/dev/input/event3 --attribute-walk
looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:0457:1072.0003/input/input3':
KERNELS=="input3"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{name}=="USBest Technology SiS HID Touch Controller"
ATTRS{phys}=="usb-3f980000.usb-1.3/input0"
ATTRS{uniq}==""
ATTRS{properties}=="2"
To copy to clipboard, switch view to plain text mode
Yes, I realize there is no driver loaded, but eglfs within Qt seems to be working just fine for most things. This is a console boot, no X or any other window manager running application doing serial and other communication. Most of the user interface is direct button touches.
The maintenance/configuration mode uses the QListWidget as a menu. (Some people mistakenly believe Apple does something worth copying...they don't.) When a mouse is enabled and used the menu is snappy. Double click selection works fine. When using the touch screen one has to go slow and it seems to take at least 4 rapid clicks to make an item work.
Is the EGLFS support built into Qt 5.5 not capable of handling flickable list type stuff without having a driver do the bulk of the work? Everything works perfectly except for this menu. I have to exhaust all options before we can put 2 behind the ear of this singular vestige of Apple influence.
Getting the hid-multitouch driver to support the device fully requires hand modifications to kernel source code. That is off the table for this project as it blocks any upgrade path until one determines what source modifications are necessary to any new kernel. This system isn't "burned" when it leaves, it is field upgradable so do not want to create a severe maintenance burden.
Thanks
Bookmarks