There is an issue with programs compiled against qt4 (also ones compiled against qt3 may be affected, I do not remember) that update the gui from another thread rather than the main one and a call to XInitThread() is made. You can see a relevant thread of this problem in the qt-interest mailing list here: http://lists.trolltech.com/qt-interest/2006-06/msg00809.html Basically such an application will stall at startup if qt is compiled with the -tablet option. Currently this is hardcoded in the ebuild and as per the suggestions on the qt-interest mailing list disabling it (using -no-tablet) solves the problem. I can provide sample code that demonstrates the problem if this is required. I am hoping that the option of enabling/disabling the tablet support will be exposed in a use flag, so that I won't have to use permanently overlays for the qt libs. I use amd64, but since this is not a gentoo bug itself, probably affects all architectures. thanks.
This is something I've been meaning to do for a while now. I've changed the ebuild in qt-4.2.1 to default to -no-tablet, and it will turn on if wacom is in the INPUT_DEVICES variable in make.conf. I think this is a good solution since the only tablet support I can see is for wacom tablets.
(In reply to comment #1) > This is something I've been meaning to do for a while now. > > I've changed the ebuild in qt-4.2.1 to default to -no-tablet, and it will turn > on if wacom is in the INPUT_DEVICES variable in make.conf. I think this is a > good solution since the only tablet support I can see is for wacom tablets. > But that would cause problems to people that do have a tablet and want to run such an application, is that not correct? I assume the bug exists regardless of one having a tablet or not.
Possibly, but since you're the first one to report it I'm not anticipating a lot of issues. I suppose we'll have to solve it when it becomes a problem.
maybe the bug gets fixed along the way. thanks for altering the default behavior.
Created attachment 115421 [details] Sample program using XInitThreads to trigger lockup behavior
There is another related issue, this time with the xkb extension. Even though the -no-tablet workaround fixes the startup of applications, when qt (including the latest 4.2.3-r1) is compiled with the -xkb option (the default), applications using XInitThreads() will startup, but they immediately lockup once the user attempts to use the keyboard to provide input. To fix this instead of -xkb one has to compile qt with the -no-xkb option. I attached you a sample application with a qmake project so that you can hopefully reproduce the problem. Just in case, to build it you can do from the command line: $ qmake; make
Is this still a problem with qt-4.4.2?
No activity since 2007 and no response, so I assume this works with newer versions. Reopen if this is still an issue.
