Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2

[Simon McVittie]

Control: retitle -1 gnome-remote-desktop: blank screen after connecting to Mac Mini M2
Control: reassign -1 gnome-remote-desktop
Control: affects -1 + asahi-platform
Control: severity -1 normal

On Fri, 11 Jul 2025 at 16:22:49 +0200, Daniel wrote:
>Le 11/07/2025 à 16:11, Simon McVittie a écrit :
>>What I should have asked at the beginning is:
>>
>>Is there a user-visible symptom that you are reporting, like some 
>>program crashing or taking a long time to start, that is in some way 
>>related to the warning you have quoted?
>
>That's the logs I get when I try to connect to gnome-remote-desktop. 
>On the client I'm asked to enter user, password and domain, once done 
>I get a blank screen and those logs appear on the server.

OK, if the user-visible symptom is "I try to remote-control my computer 
with gnome-remote-desktop and the result is a blank screen", please 
start with that. Package maintainers cannot know that you are using 
gnome-remote-desktop unless you tell us!

Please try upgrading to the remote desktop server to 
gnome-remote-desktop 48.1-4 (currently in unstable but not in testing) 
which is known to fix a bad interaction with newer versions of Mesa, 
then reboot the remote desktop server and try connecting to it again.

If that is not successful, please describe the steps to reproduce the 
problem you are seeing, without assuming that the package maintainers 
know everything about your computer. You must have done some 
configuration to make your computer offer remote desktop access - 
please describe how you achieved that. The reason I ask for this is 
that there is more than one way to use gnome-remote-desktop.

Remote-controlling a GNOME system with gnome-remote-desktop is not the 
typical configuration: the typical configuration is to plug in a screen 
and keyboard, and use it locally. You also seem to be using 
gnome-remote-desktop in a less-common way where you are creating a 
"headless" UI session, rather than sharing an existing GUI session.

If you are reporting a bug and you want it to be solvable, please always 
start with:

- what you did (how you configured the system), and especially anything
   that you did that is unusual, like:
     - installing on Apple hardware using an unofficial version of Debian;
     - using gnome-remote-desktop rather than a locally connected screen
       and keyboard
- what you expected to happen
- what actually happened

The warning message logged by xdg-desktop-portal does not necessarily 
have anything to do with you seeing a blank screen. It is potentially 
useful information, but also potentially misleading, so we should start 
by getting the full facts.

So let's start again: if you had provided that information at the 
beginning, what would you have said?

Also please note that the "Bananas" port for Apple M1/M2 hardware is not 
an official part of Debian, and relies on components that are not part 
of Debian. I don't know how much of it is expected to work, and probably 
some of it is known not to be ready at the moment. If you are not 
already an experienced Debian user, I would recommend trying it on x86 
hardware (like an old laptop) first.

Because gnome-remote-desktop interacts with video rendering, it is 
dependent on the unofficial kernel and Mesa graphics stack provided by 
"Bananas", which is not part of Debian.

Other log messages that could be particularly relevant include:

> juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - [WTSReceiveChannelData]: unknown channelId 1006 ignored
...
> juil. 10 18:39:34 apple gnome-remote-de[16112]: [DaemonSystem] Aborting handover, removing remote client with remote id /org/gnome/RemoteDesktop/Client/972001666
> juil. 10 18:39:34 apple gnome-remote-desktop-daemon[16112]: [18:39:34:766] [16112:00003ef0] [ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_CB_CONNECTION_CANCELLED [0x00010409]

(note for cc'd maintainers: there is a more full log in a previous 
message on the bug)

     smcv