Run on Linux/Mono

[Rost3]

Can I run LaserGRBL on Linux? Raspberry Pi 3. my computer is too powerful (i7 ram 16GB) to use it in workshop. or better to buy a cheap old computer for it.

[arkypita]

All the code of LaserGRBL is C# so I think it could be compiled for Linux in Mono, using MonoDevelop.
I have never done it before, and I have no linux machine at the moment, so I can't help you with this task. If you have skill you can tray yourself. In case, let me know if works

[Jakeler]

It compiles fine on Arch Linux (xbuild) with latest mono 5.0.0. But when trying to run with mono LaserGRBL.exe i always get:

Unhandled Exception:
System.TypeInitializationException: The type initializer for 'Tools.TimingBase' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Tools.HiResTimer' threw an exception. ---> System.EntryPointNotFoundException: QueryPerformanceFrequency
  at (wrapper managed-to-native) Tools.HiResTimer:QueryPerformanceFrequency (long&)
  at Tools.HiResTimer..cctor () [0x00025] in <4bb2d302ea56443d9efd6d6ed57ceec3>:0 
   --- End of inner exception stack trace ---
  at Tools.TimingBase..cctor () [0x00000] in <4bb2d302ea56443d9efd6d6ed57ceec3>:0 
   --- End of inner exception stack trace ---
  at LaserGRBL.Program.Main (System.String[] args) [0x00000] in <4bb2d302ea56443d9efd6d6ed57ceec3>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'Tools.TimingBase' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Tools.HiResTimer' threw an exception. ---> System.EntryPointNotFoundException: QueryPerformanceFrequency
  at (wrapper managed-to-native) Tools.HiResTimer:QueryPerformanceFrequency (long&)
  at Tools.HiResTimer..cctor () [0x00025] in <4bb2d302ea56443d9efd6d6ed57ceec3>:0 
   --- End of inner exception stack trace ---
  at Tools.TimingBase..cctor () [0x00000] in <4bb2d302ea56443d9efd6d6ed57ceec3>:0 
   --- End of inner exception stack trace ---
  at LaserGRBL.Program.Main (System.String[] args) [0x00000] in <4bb2d302ea56443d9efd6d6ed57ceec3>:0

Can this be solved?

[arkypita]

Hi Jackeler, I am happy that someone is trying to port LaserGRBL in linux.

TimingBase is a class for precise and hi-resolution timing. It is based on
QueryPerformanceFrequency and QueryPerformanceCounter windows API and I suppose that those API are OS specific function and they are not available on mono. Fortunately it is not too difficult to replace them with something similar.

You can try to replace the whole HiResTimer class with this code:

	public static class HiResTimer
	{
		private const long NANO_IN_MILLI = 1000 * 1000;
		private static Stopwatch watch = new Stopwatch(); 

		static HiResTimer() //costruttore static, viene chiamato prima del primo utilizzo della classe
		{watch.Start();}

		public static long TotalMilliseconds
		{ get { return TotalNano / NANO_IN_MILLI; } }

		public static long TotalNano
		{
			get
			{
				return (long)((double)watch.ElapsedTicks / (double)Stopwatch.Frequency * 1000000000.0);
			}
		}

	}

[Jakeler]

Thank you for the fast reply. That works!

Then i got this:

System.DllNotFoundException: ntdll.dll
  at (wrapper managed-to-native) Tools.TaskScheduler:NtSetTimerResolution (uint,bool,uint&)
  at Tools.TaskScheduler.SetClockResolution (System.Int32 msec) [0x0000d] in <a1ec3de5fed24c81a1d181c135352908>:0 
  at LaserGRBL.Program.Main (System.String[] args) [0x00051] in <a1ec3de5fed24c81a1d181c135352908>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: ntdll.dll
  at (wrapper managed-to-native) Tools.TaskScheduler:NtSetTimerResolution (uint,bool,uint&)
  at Tools.TaskScheduler.SetClockResolution (System.Int32 msec) [0x0000d] in <a1ec3de5fed24c81a1d181c135352908>:0 
  at LaserGRBL.Program.Main (System.String[] args) [0x00051] in <a1ec3de5fed24c81a1d181c135352908>:0 

So i simply commented it out, like this:

public class TaskScheduler
	{

		//[System.Runtime.InteropServices.DllImport("ntdll.dll", EntryPoint = "NtSetTimerResolution")]
		private static extern void NtSetTimerResolution(uint DesiredResolution, bool SetResolution, ref uint CurrentResolution);

		public static void SetClockResolution(int msec) //volendo potrebbe gestire anche 0.5 msec ma a noi basta 1-15 msec, quindi usiamo int
		{
			uint DesiredResolution = (uint)msec * 10000;
			bool SetResolution = true;
			uint CurrentResolution = 0;
			//NtSetTimerResolution(DesiredResolution, SetResolution, ref CurrentResolution);
		}

	}

Does this break something?

Anyway, i can start it now without direct error/crash on Linux! One optical issue is that the menu bar has no font, but function seems okay. I will now test if the connection to my machine works! :)

[arkypita]

SetTimerResolution change the frequency of task- switching that in windows is about 66Hz (15 mSec) to a higher frequency that made LaserGRBL more responsive and fast in streaming g-code to arduino.

It's ok to comment it out

[Jakeler]

Okay good, that makes sense.

Test results:

• Connection to GRBL 1.1 controller: works!
• Loading gcode file and sending to controller: works!
• "Type gcode here" field: fail/crash at any input:

System.NullReferenceException: Object reference not set to an instance of an object
  at LaserGRBL.UserControls.PlaceholderTextBox.waterMarkContainer_Paint (System.Object sender, System.Windows.Forms.PaintEventArgs e) [0x0000e] in <eb1043efb68f4c3593b70ed0451be259>:0 
  at System.Windows.Forms.Control.OnPaint (System.Windows.Forms.PaintEventArgs e) [0x00019] in <a98ec586cd3441aeb3d7919d9ad41ff2>:0 
  at System.Windows.Forms.Control.WmPaint (System.Windows.Forms.Message& m) [0x0007b] in <a98ec586cd3441aeb3d7919d9ad41ff2>:0 
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x001a4] in <a98ec586cd3441aeb3d7919d9ad41ff2>:0 
  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000] in <a98ec586cd3441aeb3d7919d9ad41ff2>:0 
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000] in <a98ec586cd3441aeb3d7919d9ad41ff2>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x0000b] in <a98ec586cd3441aeb3d7919d9ad41ff2>:0 
  at System.Windows.Forms.NativeWindow.WndProc (System.IntPtr hWnd, System.Windows.Forms.Msg msg, System.IntPtr wParam, System.IntPtr lParam) [0x00085] in <a98ec586cd3441aeb3d7919d9ad41ff2>:0 

• Machine control (move): works!
• Reset+Lock Button: works!
• Create custom button and send the gcode: works!

[arkypita]

Great job @Jakeler

Comment DrawWaterMark in PlaceholderTextBox class.

protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
//Draw the watermark even in design time
DrawWaterMark();
}

[Jakeler]

Had to comment it in ThisHasFocus() and ThisTextChanged() to avoid the error. It causes no problem in OnPaint() and Initialize(). I have the changes now in a fork: Jakeler@1cea400

So i was able to successfully engrave something with LaserGRBL now. More test results:

• Settings, gbrl config, hotkeys: works
• Loading a raster image (png): Does nothing, no new window, no error...
• Speed, Power override popup: extremely small (unusable)
• UI Screenshot:
  
• Color schemes: background change works, but fonts stay grey, not readable in dark/hacker option

[arkypita]

Hi @Jakeler
I am very happy with your progress & results with mono. When I do my first experiments with an older version of LaserGRBL I could not go much further. My biggest problems were that the version of mono I was using was very old (3.2.8) and suffers several bugs that prevent winform program to function properly. I had done these tests on a raspberry, because I do not have a real linux PC available.

With Arch Linux (xbuild) and mono 5.0.0 i hope you can achieve better result then me. However i remember the biggest issue was on Raster Import form. Not because of my vectorizing/line2line code, but because the WinForm layout I am using.

I see some issue that should be the same you have now. I.e. the misalignment of the connect button, of the stop-continue button etc. The whole interface of LaserGRBL is designed using "TableLayoutPanel" that allow me to make it working very well on different resolution, resizing, different space used in different string translation etc.

Maybe some form should be re-designed to use a simpler & fixed layout schema to work in mono.

[arkypita]

I should have an old laptop that I can sacrifice to a linux installation. I would be happy to help you with this job.

[Jakeler]

According to to Mono docs, support for Windows Forms 2.0 is complete, but it seems not the same like on Windows. I also noticed that resizing the window smaller does not move the stop-continue buttons back, causes them to disappear at some point. Overall, most elements look not quite right. I would also prefer a more modern style, instead of this Windows 2000 theme on Linux.

I have not really any experience with C# and Windows GUI stuff, so i am not sure if i can do this or help you a lot. Now looking at the code i started to understand it a bit, but still... In addition some code is commented in Italian, which i don't understand.
I can help you though with setting up Linux for development, testing and other related questions. When the software is working i could do proper packaging for Linux distributions, so that everone can install and update it easily.

You don't neccessarily need addidtional hardware, if you have a half decent PC you can run it just as virtual machine guest with VirtualBox. So you leave your Windows Host running and can quickly start another OS virtual. (I do this often the other way around, with Windows as guest on my Linux PC, especially for development very useful)

[arkypita]

I am able to install linux both on physical or virtual machine, this is not a problem for me. The only problem is to find time :-)

In any case, I take advantage of your availability to obtain some information that can speed up this step.

• What distro exactly you use? Could you provide me a link to an installable ISO?
• Is the mono compiler or IDE already present in distro or you have to install later? What step to install?

More: when I do my old try i remember that I cannot graphical edit my winform UI directly from monodevelop, because they only support editing GTK Form. Is the situation still the same? I mean, are you able to open a form, like mainform, and edit it graphically from monodevelop or not?

[arkypita]

Update; i have installed Linux Mint with mono v5.4.16 and monodevelop 7.1. Both are the latest version.
I am stuck on a problem with resgen.exe as you can see in picture. Any hint?

With xbuild it compile

[arkypita]

Update: solved (switching to .net 4.5)

[Jakeler]

Awesome to see that you are on it! I had not much time today to answer, anyway everything is solved now? Let me know how it goes and if you need help with something. ;)

[oliverhbailey]

The members in this thread have really gone the distance in getting LaserGRBL to work on Debian. I worked on the original NT project back in the early 1990's. As an operating system developer for almost 50 years, I still develop real time systems for several industries, using Linux almost exclusively these days.
Latency can be caused by several factors. LaserGRBL is a 32 bit windows application. Under Wine, the Dll's have access to half as much memory than under a Windows environment. A 32 bit application normally has access to 4 gigs of RAM. But under Wine 32, only the lower 2 gigabytes is actually available. There are other factors as well, type of machine, type of processor, speed, cores, and total ram, that also have an impact on performance of a Windows app.
The best solution is to move LaserGRBL to 64 bit Wine and mono. That eliminates memory and CPU restrictions of Wine 32 and should done anyway as 32 bit Windows support is deprecated. I'm retired and ported LaserGRBL to 64 bit Mono swveral yrars ago successfully. But in the past two years Microsoft has stopped promising cross platform support for Winforms on Linux only. And at that time and continuing to the present, there are build errors that remain unresolved on Linux relating to Winform 32 bit only applications.
There are ways to bump up the application process priority but this can cause other performance issues. If the latency is in the UI, its most likely memory starved. However, if it is in data buffering to the laser, you could increase the buffer size to keep data flowing smoothly. Just don't increase the buffer until you have other performance problems.
Wine is useful, but trying to solve Windows shortcomings is getting to be a bigger burden. Memory sensistivity is even caused by the order of Dll loading these days on 32 bit applications.
You've done a great job of getting LaserGRBL working. I hope this information can help.

[Styne13]

@Rybec: Thanks for describing installation using Playonlinux. I created a POL-Installation-Script to automate most of the steps including download of latest version and com port mapping in regedit.

@arkypita: Shall a create a PR to add it to the repo? What is the best path to put it in?

[Rybec]

Thank you so much! I was hoping someone could use my process to do this.

[Styne13]

I created a pull request with a setup script now:
#1666
Feel free to comment!

[arkypita]

Hi @Styne13
I see that there is something similar to PlayOnLinux but for MAC https://www.playonmac.com/en/
Do you think it is possible to do something similar to your script but for MAC?

[Styne13]

Hi @arkypita
think that shall also be possible. As far as I know the interface between wine and playonlinux and playonmac is identical. Executing installation scripts is also possible.

It might depend on the version 5.22 with mono available in macOS.
Gave it a quick try with my 1201n hackintosh running Yosemite was not successful, because I could not install the appropriate version 5.22 with mono.
Maybe someone else running a newer version of macOS can give it a try.
Can support as possible and also give it another try installing mono manually...

[rannxeru]

Thanks for providing us with this wonderful program, @arkypita .But now I am confused by a problem.
I am translating the "Strings.resx" into a new culture, Japanese, but the method provided in "TRANSLATING.md" can not include the file into "Strings.resx", the file "Strings.ja-jp.resx" is now shown in an independent position.How can I fix the problem?Thank you again.

[oliverhbailey]

Be very careful. My experience on a 5 GHZ 8 core systems with 64 GB of ram shows the GRBL stops frequently due to buffers filling up. The laser stays on the movement stops and it results in a destroyed piece of work. There are also display issues with the latest mono and wine.

…

On Sat, Dec 10, 2022, 5:10 AM Langlais115 ***@***.***> wrote: It works great on Ubuntu 22.04 I just got a *conflict* with *brltty*: Here was the log from my /var/log/syslog: ------------------------------ *Dec 10 11:15:42 user-ThinkPad-W520 brltty[10394]: USB configuration set error 16: Device or resource busy Dec 10 11:15:42 user-ThinkPad-W520 brltty[10394]: brltty: USB configuration set error 16: Device or resource busy Dec 10 11:15:42 user-ThinkPad-W520 kernel: [ 2242.930333] usb 3-2: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1 <#1> Dec 10 11:15:42 user-ThinkPad-W520 brltty[10394]: USB interface in use: 0 (ch341) Dec 10 11:15:42 user-ThinkPad-W520 kernel: [ 2242.937587] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0 Dec 10 11:15:42 user-ThinkPad-W520 kernel: [ 2242.937635] ch341 3-2:1.0: device disconnected Dec 10 11:15:42 user-ThinkPad-W520 brltty[10394]: brltty: USB interface in use: 0 (ch341)* ------------------------------ I just have to remove the package *brltty* which was creating a conflict. sudo apt remove brltty After that, everything works fine. — Reply to this email directly, view it on GitHub <#1764 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6CBIFJWWORB4CJ7EZD6Y3WMRQKDANCNFSM5QEE7V6Q> . You are receiving this because you commented.Message ID: ***@***.***>

[kevroy314]

The above tutorials were super helpful to me as a new wine user. I feel like I'm really close, but I got to the last steps (wine install.exe) and I consistently get:

0009:err:module:__wine_process_init L"E:\\home\\kevin\\LaserGRBL\\install.exe" not supported on this system

I've tried with sudo. I even tried xbuild to build it myself (though I imagine there are settings I'd need to change that I'm not aware of for my platform). I also tried running the install on a local machine, zipping the result, and running wine LaserGRBL.exe on the destination system after unzipping. Always the same error message.

I'm running on Linux raspberrypi 5.15.76-v7l+ #1597 SMP Fri Nov 4 12:14:58 GMT 2022 armv7l GNU/Linux .

Anyone know what might be going wrong? I'm guessing it's that the install.exe wasn't compiled to work with armv7l, but I'm not sure how to work around that.

[Rybec]

It's almost certainly related to the architecture. Wine can't make a program compiled for Intel run on ARM.

If you can get it to compile on the Pi though, you should get an ARM executable. You probably won't be able to compile for Linux though, since LaserGRBL has a lot of Windows specific stuff going on . I've only ever tried to compile one thing designed for Intel on ARM, and that was the Android native C build tools, which failed horribly to compile (despite being designed for Linux).

My suggestion would be to try to compile on the Pi, and when that fails, open an issue to ask about/work through things. I'm not sure I can be much help in that, but others here might be able to. There are two things I can tell you that might help though: You will probably need the Mono dev package for the .NET stuff, and you will probably also need a Windows cross compiler to compile it (you'll still have to run it in Wine). I'm not 100% sure that second one exists for ARM, but I think it should, given that MS has an ARM Windows port. Just make sure the cross compiler has support for generating ARM executables.

If you do manage to pull it off, it would also be cool if you posted here how you did it! Raspberry Pis make awesome controller interfaces for things like this, and LaserGRBL on a Pi would be really nice.

[kevroy314]

Thanks so much for the thoughtful reply! I'll give compiling a go. I'm familiar with c# development, just new to mono dev (outside of game dev). The other direction I was considering is getting full blown windows on the pi, but I've got the 1gb version so I doubt that'll fly. There's also a LinuxCNC alternative I may consider. Appreciate the leads! I'll definitely update if I figure anything useful out.

…

On Thu, Jan 5, 2023, 7:21 PM Ben Williams ***@***.***> wrote: It's almost certainly related to the architecture. Wine can't make a program compiled for Intel run on ARM. If you can get it to compile on the Pi though, you *should* get an ARM executable. You probably won't be able to compile for *Linux* though, since LaserGRBL has a lot of Windows specific stuff going on . I've only ever tried to compile one thing designed for Intel on ARM, and that was the Android native C build tools, which failed horribly to compile (despite being designed for Linux). My suggestion would be to try to compile on the Pi, and when that fails, open an issue to ask about/work through things. I'm not sure I can be much help in that, but others here might be able to. There are two things I can tell you that might help though: You will probably need the Mono dev package for the .NET stuff, and you will probably also need a Windows cross compiler to compile it (you'll still have to run it in Wine). I'm not 100% sure that second one exists for ARM, but I *think* it should, given that MS has an ARM Windows port. Just make sure the cross compiler has support for generating ARM executables. If you do manage to pull it off, it would also be cool if you posted here how you did it! Raspberry Pis make awesome controller interfaces for things like this, and LaserGRBL on a Pi would be really nice. — Reply to this email directly, view it on GitHub <#1764 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJQN4TH4AUILW6QOLMHZTWQ5XSVANCNFSM5QEE7V6Q> . You are receiving this because you commented.Message ID: ***@***.***>

[Rybec]

No problem, and good luck!

If you don't have any luck with LaserGRBL, another option is LaserWeb. LaserGRBL + Wine doesn't play nice with my window manager under Linux, sometimes resulting in hangs when I switch between virtual desktops. I honestly prefer LaserGBRL, as it is simpler and just easier to use. LaserWeb is pretty advanced and has a steep learning curve with poor documentation (and can be a pain to get setup initially). It can do some pretty cool stuff (like if you want to cut and engrave in the same run), but it's kind of a pain. It does work though. (I haven't tried it with Raspberry Pi... According to the website, the server for LaserWeb will run on Raspberry Pi but the frontend won't. So you would have to access it from its web interface through a browser. I personally prefer that anyway, but it's a limitation to keep in mind. Obviously this means LaserGRBL would be more straightforward to use on the Pi as well, if you can get it working.)

For most things though, I really do prefer LaserGRBL. One of the things I really dislike about LaserWeb is that it doesn't display where the laser is when cutting (I don't think it even tries to read real-time status information on GRBL machines...). It might seem like a small thing, but in practice, it's a bigger deal than it sounds like it should be.

[oliverhbailey]

First of all Wine doen't emulate Linux calls, it translates the windows calls to linux gui calls. Second, the raspberry pi graphics driver changed last year, so wine is not going to work unless unless you use the testing branch of wine, which may not habe been fully portrd any way. But, laser GRBL has other issues with wine relating to buffers that cause bigger problems. The display of images does not translate properly and the memory management does work either. Sadly laserGRBL is in desperate need of a rewrite and it is not going to be an easy task. It needs to be rewritten to be cross platform and it is doubtful the current authors are going to put time into the effort because they aren't experienced enough to do it. And given that Windows 11 is the last version of Windows, it isn't likely anyone eould do much given how much .NET internals have and continue to change. Find another product thst is fesigned to run on Linux.

[kevroy314]

Update for anyone who is curious. Given the price of raspberry pi 4 these days, I gave up on getting it to work there and bought a 99 dollar mini pc with windows pre installed. Installed VNC on it, added a camera to watch the laser, and installed windows lasergrbl on it. Same price as the other solution I had in mind but only took 30 min to get all set up. 10/10 would recommend.

…

On Thu, Jan 5, 2023, 9:58 PM Ben Williams ***@***.***> wrote: No problem, and good luck! If you don't have any luck with LaserGRBL, another option is LaserWeb. LaserGRBL + Wine doesn't play nice with my window manager under Linux, sometimes resulting in hangs when I switch between virtual desktops. I honestly prefer LaserGBRL, as it is simpler and just easier to use. LaserWeb is pretty advanced and has a steep learning curve with poor documentation (and can be a pain to get setup initially). It can do some pretty cool stuff (like if you want to cut and engrave in the same run), but it's kind of a pain. It does work though. (I haven't tried it with Raspberry Pi... According to the website, the server for LaserWeb will run on Raspberry Pi but the frontend won't. So you would have to access it from its web interface through a browser. I personally prefer that anyway, but it's a limitation to keep in mind. Obviously this means LaserGRBL would be more straightforward to use on the Pi as well, if you can get it working.) For most things though, I really do prefer LaserGRBL. One of the things I *really* dislike about LaserWeb is that it doesn't display where the laser is when cutting (I don't think it even tries to read real-time status information on GRBL machines...). It might seem like a small thing, but in practice, it's a bigger deal than it sounds like it should be. — Reply to this email directly, view it on GitHub <#1764 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJQNYNPW2UGZRBOIUY4NLWQ6J5VANCNFSM5QEE7V6Q> . You are receiving this because you commented.Message ID: ***@***.***>

[hovercraft-github]

Just for fun I decided to port this nice application to the mono runtime,
and after few form redesign & other adjustments
it works on Raspberry Pi 4 and Orange Pi as native executable !
Windows compatibility still present.
For someone interested look for binaries in my fork, branch linux-port.

[hovercraft-github]

In theory, we can integrate these adjustments into the main-stream project in the future,
but you should decide how deep it can suffer )
If you agree, I can think about preparing a PR.

[oliverhbailey]

Be very careful on integrating into mainline code. Mono is something that has had great success with applications for desktop use. It has not had great success with applicatiions that need hardware access for communications access over the long term. The common language runtime CLR, is the bytecode conversion library, this is not a native code executable. It can break at any time and leave users hanging. You need to also consider that Raspberry Pi OS is a Debian derivitive and has changes based on the Broadcom ARM chip that are closed source. It some cases mono works and in many cases it will break and remain broken. I would have a seperate raspberry pi fork for this reason.

[hovercraft-github]

@oliverhbailey Well, I rather agree with your statement that CLR, been not a native code, "can break at any time and leave users hanging" ), but..
In no event the suggested changes will bind this application to a mono platform anyhow -not at run time nor at compile time.
All these are in fact relatively small code style adjustments intended for better compatibility. It has nothing to do with mono runtime, with Raspbian, Linux and any hardware.
The resulting assembly will run on any compatible CLR, in particular directly on .NET Platform in Windows, and can be built there of course, as before.
So, I think your fears are mostly unfounded here )

[oliverhbailey]

Well, LaserGRBL 5.7.0 ran successfully on the Raspberry Pi 4 & 5. After an autoupdate to 7.12, it no longer runs on the Pi 5. Both raspberry pi 4 & % have current Raspberry Pi OS updates. Of course this was running on Wine, not Mono. Just thought you should know.

Good Luck!

[hovercraft-github]

@oliverhbailey Thanks for the report about wine/RPi, and I'm not surprised !
In contrast, the proposed solution with mono I expect should be more stable just because we will have more control of what's under hood.

[oliverhbailey]

It does successfully update on the Pi 4. It updates on the 5 but no longer starts after the update. HAVE FUN!!

…

On Tue, Aug 20, 2024 at 12:24 PM hovercraft-github ***@***.***> wrote: @oliverhbailey <https://github.com/oliverhbailey> Thanks for the report about wine/RPi, and I'm not surprised ! In contrast, the proposed solution with mono I expect should be more stable just because we will have more control of what's under hood. — Reply to this email directly, view it on GitHub <#1764 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6CBIFYQ7GH7GGSBUCH6ADZSN3UBAVCNFSM5QEE7V62U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBTHE4DMNBV> . You are receiving this because you were mentioned.Message ID: ***@***.***>