Wl_display@1.error(xdg_wm_base@13, 4, "xdg_surface buffer does not match the configured state")

I am using a 7 " display with weston. The display is rotated counter clockwise by 90 degrees. So resolution ist 480x800 pixels. The weston screen is diplayed properly by using “transform=90” in weston.ini. If I try to start my own Application it always terminates with the message “xdb_surface buffer does not match the configured state”. What’ wrong?
log_xdg_surface.txt (10.0 KB)

Apalis iMX8qm
Ixora 1.1
Torizon 5.3.1
weston-vivante-2.2.0

Greetings @rainer9322,

I’m not very familiar with this error, so I’ll need some more information.

  • What kind of application are you running?
  • Does the error still occur if the display is not rotated?
  • Have you made any changes/modifications to TorizonCore other than rotating your display?

Best Regards,
Jeremias

Hello Jeremias,

  • The application is written in Java using Totalcross.
  • If the display is not rotated the application starts properly but the App of course does not fit the screen. If the screen is rotated only the white Area is shown for a few seconds and then disappears. The application itself does not crash and is still alive in its docker container.
  • Only added a splash image to the core and created the device-tree-overlay for the display

Best regards,
Rainer

display-fg07_overlay.dts (708 Bytes)

In the case where the display is not rotated is the display still cut off when you’re application is not running? Or is this just a graphical issue with the application itself? Basically what happens if you just run the weston container in the normal and rotated cases? Is the weston display output cut off like with your application?

Right now with the two pictures you provided it seems like display output isn’t fitting to your display. Seems like you might have incorrect timings for the display in the device tree.

I’m trying narrow down whether the issue is with the weston/wayland graphical stack, your display configuration, or with the TotalCross application.

Best Regards,
Jeremias

Hi,

  • If the screen is not rotated the app is shown with the correct widhth (480 px). The height of the app is 800 px and is cut to the physical screen height of 480 px.
  • If the screen is rotated the white area seems to be the attempt of the app to display it’s screen. The height of the white area is 480 px and I assume that the width is 800 px but it is horizontally cut off. The vertical position of the area is randomly distributed over the sreeen. Horizontally it is always left adjusted.
  • If I only run weston the rotated and non rotated displays are properly scaled and fill the whole screen.

Best regards,
Rainer

Given this information it would appear then that the issue is on the application level. Seeing as Weston properly scales and fits by itself. I don’t have too much experience with TotalCross applications but let me see if I can find someone who can comment here further.

Best Regards,
Jeremias

Hi,
are there any news concerning this issue?

Best regards,
Rainer

I’m currently escalating this to our partners at Totalcross to take a look since this is more their expertise. Still waiting to hear back from them on this.

Best Regards,
Jeremias

Hi,

are there any news about this topic? We urgently need a solution.

Best regards,
Rainer

I haven’t heard back from Totalcross yet due to their current support work-load.

However I’ve done some further testing and research here. I started by running a dummy Totalcross app to try and replicate your issue. Here were my results:

  • If I run the Totalcross app with no rotation, the app starts and runs with no issue.
  • If I rotate the display via weston.ini and then start the app I get the following error:
xdg_wm_base@13: error 4: xdg_surface buffer (1280 x 800) is larger than the configured fullscreen state (800 x 1280)

This error appears similar to yours but it has a bit more info. It seems the surface buffer is still sized as if the screen is not rotated. This then conflicts with the actual dimensions of the rotated screen.

I did further testing where I tried other graphical apps/frameworks. For example I tried Crank and Qt. With those frameworks they properly ran on a rotated screen and the apps themselves rotated properly as well. Which still leads me to think this is a quirk with Totalcross apps themselves.

I’m not an expert with Totalcross applications, but perhaps there’s a config or something in the code that may help.

Is it possible to set a screen size in the application?

Or is possible to instead rotate the application in the code rather than use the rotation in weston?

Perhaps posting your question additionally on the Totalcross forums/community may help: TotalCross · Enjoy Our Community | TotalCross · GUI Creator For Embedded, Mobile... Everything!

Best regards,
Jeremias

Hi jeremias,

partially I have found the solution by myself. If you take a look at:

You can see that three ENV-variables have been introduced with Totalcross 6.1.1 and later:
TC_WIDTH, TC_HEIGHT and ENV TC_FULLSCREEN.
If I set them in the dockerfile to
ENV TC_WIDTH=480
ENV TC_HEIGHT=800
ENV TC_FULLSCREEN=1
the application does not crash any longer.
But there is another issue now. The display has an offset to the right and bottom. The fullscreen variable seems not to work.

Kind regards,

Rainer

Well that is definitely a huge improvement. It appears that perhaps the Totalcross app isn’t finding the correct center/boundaries of the display.

In the changelog you referenced it states “When the full-screen is deactivated the TC is opened in a window…”. If full-screen is deactivated is the UI more centered/well-fitted to the display?

Hi jeremias,

if the FULLSCREEN is not defined the application crashes in the same way as in the past, even if WIDTH and HEIGHT are well defined.
I have investigated the TCVM Source-Code. In the TCSDL_Init-function you can find:

viewport.x = SDL_WINDOWPOS_UNDEFINED;
viewport.y = SDL_WINDOWPOS_UNDEFINED;

The define SDL_WINDOWPOS_UNDEFINED comes from the sdllib2 and the comment is ‘Used to indicate that you don’t care what the window position is’. I think it could be better to set it to SDL_WINDOWPOS_CENTERED.

So my idea is to build my own TCVM with this issue fixed. Unfortuantely there is only an outdated documentation at totalcross.com how to do this. Do you have an idea, where I can get actual docs?

Kind regards,

Rainer

tcsdl.cpp (8.3 KB)

The only docs I can find related to building the TCVM is here: totalcross-docs/how-to-build-totalcross-vm-wip.md at master · TotalCross/totalcross-docs · GitHub

However it is marked a “WIP”, but it appears the build process is mostly complete.

Best Regards,
Jeremias