What sort of device are you on?

It’s a sh7724 based board. Not having any X11 or something else.

I continued my investigation and found also the QScreen-class, unfortunately the derived class QLinuxFbScreen does not implement the function mapToDevice which I think would provide the necessary functions.

Is the menu you are referring to some always-present system menu? Or is it something you draw? You could always patch Qt to implement the missing function or maybe sub-class QLinuxFbScreen perhaps?

Does it matter that the menu is not taken into account if that part of the screen is not paintable anyway? Not sure what your end goal is.

The menu is kind of system menu.

But my goal is to embed the output of a video hardware directly into a defined area of the framebuffer. To configure my video output i have to give it an address in the framebuffer where to put the output data. The ouptut area is defined by a widget with a qdirectpainter. Now i want to configure the hardware from within my QT application so data is put at the proper place within the widget.

But i can’t resolve the excact address of this widget containing the output area.

Or should I choose another way to output the data into the framebuffer?

Previously i wrote some code which recurse up to the most parent widget and adds all relative addresses to an absolute, but here was the problem that the system menu and i think also the window frame where not included.

Do you control the code for the system menu or does it always have a fixed size? If so you could either hack QLinuxFbScreen or subclass it and use that on your special device such that it takes into account the menu size by applying it as an offset.

Yes, i think it has fixed size. But I think in qt it’s configurable if it’s vivible or not, so I would have to write a lot of code to solve this issue. Isn’t the kind of elegant way to do this?

I’m confused. Are you saying that Qt itself provides this system menu? The last time I used Qt Embedded all I had was a bare framebuffer. I can’t recall seeing a menu. Hmmm, then again we ran our application as fullscreen. Do you have an image of the menu? What process is responsible for drawing it?

The menubar is also a widget, i started off with the ui template “main window” in qt designer.

Currently the application is a standalone app which is started with “-qws” option. So itself draws everything to the framebuffer, except of the videooutput which is done in a seperate thread.

But in general also in qt-emebedded you can run also applications in windows and not only as fullscreen.

Ah sorry I misunderstood. I thought you had some other application drawing a system menu like on a phone. Hmmm, in this case as you say the mapToGlobal() function should just work and take the menu bar and window decoration into account.

Which version of Qt are you using? Can you reproduce this on your host machine running your application via qvfb? Can you post a small compilable example that reproduces it please?

With mapToGlobal i experienced the same problems. Doesn’t it use also the QScreen instance?

I will have to wait to next week to provide some example code and reproduce it, but i will keep you informed. Thanks so far.

No worries. It should just work but if not then we’ll see if we can squash the bug.

Finally i found my failure. I didn’t realize maptoglobal returns the position in framebuffer in bytes and not in pixels. So when calculating it to pixel address in bytes must be divided by the depth in bytes.

So the problem can be considered as solved. Thanks.

Hmmm, that is not clear from the docs at all. It reads as if it should be in pixels and I’m pretty sure that’s what it is on the desktop. Maybe something is forgetting to do the byte->pixel conversion when using the framebuffer driver in Qt Embedded?

Might be worth testing on the desktop and comparing. It is either a bug in Qt Embedded or a documentation bug (if it is intended to be bytes it should say so).

So i did some further investigation and could bring up the core problem with the coordinates.

If mapToGlobal is called from the top-level widget the coordinates are mapped correctly.
If mapToGlobal is called from within the class it does strange things.

How can i upload some file, wrote a little test to reproduce this problem?