Has anyone gotten the 340 display working?

[wjegr...@gmail.com]

I run a headless system, X11, VNC into it. When trying to start the 340, something happens but no display ever comes up. See the pic, a snippet from trying 'pdp type340'.

[wjegr...@gmail.com]

Oh, and what's with the async eth error? Any reason it's not being build for async?

[oscarv]

See the manual and the recent bug fix. If you unstalled headless, and then want to use the Type 340, you have to run install again. Quite annoying Wayland consequence, working on a more elegant solution.

Kind regards,

Oscar.

[oscarv]

On Saturday, May 4, 2024 at 11:06:54 PM UTC+2 wjegr...@gmail.com wrote:

Oh, and what's with the async eth error? Any reason it's not being build for async?

Hm! I will look into that tomorrow.

Kind regards,

Oscar.

[oscarv]

Oh, wait - you switched to running X11, not Wayland.

Then I need to investigate. You did do an update in the last two days?

...this whole Wayland and X11 malarkey in the new Bookworm Pi OS version is quite a headache. 

Kind regards,

Oscar.

[wjegr...@gmail.com]

Ok, it's another headless issue. If I boot up the rPi with a monitor connected,  the TV340 display comes up. THEN I can connect via VNC and see it.Pure headless, no TV340 display visible. But, where I have my PidP located, a monitor isn't a permanent option. ITS can also be stopped and started multiple times with no problem. The headless ITS start issue seems to be when the TV340 is being brought up. I'm researching, but my impression is that booting works the first time because tv340 is starting (but never shows up on the VNC desktop). If ITS is shut down and the similator stopped, that doesn't stop the TV340 instance, and then subsequent ITS boots fail at the point the tv340 is being started. But, it's already running, so startup exits. Well, that's my theory,  at least. Looking into it more.

And bingo, I got around all my issues by using one of those HDMI dummy monitor widgets. rPi thinks there's an attached monitor, everything comes up and works. This is a total hack, but at least the problem is has been isolated more. Will keep researching.

[R H]

Hi, have you tried adding the following into the pi’s /boot/config.txt file…

hdmi_force_hotplug=1
hdmi_drive=2

This should force the Pi to think it is connected to an HDMI display when booting, it might do the same as the widget you tried?

Cheers, Richard

[wjegr...@gmail.com]

Interesting, I'll give that a try. I'd still like to figure out why a display is needed.

 

[Steven A. Falco]

On 5/6/24 07:29 AM, wjegr...@gmail.com wrote:
> Ok, it's another headless issue. If I boot up the rPi with a monitor connected,  the TV340 display comes up. THEN I can connect via VNC and see it.Pure headless, no TV340 display visible. But, where I have my PidP located, a monitor isn't a permanent option. ITS can also be stopped and started multiple times with no problem. The headless ITS start issue seems to be when the TV340 is being brought up. I'm researching, but my impression is that booting works the first time because tv340 is starting (but never shows up on the VNC desktop). If ITS is shut down and the similator stopped, that doesn't stop the TV340 instance, and then subsequent ITS boots fail at the point the tv340 is being started. But, it's already running, so startup exits. Well, that's my theory,  at least. Looking into it more.
> And bingo, I got around all my issues by using one of those HDMI dummy monitor widgets. rPi thinks there's an attached monitor, everything comes up and works. This is a total hack, but at least the problem is has been isolated more. Will keep researching.

Another approach is to modify the kernel command line to force a video mode. You can do that by editing /boot/firmware/cmdline.txt and adding something like video=HDMI-A-1:1280x1024@60D. I have to do that because I have two Pi-5 boards connected to an HDMI KVM. When the Pi boards boot, one Pi will see the connected monitor but the other Pi won't. Adding the video= phrase does roughly the same thing as your dummy monitor widget without needing extra hardware.

Here is my cmdline.txt file:

$ cat /boot/firmware/cmdline.txt
console=tty1 root=PARTUUID=7f2f1b0c-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=US video=HDMI-A-1:1280x1024@60D

I would have liked to use 1920x1080 rather than 1280x1024, but I had trouble getting 1920x1080 to work properly with my monitor - I kept getting "timing out of range" errors. But that is not a problem because I also edited /usr/share/dispsetup.sh, which let me readjust the timing when logging in. Please note that I'm running X11 rather than Wayland - I don't know if Wayland has the dispsetup.sh file, but if not there is probably something similar for Wayland somewhere. Here is that file:

$ cat /usr/share/dispsetup.sh
#!/bin/sh
xrandr --newmode "1920x1080" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
xrandr --addmode HDMI-1 "1920x1080"
xrandr --output HDMI-1 --mode "1920x1080"
exit 0

I got the above timing numbers by looking in /var/log/Xorg.0.log on the Pi that was connected to the monitor. You can also use a web site to calculate video timing here: https://tomverbeure.github.io/video_timings_calculator

And, there is a tool called "cvt" which can calculate monitor timings - I found that here: http://www.uruk.org/~erich/projects/cvt/ but you have to download and build it from source.

If you search around you will find that this is a very old problem and lots of people have come up with ways to calculate and override monitor settings.

Steve

[wjegr...@gmail.com]

Doing some research and playing around, the old hdmi_force_hotplug is no longer supported. I'm trying Steve's solution. It's interesting that I never came across this issue on any of my other rPi headless systems, of which I have 3, a music server, a PiDP-8, and a PiDP-11. Would be nice if there was an ITS-specific fix, I still suspect it's related to starting the Type 340 display. I'm very unimpressed with the Wayland stuff so far.

[Steven A. Falco]

On 5/6/24 10:02 AM, wjegr...@gmail.com wrote:
> Doing some research and playing around, the old hdmi_force_hotplug is no longer supported. I'm trying Steve's solution. It's interesting that I never came across this issue on any of my other rPi headless systems, of which I have 3, a music server, a PiDP-8, and a PiDP-11. Would be nice if there was an ITS-specific fix, I still suspect it's related to starting the Type 340 display. I'm very unimpressed with the Wayland stuff so far.

I struggled with Wayland for a long time and finally decided it is missing too much functionality that I depend on. Maybe someday it will be usable, but not today.

Please let me know if my method solves your problem or if you need additional info.

Steve

[Ian Schofield]

Dear All,

 Hope this helps. Type340 runs very nicely.....

PI5:

pi@pi11:~ $ uname -v
#1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25)

XWayland display server.

No HDMI connection.

Running wayvnc server (install with sudo apt install wayvnc)

pi@pi11:~ $ systemctl status wayvnc
â— wayvnc.service - VNC Server
     Loaded: loaded (/lib/systemd/system/wayvnc.service; enabled; preset: enabl>
     Active: active (running) since Mon 2024-05-06 14:39:09 BST; 14min ago
       Docs: man:wayvnc
   Main PID: 893 (sh)
      Tasks: 9 (limit: 9255)
        CPU: 1min 8.431s
     CGroup: /system.slice/wayvnc.service
              /bin/sh /usr/sbin/wayvnc-run.sh
              wayvnc --render-cursor --detached --config /etc/wayvnc/config
pi@pi11:~ $ xrandr
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm

cat /etc/wayvnc/config
use_relative_paths=true
address=::
enable_auth=true
enable_pam=true
private_key_file=tls_key.pem
certificate_file=tls_cert.pem
rsa_private_key_file=rsa_key.pem

Set the resolution you want in Preferences->Raspberry Pi Configuration->Display.

Sorry for a lot of detail. 

Regards, Ian.

[Ian Schofield]

Dear All,

 Oooops! Config.txt is unchanged from default and contains only this bit this is display related......:

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

BW, Ian.

[oscarv]

All,

I will follow Ian's idea in a next update, but I am travelling at the moment.

There is a very simple solution though (yes, this is all about the type340 display window, it expects a GUI canvas to paint itself on and - there's the catch, I always have a HDMI monitor attached even when I install 'headless'):

disable the line 'set dpy ena' in /opt/pidp10/systems/its/boot.pi and boot.pidp. 

That will take care of the issue if you do not have a HDMI monitor attached!

But Ian's way should be how the install script configures the Pi - always have a graphics canvas to paint on, even when there's no HDMI monitor to look at it. Will investigate!

Kind regards,

Oscar.