[Development] automated bulk change closing old issues in the "Need more info" state

Shawn Rutledge Shawn.Rutledge at qt.io
Tue Nov 20 11:42:20 CET 2018


> On 20 Nov 2018, at 08:14, Uwe Rathmann <Uwe.Rathmann at tigertal.de> wrote:
> 
> F.e the QPA/EGLFS stuff is full of problems, when working with multiple 
> touch screens. But obviously this is a rare combination and the Qt 
> Company seems not being interested - or lost the competence - in fixing 
> it.

I’m interested in having it work some day, because the inconvenient means of configuring that (by writing JSON files ahead of time) is holding up one of my spare-time projects.  But, I’m interested in too many things, and also don’t know exactly what to do about that issue right now, since I’m lacking some experience that others have with trying to support specific embedded systems.

I think ideally it should be auto-configured somehow when possible.  That might involve a database of known touchscreen monitors, but we should get that from a third party, not maintain it (just like there are databases with EDID info, USB IDs, PCI IDs and such things).  Maybe it already exists?  But there also needs to be API for dynamically configuring the screen-to-touchscreen mapping, and saving and restoring known-good configurations when the auto-configuration goes wrong.

Since QTouchDevice is public and does not inherit from any common device class, I figure getting the API right is a Qt 6 task.  I want to have a device hierarchy so that devices in general can be associated with each other (associating screens and touch input devices is just one case, but probably there will be others).

Presumably the Plasma project has the same problems with wanting to dynamically configure hotplugged screens (some of which might be touchscreens).  I don’t even know the status… since Plasma on Wayland is still unstable even now, AFAICT.  (I wouldn’t be surprised if that’s our fault too.)



More information about the Development mailing list