Get absoluto position of a widget in the framebuffer

meem

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?

meem

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.

ZapB

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.

meem

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?

ZapB

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?

meem

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.

ZapB

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?

meem

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.

ZapB

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

meem

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.

ZapB

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).

meem

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?

ZapB

Please open a bug report in JIRA (http://bugreports.qt.nokia.com/) and attach a tarball/zip file of your test case.