Screen patch questions

OWL Patches
#1

I noticed USE_SCREEN is gone now, so I checked and read about the new rules for screen-based patches:
https://community.rebeltech.org/t/writing-screen-patches
And I see MonochromePatch is in the docs and firmware now. Awesome!

But, I have some questions…

  • What happens when you run a MonochromePatch on a screenless device? Does it work?
  • Is there a way to tell, either at compile time or at run time, if a screen is going to be available? (For example maybe I would skip initing screen-related variables in the constructor if I knew I was on a device with no screen)

Also, a silly question: I notice a “ColourScreenPatch” class in the source and documentation… :smiley: If you happen to inherit from this, and run on a device with a monochrome screen or no screen, what happens?

#2

Yeah, the patch still works without display. The way the screen rendering is done is that there’s a callback function to be called from firmware periodically that renders a new frame. Without display your `::processScreen`` function just won’t get called. This also means that you can determine that the display is available by setting a flag when a new frame is rendered, but you can’t determine if there’s no display available or the very first frame hasn’t been rendered yet.

If you use color screen patch on monochrome display, you’ll get a buffer of mismatching format, since monochrome patches operate with 1 byte pixels, while color patches need 2 bytes to store 16 bits color (565 format). So you would just get a corrupt display image. For now there’s no color display hardware and there’s no official hardware with color display, but there’s something in the works (and I’ve ported OWL to run on something with ILI9341 too)

#5

Thanks for the help.
I do hope there will eventually be some way to write a single patch that can handle either a color or a monochrome screen, but if there’s no hardware yet there’s lots of time to figure that out.

I wrote a couple of long posts last night, but I think they are just confusing so I deleted them. I was seeing two unrelated failures with FirmwareSender and the Rebeltech web app, and posted here documenting the symptoms I saw, but I think it is more helpful if I make github issues. So I am will do that.

Anyway, I’m still having one small but real screen API problem: I made this very simple test patch. It has a processScreen() and at the end it runs:

    screen.clear();
    screen.print(x, y, num);

But, although I clear the screen, when this draws it still draws the line of vertical bars for parameters at the bottom. So I have my desired screen contents and then the bars at the bottom. I don’t remember that happening before. I see this both with my current code and with my old code based on OwlProgram 2918c483c53c, so it must be something in the v22.4.0 firmware itself (or it’s always been there). Is there a way to “actually clear” the screen? Or if the lines are being drawn on top after my patch runs, is there a way to get OpenWare to suppress the interface?

Thanks again.

#6

(Update: I filed github issues for the problems from my deleted posts from last night:

…it was a long night.)

#7

Those parameters are always rendered after main UI (drawBlocks method). And current behavior makes more sense by default for regular patches, so disabling this would have to be optional (either as global setting or as a settings triggered by patch and reset when new patch is loaded).

We did discuss with Martin adding screen savers to firmware before, so maybe it makes more sense to consider this feature instead.

#8

Understood, thanks.

The fact the patch is named “ScreenSaver” is sort of a joke, it is just a screen test… the reason I want to opt out of the normal overlay UI is situations more like

  1. I have written a patch that completely eschews the normal interface (it is controlled by external MIDI, or I have overloaded encoderChanged/buttonChanged)
  2. I am using the interface as normal, but I want to change the default display behavior (for example maybe instead of showing a bar when you turn the encoder, I want to show a number or a list of unique “options”/strings in that space)

A global “don’t overlay UI” flag, or more likely a member on PatchSource “don’t overlay default UI while I’m foregrounded”, would be fine for these purposes.

I also might file yet another github issue asking later at least for a function to get the “usable” screen area (ie the area not taken up by default UI), so my patch can be forward-compatible if the size of the UI overlay changes later.

#9

I doubt that this would be added to official firmware, but it’s not too hard to exchange data between firmware and patches. I can give some pointers if you want it badly enough to try adding something like this.

This sounds more useful, especially now that the second module with display is in production. And the solution would be similar to that flag.

An alternative solution is to change screen buffer size that firmware tells us to exclude bottom rows that are being drawn into by firmware itself. Or maybe we could return the reported height based on the flag that you’ve mentioned being set or not.