#83

N/Mind. After a forced RESET it behaves normally now…

1 Like
#84

@lcchy & @okyeron (posting in public in case anyone else also has insight)

There are a couple things I’m curious about that affect the usability of Eyesy on Fates. I’m going to dig in myself to see what I can discover but if anyone happens to know the answers off the top of their head it would be great to get some insight.

  1. Sometimes when I launch Fates with an HDMI cable plugged in, I also get halted at a login prompt as @swhic describes above; though for me, it displays on the Fates display rather than on the monitor as they show. Does anyone know the process by which Fates/Sidekick/Norns autologs in and launches an application? I want to figure out how Fates would get into a state where it would not auto-launch.

  2. I’ve noticed in testing that if I’m in “Eyesy” mode - That is, Fates is running Eyesy correctly on HDMI output - and I switch apps via Sidekick, ORAC completely ignores the HDMI out (and thus operates correctly), while Norns tries to use the HDMI out (at least on my Pi4) and thus is unusable. Does anyone know what would cause an app to try to use or else ignore the HDMI out?

#85

I think we’re currently in a state where switching between Eyesy and Norns via Sidekick is problematic and also that getting Eyesy up-and-running can require a specific set of launch steps. All this is useful information, so I appreciate you sharing what’s happening for you. Glad Norns is working again!

#86

No change, forgot to mention I am on a pi3… no hdmi out when on norns or sidekick.

#87

Pretty much everything is from systemd.

So I think ORAC is smarter about the framebuffer being used (not sure where tho Here I think).

Norns software is hardwired for a specific framebuffer (depending on which pi you have). On a pi3, the HDMI is always framebuffer 0. But, on the pi4, the framebuffer gets dynamically assigned, so with nothing plugged in, the OLED is fb0, but with HDMI plugged in, HDMI is fb0 and the OLED is fb1 (so norns goes to the HDMI)

Note - If someone has some bash and systemd skillz - please DM me

1 Like
#88

Okie Doki… I may have a solution to the pi4 display stuff with regards to norns.

If this works ok in testing, I’ll try to wrap it into the next norns/fates update :slight_smile:

2 Likes
#89

It works!!! :wink:

6 Likes
#90

Is your Fates booting by default into norns ?
I had the same issue and with your second point I think it could all be due to the same problem that @okyeron wrote about (and is already solving :stuck_out_tongue: )

A short term solution to your first problem could be to set Fates to boot into Sidekick by default which you can do in sidekick/sidekick.json

Niice!!

#91

+1 for wanting this to work with norns shield. Maybe someone could cook up a “dirty” edited shields image that enables the hdmi port? For testing purposes.

2 Likes
#92

Absolute noob here. I have no technical knowledge and haven’t even gotten around to figuring out how to install others‘ apps on Fates.

Is the most recent version of the Eyesy port functioning and stable so I can just run it on Fates (Pi4) or should I wait until the more technically minded of you have figured everything out and I don’t have to run mysterious (to me) additional lines of code and such?
:grimacing:

#93

Wait.

It’s VERY early days with this. We’re still just figuring things out.

In the meantime read up on how to SSH on raspberry pi.

3 Likes
#94

Thank you! I will follow your advice!

Is there any chance Critter & Guitari will put a stop to this development?
Or is it open source?

1 Like
#95

This is the beauty of open source! I think they are very open to all kinds of experimentation with their code, they were in the past :slight_smile:
Amazing things like Orac wouldn’t have seen the light otherwise and it’s not like we are selling a clone for half the money.
Someone who seeks a robust platform for video synthing with customer support and appropriate hardware should definitely go buy the Eyesy! what we are doing here is just some happy time experimentation

4 Likes
#96

:tada: 20 characters of :point_up:

:grinning:

3 Likes
#97

This is so much fun! I have only scratched the surface.

Initial Experiment with composite output:
I edited my config. text with enable_tvout=1 which has enabled the composite out, but this also seems to make the HDMI out not work anymore and will only display EYESY on the Fates screen. Returning the config file to its prior state has restored order.

1 Like
#98

Can you test with enable_tvout=1 and then get the result from cat /proc/fb ?

Maybe with and without HDMI plugged in on reboot?

#99

With HDMI plugged in on boot: 0 fb_ssd1322
Without: 0 fb_ssd1322

What does it mean? :slight_smile: (thanks for the reply)

#100

So… the HDMI and OLED use the system “framebuffers” to output video.

on my Pi4
1 fb_ssd1322 is the OLED (fb1)
0 DRM emulated is the HDMI (fb0)

So… in the case of enable_tvout, it seems that this does not use the framebuffers? Will need to do more research on that and see what I can find.

FWIW:

enable_tvout (Pi 4B only)
On the Raspberry Pi 4, composite output is disabled by default, due to the way the internal clocks are interrelated and allocated. Because composite video requires a very specific clock, setting that clock to the required speed on the Pi 4 means that other clocks connected to it are detrimentally affected, which slightly slows down the entire system. Since composite video is a less commonly used function, we decided to disable it by default to prevent this system slowdown.

1 Like
#101

Uploading: IMG_20201118_101326.jpg…
This thing can go really wild

#102

Thanks! Let me know if you need any testing! I’ll keep hacking at it from my end. Either way, this is so much fun!

I’m also gonna try out a cheap HDMI -> NTSC converter and see how it does.