News:

Server migration complete, Welcome to version 2.1.1

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 15659
Latest: PaulDzRGB
New This Month: 9
New This Week: 3
New Today: 0
Stats
Total Posts: 128432
Total Topics: 15791
Most Online Today: 48
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 5
Guests: 29
Total: 34

Is a plugin approach suitable for GPU/framebuffer IO?

Started by djulien, January 17, 2022, 12:02:15 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

djulien

Quote from: CaptainMurdoch on March 08, 2022, 09:08:22 PM
Quote from: djulien on March 07, 2022, 10:09:27 PMI'm not seeing numbers like "45" or "112" in github (so I'm probably looking in the wrong place).  What is the date on those?
That number is basically a counter, it goes up one for every commit after the last tag.  It isn't as useful as the hash which is also in our version string, but it does help us to quickly see how old something is without looking up the hash itself.

'git describe --dirty' is what we use to get the version number presented in the UI.

Thanks for clarifying.  Does that info display anywhere on github itself, or it is only from the git command line?  I've been looking through the commit history on github.com but don't see anything that matches it.

CaptainMurdoch

The "every 5th pixel starting at pixel 6" issue is now fixed in master.  The initialization loop that sets up the non-changing bits in the framebuffer was initializing an extra bit at the end of each scan line which was being interpretted as the first bit of the first WS pixel on the next scan line starting at line 2 (the 6th WS pixel).  That explains why I wasn't seeing the issue with my latest code, because I rewrote the frame initialization code as part of adding support for banks and smart strings.

Quote from: djulien on March 08, 2022, 10:14:54 PMThanks for clarifying.  Does that info display anywhere on github itself, or it is only from the git command line?  I've been looking through the commit history on github.com but don't see anything that matches it.

The github UI only has the hash value as far as I know, not the commit #.  There is more info on this number in the "git help describe" output. 
-
Chris

bloojoop

Quote from: CaptainMurdoch on March 08, 2022, 11:10:41 PMThe "every 5th pixel starting at pixel 6" issue is now fixed in master

Ding ding ding... Chris, we have a winner.. After updating to the latest build of 6.x-master-117-gb7b098af, my display testing that I had been doing looks to be correct again!  I added a 2nd string to port two and a DDP output to a f16v4 with a string on it.  The "display testing" from fpp and the tools testing from xlights function as expected now.
--Ron A.

bloojoop

@djulien , Here are my config and dpipixels txt files for your enjoyment. 

You cannot view this attachment.
You cannot view this attachment.
--Ron A.

JonB256

Quote from: CaptainMurdoch on March 08, 2022, 11:10:41 PMThe "every 5th pixel starting at pixel 6" issue is now fixed in master. 

Yes, the 5th or 6th bluish pixel is now white (like it should be). That did correct that problem.
Long time Falcon, FPP and xLights user


djulien

Quote from: bloojoop on March 09, 2022, 12:49:22 PM@djulien , Here are my config and dpipixels txt files for your enjoyment.

Thanks.  I don't see any framebuffer or overscan settings that would interfere with DPI timing, but CaptainMurdoch already solved it.

ElfStuart

Bit late to the party on this thread but great to see the progress and has made me put my SMI based approach on hold.

Tried running the latest master branch on my Pi Zero 2 W.  Managed to push a DPIpixels-24 config from xlights to fpp but hitting an error which is stopping fppd running.  fppd error log says:
Apr 22 17:08:23 FPPv6 systemd[1]: Starting FPPd...
Apr 22 17:08:23 FPPv6 fppd_boot_pre[6492]: Setup channel outputs
Apr 22 17:08:24 FPPv6 fppd_boot_pre[6492]: Running pre-start scripts
Apr 22 17:08:24 FPPv6 fppd_boot_pre[6492]: FPP - Turning OFF screen blanking
Apr 22 17:08:24 FPPv6 fppd[6522]: Gpio 14 is illegal for LED channel 0
Apr 22 17:08:24 FPPv6 fppd[6522]: Magick: abort due to signal 11 (SIGSEGV)
"Segmentation Fault"...
Apr 22 17:08:24 FPPv6 systemd[1]: fppd.service: Main process exited,
code=killed, status=6/ABRT


Perhaps something wrong with GPIO config as it doesn't seem to like using GPIO 14 (pin 8 )[/pre]
The 'piuxel strings' outputs screen on fpp has populated correctly but when I go to channel outputs before it shows a pop-up error appears saying:

"Query gpio
Get gpio info failed: [object Object] "

CaptainMurdoch

Quote from: ElfStuart on April 22, 2022, 10:42:26 AMBit late to the party on this thread but great to see the progress and has made me put my SMI based approach on hold.

Tried running the latest master branch on my Pi Zero 2 W.  Managed to push a DPIpixels-24 config from xlights to fpp but hitting an error which is stopping fppd running.  fppd error log says:

The illegal error message is coming from the old 2-string rpi_ws281x library so your /home/fpp/media/config/co-pixelStrings.json file must have the RPIWS281X output setup, not the DPIPixels output.  The gpio error in the UI is due to fppd not being started.
-
Chris

ElfStuart

Quote from: CaptainMurdoch on April 22, 2022, 11:32:45 AMThe illegal error message is coming from the old 2-string rpi_ws281x library so your /home/fpp/media/config/co-pixelStrings.json file must have the RPIWS281X output setup, not the DPIPixels output.  The gpio error in the UI is due to fppd not being started.
Thanks - that was indeed the problem - manually overriding it sorted the issue..  looks like xlights is forcing that type in, is there a way yet to make sure it pushes 'DPIPixels' as the type instead?  Current test controller file in xlights looks like:

<Vendor Name="Test Vendor">
    <Controller Name="FPP">
        <!-- FPP's various serial outputs configured on the "Other" output tab -->
        <Variant Name="">
            <MaxPixelPort>0</MaxPixelPort>
            <MaxSerialPort>1</MaxSerialPort>
            <MaxSerialPortChannels>4096</MaxSerialPortChannels>
            <MaxPixelPortChannels>0</MaxPixelPortChannels>
            <SupportsAutoLayout/>
            <SupportsUpload/>
            <SupportsAutoUpload/>
            <PixelProtocols>
            </PixelProtocols>
            <SerialProtocols>
                <Protocol>DMX</Protocol>
                <Protocol>OpenDMX</Protocol>
                <Protocol>GenericSerial</Protocol>
                <Protocol>LOR</Protocol>
                <Protocol>Pixelnet</Protocol>
                <Protocol>Pixelnet-Open</Protocol>
                <Protocol>Renard</Protocol>
            </SerialProtocols>
            <InputProtocols>
                <Protocol>ddp-input</Protocol>
            </InputProtocols>
        </Variant>
    </Controller>
    <AbstractVariant Name="BaseFPPSettings">
        <SupportsPixelPortCommonSettings/>
        <SupportsUpload/>
        <SupportsInputOnlyUpload/>
        <MaxInputUniverses>1000</MaxInputUniverses>
        <InputProtocols>
            <Protocol>e131</Protocol>
            <Protocol>artnet</Protocol>
            <Protocol>ddp</Protocol>
        </InputProtocols>
        <SupportsMultipleSimultaneousInputProtocols/>
        <SupportsAutoUpload/>
        <SupportsFullxLightsControl/>
        <SupportsDefaultBrightness/>
        <SupportsDefaultGamma/>
        <PreferredInputProtocol>DDP</PreferredInputProtocol>
    </AbstractVariant>
    <AbstractVariant Name="FPPStringCape" Base="FPP:BaseFPPSettings">
        <MaxSerialPortChannels>512</MaxSerialPortChannels>
        <MaxPixelPortChannels>4200</MaxPixelPortChannels>
        <SupportsVirtualStrings/>
        <SupportsAutoLayout/>
        <SupportsRemotes/>
        <SupportsSmartRemotes>6</SupportsSmartRemotes>
        <AllSmartRemoteTypesPerPortMustBeSame/>
        <SupportsPixelPortEndNullPixels/>
        <PixelProtocols>
            <Protocol>ws2811</Protocol>
        </PixelProtocols>
        <SerialProtocols>
            <Protocol>dmx</Protocol>
            <Protocol>pixelnet</Protocol>
        </SerialProtocols>
        <SmartRemoteTypes>
            <Type>falcon_v1</Type>
            <Type>fpp_v2</Type>
        </SmartRemoteTypes>
    </AbstractVariant>

<Controller Name="DPIPixels-24">
<Variant Name="" ID="DPIPixels-24" Base="FPP:FPPStringCape">
<MaxPixelPort>24</MaxPixelPort>
<MaxSerialPort>0</MaxSerialPort>
<MaxPixelPortChannels>2400</MaxPixelPortChannels>
<SupportsVirtualStrings/>
<SupportsAutoLayout/>
            <SupportsPixelPortEndNullPixels/>
<PixelProtocols>
<Protocol>ws2811</Protocol>
</PixelProtocols>
            <fppStringFileName>co-pixelStrings</fppStringFileName>
</Variant>
</Controller>

</Vendor>

CaptainMurdoch

Quote from: ElfStuart on April 22, 2022, 05:43:12 PMThanks - that was indeed the problem - manually overriding it sorted the issue..  looks like xlights is forcing that type in, is there a way yet to make sure it pushes 'DPIPixels' as the type instead?  Current test controller file in xlights looks like:

I haven't taken a look at xLights yet because I haven't finished committing changes to DPIPixels.  I do plan on taking a look at xLights in a while.
-
Chris

JonB256

Latest update to Master Branch v6.x-master-273-g80097664 has all the new EEPROM and Virtual EEPROM code enabled. On the DPI-24 board I have, made by Don Julien (no EEPROM), it quit working past 50 pixels until I get a key.

For now, on that board, I've detached back to v6.x-master-260-gecf0a27a ((HEAD detached at ecf0a27a) branch) to regain full capability.

I'll worry about it again after May 27th when keys begin to be issued.
Long time Falcon, FPP and xLights user

CaptainMurdoch

Quote from: JonB256 on May 20, 2022, 01:59:08 PMLatest update to Master Branch v6.x-master-273-g80097664 has all the new EEPROM and Virtual EEPROM code enabled. On the DPI-24 board I have, made by Don Julien (no EEPROM), it quit working past 50 pixels until I get a key.

The UI won't allow configuring more than 50, but the backend code should continue to allow more than 50 until we start issuing vouchers.
-
Chris

3636lightshow

Quote from: djulien on March 07, 2022, 10:12:36 PM
Quote from: fone626 on March 07, 2022, 08:14:43 PMI guess I'll take 2nd place.


...and third place.

I think you actually get 1st and 2nd place.  (The board I made did not have all the accessories on it like sockets, fuses, etc).
Is this board is available for sale or it is Kicad open source 

Cureck

Quote from: 3636lightshow on July 25, 2022, 08:26:40 PM
Quote from: djulien on March 07, 2022, 10:12:36 PM
Quote from: fone626 on March 07, 2022, 08:14:43 PMI guess I'll take 2nd place.


...and third place.

I think you actually get 1st and 2nd place.  (The board I made did not have all the accessories on it like sockets, fuses, etc).
Is this board is available for sale or it is Kicad open source
I'm going to second this.... I'd buy it in a heart beat.

Support FPP

+- Recent Topics

Warning/Error: Network incomplete frames hit 250. by JonD
Today at 10:59:15 AM

F16V3 with 2 expansion boards at 40 fps MAX PIXELS per output? by tbone321
February 06, 2023, 10:51:55 AM

F48V4-NS at 40 fps using all 48 pixel output ports? by Poporacer
February 06, 2023, 10:27:09 AM

Unable to update RPi 5.5 to latest version by JonB256
February 05, 2023, 07:23:16 PM

help getting started, next step? by rayster
February 05, 2023, 04:24:09 PM

F48v4NS - Pi or No Pi? by joeyblasko
February 05, 2023, 09:15:33 AM

Huidu Controllers LED matrix by CaptainMurdoch
February 04, 2023, 10:18:47 AM

FPP6.2 universes by darylc
February 03, 2023, 08:48:57 PM

F16v4 Ports vs Universe Configuration Question by k6ccc
February 03, 2023, 09:32:48 AM

Need Expert Advise on F16v4 Ports vs Universe Configuration by Kairus
February 03, 2023, 09:32:33 AM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod