Samsung ultra wide monitor

Anybody know if RISC OS will work with this Samsung monitor

Depends whether it supports slower frame rates such as 24Hz, 25Hz or 30Hz. If so, probably, although you’ll have to faff about with CONFIG/TXT and the mode definition files to get it to work. That’s RISC OS on a Pi – I don’t know about other hardware.

I have a 4K (43" 3840×2160) monitor that it’s working with okay, but only at 24Hz. (Incidentally, my Philips monitor was a good deal cheaper than that Samsung one.)

I expect it will work fine with a Raspberry Pi or ARMX6. A peek at the manual suggests that it supports 3440×1440 at 30Hz, 50Hz, and 60Hz. However 60Hz is apparently only available via DisplayPort, so don’t expect to get that working. 50Hz looks like it might work OK (the required pixel rate might be a bit too high – I can’t remember the exact limit for the ARMX6). 30Hz should be fine.

The other modern machines (Titanium, IGEPv5, Pandaboard, etc.) are all limited to a max resolution of 2048×2048, so if you plan on using it with those then you definitely won’t be able to use it at the native resolution.

As Geoffrey says, it should be OK. I’m not sure on the limits of Pi bandwidth-wise (I’ve only seen 4k at sub-30hz on Pi, suggesting a possible limit, but have no hard evidence), but we have many ARMX6 users running at that resolution (we demo the systems at shows). Indeed, the standard monitor definition files we provide cover 3440×1440 at 30hz and 50hz (the rates Jeffrey mentions for HDMI). It should just be a case of “pick the resolution and off-you-go!”.

Note that Sammy monitors tend to use VA panels which don’t have as good colour reproduction as IPS, so you might want to look at one of the IPS units available of a similar price/spec for best colour (this is presonal preference, I returned a 4k VA panel because I couldn’t get on with it).

The Philips I have is IPS. Model 43put4900/12. But the Pi doesn’t seem able to drive it any faster than 24Hz at the full 4K resolution – and because I’ve defined that as the resolution in CONFIG.TXT, all the other resolutions are scaled to that by RISCOS so the GPU thinks they’re all 4K and delivers all of them at 24Hz.

If you limited the resolution in CONFIG.TXT to 3440×1440 (which would be sensible given that that’s your monitor’s native resolution) the Pi should be able to deliver that at anything up to about 40Hz, to judge by my Pi’s performance.

Thanks guys for the insight. Food for thought.

Oh – and 24 Hz is absolutely fine for anything other than video, or video games. I’m told it’s crap for those, but I’ve no experience of either (on the Pi – I do sometimes watch video on the Mac at 30Hz, which seems fine to me).

I think this CONFIG/TXT should work for you on the Samsung:

disable_overscan=1
hdmi_drive=2
hdmi_group=2
fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=128
init_emmc_clock=100000000
ramfsfile=CMOS
ramfsaddr=0×508000
kernel=RISCOS.IMG
hdmi_mode=87
hdmi_cvt=3440 1440 30 8 0 0 1
max_framebuffer_width=3440
max_framebuffer_height=1440
hdmi_pixel_freq_limit=400000000

This replaces the CONFIG/TXT already in !Boot.Loader (shift-double-click to open !Boot, and again to open Loader.) Best to rename the old CONFIG/TXT to something like CONFIGx/TXT and make a new one – anything in Loader has a horrible tendency to revert to its old contents on reboot (if someone can explain that to me, please do!)

You also need CMDLINE/TXT containing disable_mode_changes – also inside Loader in !Boot

Finally you may need an MDF file in !Boot.Resources.Configure.Monitors.Samsung – here’s a minimalist one that should work okay:

file_format:1
monitor_title:Samsung 2K
DPMS_state:3

# Mode: 3440 × 1440 @ 24Hz
startmode
mode_name:3440 × 1440
x_res:3440
y_res:1440
pixel_rate:1000
h_timings:0,0,0,3440,0,0
v_timings:0,0,0,1440,0,0
sync_pol:0
endmode

I’d call the file Samsung2K or something like that, but it’s not critical.

That pixel rate is just a dummy number, as are all the zeros in the timings – these values are not used on Pis. (I’m assuming all through this that you’re using a Pi and RC15 – I’ve no idea whether it would be the same on other hardware.)

(You may not need the MDF file if the monitor delivers its EDID nicely and RISCOS interprets it correctly. In the end I find I don’t need one for the Philips, but the one I’ve made gives me a range of modes not offered automatically, which means I can choose the trade-off between getting more detail on screen or having bigger icons etc. – where on that range I choose varies according to what I’m doing.)