Is there an elegant way to register custom pixel mappers globally without hacking or modifying any internal code or C++ build params within rpi-rgb-led-matrix directly? I also don’t want to have to import and register the pixel mapper within each individual’s display program. I’d like it to be recognizable from the command-line flags. I have a mixture of Python and C++ written display programs and they live in a separate folders like this:
project_root
rpi-rgb-led-matrix(git)
src
pixel-mapper-custom.cc
views
py
weather
clock
cc
news
system-info
With this directory layout is it possible to register pixel-mapper-custom.cc without modifying the git repo rpi-rgb-led-matrix directly?
I see there is ApplyPixelMapperwhich seems to require initialization in each individual view program, and also RegisterPixelMapperfor global use - but I’m not sure where to use this second function when starting an individual Python or CC program from Bash. My code starts each individual display program directly from their own file. How in the build/init step can it be aware of how to find the pixel-mapper-custom.cc file and run RegisterPixelMapper?
I had some time to think this over while working on other stuff, but my strategy is probably going to be to make a common entry-point for all of the display programs, like a BaseView class. Then each of these views can inherit from that. That will include the pixel-mapper and register it providing a clean plug-and-play kind of system as I want to keep the core rpi-rgb-leg-matrix code unmodified out of a desire for perfection.
this sounds like the correct way to do things, so if you can build a nice PR, that would make things better for sure.
Please do have a look at this panel mapper that just landed though:
For pixel mappers within a panel, there is no plugin, they just get added one at a time.
I’m thinking those pixel mappers should be added to the code like they are now, because they are useful for everyone.
Mappers for layouts between panels are indeed more personal and one-off. If the one I just gave you is not good enough, having another plug in option would be good, or maybe you can further extend the one that just got added.
I see you merged the remap mapper a day or two ago. I’m going to test that and report back if it works well for me. Perhaps that can help serve as manual testing to confirm its behavior which I see was requested. Then I will discard my custom pixel mapper if that’s the case.
Hey @marcmerlin - just reporting back. I tested and used the remap pixel mapper that was just merged and it works very well. It was actually remarkably simple and intuitive to set up. I wrote the remap string in less than a minute and it was working as expected right away. On my first try it went upside down on me, but I flipped the value from west to east and that fixed it perfectly.
I thought my panel arrangement was too strange to have an official pixel mapper that supported it, but this new remap mapper removes the need from my original post of making a custom plugin loader.
I have 7 of the very common HUB75 panels, each are 64x32. I have them wired right to left in one horizontal chain as the standard data in/out direction goes. Parameters are width=64, height=32, chain=7, parallel=1 . The only difference is then I physically rotate each panel 90 degrees counter clockwise (each individually, not the whole panel chain as one). This forms a physical matrix of 224x64 instead of originally 448x32.
