@mj01 Up to you to use or not to use debugger to get more information about your issue, I'm out...

Problem solved. The issue was the default seat inside of the compositor was unset. Means the keymap attributes were emtpy. I have set it manually and now it works. [image: 17695744-788a-46e5-928e-d342b7238507.jpeg]

Even if it's old, I would try with this version if Qt to see if you have the same issue going on.

I also encountered this problem, can anyone solve it?

Hi, AFAIK, QSystemTrayIcon doesn't use dbus in its Linux backend. That might be related to your situation.

@hskoglund I already have an underlying data store and I'm using a subclass of QAbstractTableModel to bridge it into a Qt GUI. Making two in-memory copies of that data store and then jerry-rigging View-like synchronization between the actual data and two widget-specific data stores (plus all the requisite automated testing to make sure it works reliably) seems like the exact opposite of what I want.

@Ajith_P_V , maybe, you need not RGB, but BGR model. I didn't work with graphics in qt, but in OpenCV all work was gone in BGR.

This topic is old, but nevertheless, for the sake of completeness... Do not close ssh session, otherwise the forwarded display would become invalid.

Hi and welcome Maybe this has some interest. https://forum.qt.io/topic/56672/need-help-with-performance-of-qt-application-when-x11-forwarding

Hi and welcome to devnet, What backtrace do you get from the crash ?

Hi, Did you compile your application with your desktop Qt and then copied it over the RPi2 ?

Thanks for the reply. This is using intel graphics, and unfortunately your workaround does not help. After your message, I've tested the same code from a newer live image and also on my more up-to-date laptop (which has similar hardware) and I can not reproduce the issue in either of these cases. On the affected machine, I tried updating the intel driver and mesa, but this did not solve it, so I guess it probably needs the kernel or qt packages updated as well. Unfortunately, this is not an option at this point. I've worked around the issue by re-implementing paintEvent() to do something like the following if (no_pixmap_set) { pos = calculateTextPosition() QPainter::drawText(pos, text); return; } QLabel::paintEvent(event); Which seems to work just fine. In fact, re-implementing the paintEvent has given me the chance to animate the image changes which looks pretty nice, and it will be easy to simplify the code a bit when all my machines are fully updated and the glitch is gone. Thanks again!

The 8 bit paletteized option (PseudoColor in X11 speak I think) is an interesting idea. Last time I used that stuff was late 80s when true RGB displays were much more expensive; I was glad to see the back of it. We did indeed used to use a custom palette depending on what we were displaying: for greyscale images we used some palette with something like 224 greys and the rest for a few "UI colors"; for color images we had to dither to 3 bits red, 3 bits green and 2 bits blue and it still looked terrible. No idea whether Qt supports such customization; documentation at http://doc.qt.io/qt-4.8/qapplication.html#setColorSpec suggests Qt has it's own palette built-in for such purposes. I'd be amazed if anyone was seriously using this sort of palletized graphics display these days when it seems OpenGLES is defines the min.spec graphics for even the lowliest embedded chips. But if you think the 3:1 or 4:1 reduction in bandwidth moving from a 24/32-bit "visual" to an 8 bit one is all you need, AND most of your bandwidth hogging content is greyscale images, then my instinct would be to just look into displaying the images by sending them to the server (display) side using a single channel OpenGL GL_R8/GL_INTENSITY8 texture, and appropriate GL commands to texture that to a view-filling polygon. This changes the solution focus a bit from messing around with Qt to messing around with OpenGL though.