Thanks Mike, but what could be the cause of the high CPU usage? Is it QXcbConnection: XCB error: 1 (BadRequest)?

On Sat, Sep 26, 2020, 10:43 AM Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi,

Am Dienstag, 22. September 2020 schrieb Robert Kudyba:
> Not sure if this is the best place to report this. Is this a X2Go issue, or
> a Gazebo issue with the Fedora package, or just a straight up Gazebo issue?
>
> Gazebo, gzclient, pins the CPU. We don't see this when using ssh -X, e.g.,
> from a Mac with XQuartz, nor Windows with MobaXterm.

What the Gazebo Client devs could.do is: fall back to Xinput1 if Xinput2 is unavailable.

> 5.7.15-200.fc32.x86_64, gazebo-11.1.0-2.fc32.x86_64
>
> top - 09:31:06 up 33 days, 17:28,  4 users,  load average: 2.15, 0.74, 0.44
> Tasks: 806 total,   3 running, 803 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 17.6 us,  0.4 sy,  0.0 ni, 81.7 id,  0.0 wa,  0.1 hi,  0.1 si,
>  0.0 st
> MiB Mem : 128537.7 total,  58096.7 free,  11477.8 used,  58963.1 buff/cache
> MiB Swap:  15260.0 total,  15178.2 free,     81.8 used. 115554.7 avail Mem
>
>     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
> COMMAND
>  523200 me 20   0   14.0g 343892 146472 R 826.2   0.3   2:40.46 gzclient
>  523199 me 20   0   12.0g 200884 117124 S   7.6   0.2   0:03.21 gzserver
>  521547 me 20   0  202364  94772  25548 S   4.3   0.1   0:03.45 x2goagent
>
> We see this in /var/log/messages:
> Sep 22 09:30:11 us dbus-broker-launch[522115]: Activation request for
> 'org.a11y.atspi.Registry' failed.

This one can be ignored, it is not fatal.

> And from launching with verbose option:
> [Wrn] [GuiIface.cc:119] X server does not support XInput 2

This one is the problem.

> [Wrn] [GuiIface.cc:119] QXcbConnection: XCB error: 1 (BadRequest),
> sequence: 168, resource id: 158, major code: 130 (Unknown), minor code: 47

... and the XClient gzclient dies...

Mike

--
Sent from my Fairphone powered by SailfishOS