Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpi black screen in all windows. #3288

Closed
GWHAYWOOD opened this issue Sep 28, 2021 · 5 comments
Closed

rpi black screen in all windows. #3288

GWHAYWOOD opened this issue Sep 28, 2021 · 5 comments
Labels
bug Something isn't working display

Comments

@GWHAYWOOD
Copy link

GWHAYWOOD commented Sep 28, 2021

xpra version 4.3-r867 on the server, which is an Intel i7 laptop.
xpra version 4.3-r29977 (g8a0d2b663) on the client which is a Raspberry Pi 3B+.

I log in via ssh from the client to the server, where there is no window manager running and no other user session running.

I type

$ xpra start :103
$ DISPLAY=:103 xterm

to start a bash shell in an xterm on the server using xpra as the window manager.

On the client from which I log in to the server (on the client there IS a window manager running - fluxbox) I type

xpra attach ssh://laptop3/103

which after a little time opens a window on the client with a completely black display although the window ornamentation is as expected. I can use this window to type commands, but there is no visible indication on the black screen of any response. The commands are however executed on the server, for example I can 'touch' a non-existent file to create it in the user's home directory on the server.

The results are exactly the same if I use --opengl=yes or --opengl=no.

The bug-report data included a screenshot which I have removed. It was an image of the "file manager" display of the user's home directory. It contained sensitive information and nothing which could possibly be of use in diagnosing this issue. I have attached a tarball of the directory excluding the screenshot. That is the only redaction, but it was not clear to me that the bug-report process completed successfully. I used the 'save' button to create the directory of report contents but then had to kill the bug-report process as there seemed to be no obvious way to complete it.

The attached server log file is for three attempts to connect from the client:

xpra attach ssh://laptop3/103
xpra --opengl=yes  attach ssh://laptop3/103
xpra --opengl=no attach ssh://laptop3/103

XPRA_bug_report_data.tar.gz
xpra.log

@totaam
Copy link
Collaborator

totaam commented Sep 29, 2021

Original mailing list thread: https://xpra.org/list/2021-September/002876.html

xpra start :103
DISPLAY=:103 xterm

FYI: always use xpra start --start=xterm instead.

There is no mention of /run/user/$UID/xpra anywhere, which is strange.
It does write to /tmp/xpra/ instead. I guess this server was started from an ssh session?

Other information gleaned from the bug report data and log file.

  • server is xpra X11 seamless version 4.3-r867 64-bit running with pid 21107 on Linux Debian 10 buster
  • client is Python/GTK3 Linux Raspbian 11 bullseye tty client version 4.3-r29977 - odd, what does tty mean here?
  • the only encoders supported are the builtin (rgb and scroll) and the pillow ones (png* and jpeg)

How was this installed? From source?

The bug-report data included a screenshot which I have removed

You can just tell the tool not to take the screenshot. Though it is extremely useful, especially when the bug is a visual one.
A better way would be to move your sensitive applications out of the way before taking the screenshot.

Please try starting and attaching to a local session on the server and on the client separately:
xpra start --start=xterm --attach=yes
To see if the problem still occurs.
Or you could also try connecting with a different client (ie: MS Windows) or install xpra-html5 and use a browser.
Then also try turning off transparency support, both on the server and on the client:

XPRA_ALPHA=0 xpra start ...

You could also try forcing encodings: --encodings=png.

@totaam totaam changed the title First time install of xpra: black screen in all windows. rpi black screen in all windows. Sep 29, 2021
@totaam totaam added bug Something isn't working display labels Sep 29, 2021
@GWHAYWOOD
Copy link
Author

GWHAYWOOD commented Sep 29, 2021 via email

@totaam
Copy link
Collaborator

totaam commented Sep 29, 2021

There is no mention of /run/user/$UID/xpra anywhere, which is strange.

It is mentioned, but on stdout:

Right, that's on Debian.
It's not ideal to run without a valid $XDG_RUNTIME_DIR but it should still work.

'cal' says that it is not highlighted if the terminal is not a tty

This is unlikely to be related, but who knows.

At this point I should make clear that I don't know what encoders are...

Some related information can be found here:
https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Encodings.md

As I explained in my OP, this works fine on the server but gives the same symptoms on the client.

OK, so definitely something weird happening with the client then.
I was hoping that running both server and client on that system would resolve things. Either because the client and server can enable mmap when running locally, or because the (potentially weird) pixel format order wouldn't matter.

XPRA_ALPHA=0 xpra start ...
When I use this option, no xterm appears at all.

Damn.

As I said I will report on xpra-html5, although I should be most reluctant to use a browser for this purpose routinely.

I am not suggesting that you should use the browser routinely, only for diagnostics.
This should give us an interesting data point.

I have located my rpi, now I need to put an OS on it and wire it up somewhere.

@GWHAYWOOD
Copy link
Author

GWHAYWOOD commented Sep 30, 2021 via email

@totaam
Copy link
Collaborator

totaam commented Oct 1, 2021

Here is the full log of what I did:

  • downloaded 2021-05-07-raspios-buster-armhf-full.zip and extracted it to an sd card
  • booted this OS on:
$ cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.1
  • changed password, logged in via ssh, then apt-get install lots of packages as per https://github.com/Xpra-org/xpra/blob/master/docs/Build/Debian.md
  • git clone https://github.com/Xpra-org/xpra
  • cd xpra;python3 ./setup.py build;sudo python3 ./setup.py install --prefix=/usr
  • PYTHONPATH=/usr/lib/python3.7/site-packages/ xpra start --start=xterm --no-daemon
  • from an xterm on the default X11 desktop: PYTHONPATH=/usr/lib/python3.7/site-packages/ xpra attach

The xterm appeared after a few seconds and worked fine.
I also tried connecting to remote hosts via tcp, also without problems.

For good measure, I then dusted off an older rpi, downloaded an older version of raspios since newer versions fail to boot on it.

$ cat /sys/firmware/devicetree/base/model
Raspberry Pi Model B Rev 2

That took many many hours longer.
And also required to git checkout v3.1.x before building because the Python3 version in Debian Stretch (3.5.x) is just too old for newer versions of xpra.
With this one, I do get the black window bug. There is one obvious warning sticking out every time there's a missing screen update: Couldn't find foreign struct converter for 'cairo.Context'.
Easily fixed by installing the cairo bindings: sudo apt-get install python3-gi-cairo.
This dependency is usually installed automatically when installing packages:

,python3-cairo
,python3-gi-cairo

I'll update the build instructions to include this package as part of the build preparation (even though it's not actually needed for building..)

See also #3291.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working display
Projects
None yet
Development

No branches or pull requests

2 participants