After a re-installation from scratch problem disappear, g-r-d is working.
Seems that apt install task-gnome-desktop don't do the complete job.
Le 11/07/2025 à 17:56, Simon McVittie a écrit :
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
