-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add ZeDMD WiFi support #49
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The libzedmd version needs to be raised to a7c9ba92d1ca3418ff3d93b2f99a62f60e99d672 in the externals scripts.
dmdserver.ini
Outdated
@@ -16,7 +16,7 @@ PUPVideosPath = | |||
PUPExactColorMatch = 1 | |||
|
|||
[ZeDMD] | |||
# Set to 1 if ZeDMD is attached. | |||
# Set to 1 if ZeDMD or ZeDMD WiFI is attached. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In DMDext we treat ZeDMD and ZeDMD WiFi as different devices. For example, ZeDMDWiFi doesn't support setting brightness or RGB order over the WiFi stream.
And it would be nice to have the possibility to attach two devices, one via USB within the cab and a second via WiFi at the wall ;-)
But maybe we can do the split in a second step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we only need to modify findDisplays to get simultaneous functionality working. My question is: how should we handle failures? If I have both a ZeDMD Serial and a ZeDMD Wifi configured in the dmdserver.ini, should the thread stop if it fails to find one of them, or should it continue with whichever one is available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In DMDext we treat ZeDMD and ZeDMD WiFi as different devices. For example, ZeDMDWiFi doesn't support setting brightness or RGB order over the WiFi stream.
And it would be nice to have the possibility to attach two devices, one via USB within the cab and a second via WiFi at the wall ;-)
But maybe we can do the split in a second step.
See the latest commit; i have changed it to working with 2 at the same time and seperated the config stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, I've set up error handling so that the system will continue if it finds at least one of the two configured displays. Let me know what you think is the best approach for handling this.
Make sure we do a squash merge on this when ready as well! |
Fixed |
…or now it will continue to run if it finds at least 1 enabled device.
I have updated the code so the ZeDMD-WiFi has it's own config and can work at the same time with Serial. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bartdesign @jsm174
I think we should merge this as soon as the the network address is changed to 127.0.0.1.
The PR introduces a new ZeDMD-WiFi section in the config file, which is good and the base to support both variations in parallel.
Then @bartdesign has a working version and we can continue to split the ZeDMD threads in a new PR.
@@ -34,6 +34,14 @@ Brightness = -1 | |||
# Set to 1 to permantenly store the overwritten settings above in ZeDMD internally. | |||
SaveSettings = 0 | |||
|
|||
[ZeDMD-WiFi] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to put all the load on @bartdesign.
But we should discuss things here.
I think having a separate device here is the right choice as you also have to decide which firmware to flash on ZeDMD, WiFi or USB. (WiFi has minimal USB support to support the settings features.)
But the code later on here doesn't support two devices at the same time.
We need to treat ZeDMD and ZeDMD WiFi like ZeDMD and Pixelcade as two different things.
That means that we have two threads if both are enabled, a ZeDMD thread and a ZeDMD WiFi thread. For sure we can re-use the entire threading code.
} | ||
} | ||
|
||
if (openSerial || openWiFi) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
openSerial should start m_pZeDMDThread,
openWiFi should start m_pZeDMDWiFiThread.
We also need two pointers, pZeDMD and pZeDMDWiFi
dmdserver.ini
Outdated
@@ -1,7 +1,7 @@ | |||
|
|||
[DMDServer] | |||
# The address (interface) to listen for TCP connections. | |||
Addr = localhost | |||
Addr = 0.0.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @jsm174 that 127.0.0.1 is the better and safer default.
I understand that the usage should be as easy as possible.
But you don't sell a car without a handbrake just because people might to forget to release it before driving.
The default usage for dmdserver is to run on the same machine as the clients like VPX or batocera. In your new handheld device, dmdserver will also run on the same device or you would use libdmdutil directly (embedded in VPX).
Added ZeDMD Wifi support, updated dmdserver.ini and README.md with the new wifi options.