Mono Winforms Fullscreen on Raspberry Pi OS Bookworm

[JinShil]

Raspberry Pi OS Bookworm now uses Wayland and labwc instead of X11, so what I think used to work to display Mono Winforms application fullscreen doesn't seem to work anymore. Apps that used to display fullscreen in X11, now appear just below the the "TaskBar" instead of being display over the top of it. I tried playing with the Form's `Size`, `AlwaysOnTop`, `WindowState`, etc. but can't seem to get anything to work.

Other apps on the system like Chromium and VLC have no problem displaying fullscren over the TaskBar. I think the way an app registers itself as FullScreen in Wayland is different.

Q1: Can anyone provide a method to display an Mono app fullscreen in Wayland and labwc, on Raspberry Pi OS Bookworm?

Q2: Is this the right forum to reach those working on, or with expertise in, Mono? If not, what would be the preferred forum?

[madewokherd]

Maybe it'd make sense to add a Mono-specific forum?

Based on a quick search, it looks like Mono's winforms on X11 doesn't use the _NET_WM_STATE option to fullscreen windows. I think this is because there's no explicit "fullscreen" property in the System.Windows.Forms, so we would have to detect that an application wants fullscreen and set that property (Wine does something similar by looking for windows that try to fill the screen, which is how fullscreen works on Windows).

Based on that, I wouldn't expect this to work on X11 either. I'm guessing that if it did, that's because the window manager on X11 was taking care of it, and the Wayland configuration does not. The correct fix would be for winforms to use _NET_WM_STATE_FULLSCREEN

Do you have a good test case for this? Either an application you're trying to use, or code that works to fullscreen a window on Windows?

I see that stack overflow recommends this:
FormBorderStyle = FormBorderStyle.None;
WindowState = FormWindowState.Maximized;
but it'd be good to know how your application does it so I can make sure that case is handled.

If it's an application you develop, and you don't want to wait for a fix, you may be able to work around this by setting _NET_WM_STATE yourself through X11 libraries. Fullscreen state can also be toggled with the "xdotool" command, and some window managers allow binding keyboard shortcuts for fullscreen mode.

I should also mention that I've been finding major issues with Mono's JIT compiler on ARM architectures in my testing (mainly around floating point support), so there might be other problems on a Raspberry Pi until I can get those sorted out.

[JinShil]

Maybe it'd make sense to add a Mono-specific forum?

That seems logical to me, especially since the Mono Framework doesn't have a dependency on Wine.

Based on that, I wouldn't expect this to work on X11 either. I'm guessing that if it did, that's because the window manager on X11 was taking care of it, and the Wayland configuration does not. The correct fix would be for winforms to use _NET_WM_STATE_FULLSCREEN

Do you have a good test case for this? Either an application you're trying to use, or code that works to fullscreen a window on Windows?

I think you're right. On Raspberry Pi OS's Debian Buster release, using X11, the application appears fullscreen if you make the Window the same size as the screen, and also set the `TopMost` property to `true`. On Bookworm, using Wayland, the `TopMost` property doesn't seem to have the same effect. Instead of putting the Window on top of all others, it seems to dock it right below the panel (i.e. TaskBar). The difference in behavior between the two OSes may be due to the different panel applications or window managers, or perhaps even something else.

I see that stack overflow recommends this:
FormBorderStyle = FormBorderStyle.None;
WindowState = FormWindowState.Maximized;
but it'd be good to know how your application does it so I can make sure that case is handled.

Thinking through your prior comments, I think making any changes in Mono would actually be introducing a new feature rather than fixing an existing one. I think devising an algorithm that uses `FormBorderStyle`, `WindowState`, `Size`, and `TopMost` to "detect fullscreen" makes sense, and would certainly make my given task simpler, but I can't say one way or another that that would be the "right thing to do".

If it's an application you develop, and you don't want to wait for a fix, you may be able to work around this by setting _NET_WM_STATE yourself through X11 libraries.

I think I'll just PInvoke the X11 libraries for now. I tried the following, in a form, but it didn't work. Maybe `Handle` isn't the right window.

Code: Select all

IntPtr display = X11.XOpenDisplay(null);
if (display == IntPtr.Zero)
{
    Console.WriteLine("Unable to open display.");
    return;
}

try
{
    IntPtr wmState = X11.XInternAtom(display, "_NET_WM_STATE", false);
    IntPtr fullscreen = X11.XInternAtom(display, "_NET_WM_STATE_FULLSCREEN", false);

    IntPtr[] properties = { fullscreen };
    X11.XChangeProperty(
        display,
        Handle,
        wmState,
        (IntPtr)X11.XA_ATOM,
        32,
        X11.PropModeReplace,
        ref properties[0],
        properties.Length
    );

    X11.XFlush(display); 
}
finally
{
    X11.XCloseDisplay(display);
}

If you know what I'm doing wrong, please point it out. I think I'll get there eventually, but it seems I'm going to have to struggle with it for a while.

I should also mention that I've been finding major issues with Mono's JIT compiler on ARM architectures in my testing (mainly around floating point support), so there might be other problems on a Raspberry Pi until I can get those sorted out.

That's concerning. I've been wondering: Is it technically feasible to port the Mono Framework to .NET 8+ to avoid having to maintain the JIT compiler and all that other infrastructure. Short term it would be a lot of work, but as each infrastructure component is dropped in favor of official .NET, only the platform abstraction would need to be maintained. I know your goals are just to keep the Mono Framework maintained in its current state, but I'd very much like to hear your thoughts on whether or not it would be technically feasible.

[JinShil]

I was able create a simple workaround with...

Code: Select all

if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
{
    // Workaround for fullscreen on Raspberry Pi OS Bookworm with Wayland and LabWC
    LocationChanged += (s, e) => { Location = new Point(0, 0); };
}

On Raspberry Pi Bookworm OS with Wayland and LabWC, the window manager seems to relocate the window just below the desktop panel/taskbar. Adding the above event handler simply detects the change in location, and repositions it back to 0,0. That works for my purposes as I already have logic to make the Form the same size as the screen, FormBorderStyle = None, ControlBox = false, and TopMost = true.

[madewokherd]

If modern .NET runs, there is a separate port of just System.Windows.Forms that you may be able to use: https://github.com/DanielVanNoord/System.Windows.Forms

I've been working with them to keep Framework Mono synced up with it.

The trouble with modern .NET more generally is that they've given up compatibility with .NET Framework, which is a big part of what I'm trying to preserve (we kinda need it in Wine).

From a quick look at the X11 code, winforms windows have a "whole window" and "client window" on the X11 side. What you want is the "whole window". The handle returned via API is the "client window". The "whole window" is the parent of the "client window", so it should be possible to find the window you need using XQueryTree on to get the parent window of Form.Handle.

I think I'll try implementing fullscreen support based on form modes first and see where that gets us.