User avatar
w4mmp
Posts: 82
Joined: Thu Mar 26, 2015 3:11 pm

Xorg utilization

Thu Apr 15, 2021 6:40 pm

Hello,

I am working on a hardware product that incorporates the RPi 4B (2GB) and a DSI display from DF Robot (https://www.dfrobot.com/product-1784.html). The application driving the display drives it quite heavily (an active spectrum graph and waterfall display are continually running).
When examining Xorg utilization I have the following observations.

With the line: #dtoverlay=vc4-fkms-v3d (commented out) of /boot/config.txt, Xorg utilization is about 25%. However as expected, the HDMI ports will not function. It is desired to have both the DSI display and a HDMI display available to the user. So to have both, dtoverlay=vc4-fkms-v3d is un-commented in /boot/config.txt. This does allow both the displays to be available to the user. However, this is where Xorg goes a bit nuts. Xorg utilization goes to over 80% with the same identical application running, over three times the utilization verses when the overlay is not active. This high utilization apparently causes some sluggishness of the spectrum display. Please note that even when both displays are configured to be available, the application is still only using the DSI display. There is nothing on the HDMI display other than an idle desk top.

So the question I have is why does allowing both displays to be available, cause such high Xorg utilization particularly when only the DSI display is being used by the application? And then the follow on question, what if anything can be done about it.

Thanks for your attention,
Ron
73,
Ron / W4MMP

User avatar
w4mmp
Posts: 82
Joined: Thu Mar 26, 2015 3:11 pm

Re: Xorg utilization

Fri Apr 16, 2021 3:58 pm

Help, please.

Should I post this in a different category such bug reports?
73,
Ron / W4MMP

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11056
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Xorg utilization

Tue Apr 20, 2021 11:05 am

Sorry, this isn't a sub-forum I routinely read. I don't know about other Pi employees.
For display related questions you're generally best to ask under "Interfacing (DSI, CSI, I2C, etc.)" if you want me to see it.

That display is a third party display that clones the behaviour of the Pi 7" touchscreen. Seeing as DSI displays do vary dramatically, and the Pi screen has an Atmel MCU for power management, I'm slightly amazed it actually all works.
That's unlikely to be the cause of any issue here.

vc4-fkms-v3d (and vc4-kms-v3d) both switch all window composition from being framebuffer based to using OpenGL. For most things this is more efficient than having to bash things through on the CPU, but it depends on exactly the operations you're using.

Is xorg using large amounts of CPU without this app running? It shouldn't.
What is this application doing in terms of on-screen drawing, and using what API calls? It may be that some operation was either tied to the display frame rate under the framebuffer driver, or offloaded to some other thread/worker for a large proportion of the time, whereas that throttling doesn't apply under DRM/KMS.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
w4mmp
Posts: 82
Joined: Thu Mar 26, 2015 3:11 pm

Re: Xorg utilization

Wed Apr 21, 2021 2:51 pm

Hello and thank you for responding to my request for help.

Your response helped break a log jam in my thought processes. There three processes that display information on the screen. I found only one of the three is causing the problem. Now I need to determine why it drives Xorg so busy particularly in light of the fact it does not access the HDMI display.

To answer your question, no Xorg is not busy when the application(s) are not running. Only when the above mentioned application is running does Xorg become successively busy.

Oh, I want to mention that if Raspberry offered a 5" DSI touch display, I would have highly considered using it in our product. The Raspberry 7" display is simply too large for our product.

If you a curious about the applications and want to know more, read on.
Below is a screen shot of the full application running on the DSI display.
mscc.png
mscc.png (75.54 KiB) Viewed 166 times
There are three independent applications driving the display. 1) MSCC (Multus SDR Control Console), 2) spectrum display, 3) waterfall display.
All three run under the service of Mono. Yea, I know, a bad choice but I'm stuck with it for now and after working around the bugs in Mono, the applications work. One day MicroSoft may offer a .Net 5.x desktop for Linux but for now the .Net 5.x desktop runs only in Windows.

As mentioned at the top of this reply, it is the spectrum display that is causing the heart burn. This application use a graphing library called ZedGraph. To find out how ZedGraph is accessing the display, I will need to dig down deep into the source code. I might be better off simply re-writing the spectrum display application using direct calls to GDI+ as the waterfall application does. The waterfall application runs well and does not cause the issue. Or scrap Mono for the spectrum application use QT (but I loathe C++).

Regards,
Ron
73,
Ron / W4MMP

User avatar
w4mmp
Posts: 82
Joined: Thu Mar 26, 2015 3:11 pm

Re: Xorg utilization

Wed Apr 21, 2021 2:56 pm

I should have mentioned the applications are developed with MS Visual Studio and Winforms. Yep, old technology but developing this application started some years ago and was intended for Windows. We are moving to the RPi 4B for the host computer and at the time Mono seemed a good path to follow. But that is one of the dangers of using open source applications. Support dies.
73,
Ron / W4MMP

fruitoftheloom
Posts: 26555
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: Xorg utilization

Wed Apr 21, 2021 3:05 pm

w4mmp wrote:
Wed Apr 21, 2021 2:56 pm
I should have mentioned the applications are developed with MS Visual Studio and Winforms. Yep, old technology but developing this application started some years ago and was intended for Windows. We are moving to the RPi 4B for the host computer and at the time Mono seemed a good path to follow. But that is one of the dangers of using open source applications. Support dies.

Osoyoo offer a 5" DSi Screen

https://osoyoo.com/2019/09/20/instructi ... ch-screen/


Visual Studio Code is now offered by Microsoft for Raspberry Pi SBC / CM
The information is out there....you just have to let it in.

My other Linux machines: ChromeBox
https://www.aliexpress.com/item/32966393971.html
& Stone Desktop Intel CoreDuo circa 2010

User avatar
w4mmp
Posts: 82
Joined: Thu Mar 26, 2015 3:11 pm

Re: Xorg utilization

Wed Apr 21, 2021 3:27 pm

Hi,
Thanks for the info on the display. I will take a look.

On the Visual Studio desktop issue, nope the desktop is not available for running Winforms on Linux:
From the https://dotnet.microsoft.com/download/dotnet/5.0 page:
net-desktop.png
net-desktop.png (10.95 KiB) Viewed 132 times
73,
Ron / W4MMP

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11056
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Xorg utilization

Wed Apr 21, 2021 3:37 pm

w4mmp wrote:
Wed Apr 21, 2021 2:51 pm
As mentioned at the top of this reply, it is the spectrum display that is causing the heart burn. This application use a graphing library called ZedGraph. To find out how ZedGraph is accessing the display, I will need to dig down deep into the source code. I might be better off simply re-writing the spectrum display application using direct calls to GDI+ as the waterfall application does. The waterfall application runs well and does not cause the issue. Or scrap Mono for the spectrum application use QT (but I loathe C++).
Total shot in the dark, but if it is drawing on textures and flushing lots, then under simple X it would just write a few pixels to the framebuffer. With GL composition it'll trigger a redraw of the texture.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
w4mmp
Posts: 82
Joined: Thu Mar 26, 2015 3:11 pm

Re: Xorg utilization

Wed Apr 21, 2021 4:09 pm

6by9 wrote:
Wed Apr 21, 2021 3:37 pm
w4mmp wrote:
Wed Apr 21, 2021 2:51 pm
As mentioned at the top of this reply, it is the spectrum display that is causing the heart burn. This application use a graphing library called ZedGraph. To find out how ZedGraph is accessing the display, I will need to dig down deep into the source code. I might be better off simply re-writing the spectrum display application using direct calls to GDI+ as the waterfall application does. The waterfall application runs well and does not cause the issue. Or scrap Mono for the spectrum application use QT (but I loathe C++).
Total shot in the dark, but if it is drawing on textures and flushing lots, then under simple X it would just write a few pixels to the framebuffer. With GL composition it'll trigger a redraw of the texture.
Thanks for you insights. I will be first to admit that I'm not really up on the low level stuff. I assume that a redraw of the texture is not a good thing.
73,
Ron / W4MMP

Return to “Raspberry Pi OS”