Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please can the ability to modify HDMI timings on the fly (i.e. without having to carry out a reboot) be added to the firmware drivers #637

Closed
Grasshopper2 opened this issue Aug 4, 2016 · 46 comments

Comments

@Grasshopper2
Copy link

commented Aug 4, 2016

At the moment, it's only possible to create a single custom HDMI mode. The timings for this mode are defined in the config.txt file, and therefore cannot be changed without a reboot.

However, the ability to modify HDMI timings on the fly (i.e. without having to carry out a reboot) is essential for anyone who is using the RPi to emulate old hardware, and that's a very large percentage of RPi users. I would therefore like to put in a request for this facility to be added to the firmware drivers.

Thanks

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2016

Are you currently creating custom modes with hdmi_cvt= or hdmi_timings=?

Would you be happy with a gencmd to do:
vcgencmd hdmi_cvt 1680 1050 60 5 0 0 1
or
vcgencmd hdmi_timings 640 0 16 64 120 480 0 1 3 16 0 0 0 75 0 31500000 1
followed by a tvservice command to switch to the new timings:

tvservice -e "DMT 87"
fbset -depth 8 && fbset -depth 16
@ajefr

This comment has been minimized.

Copy link

commented Aug 8, 2016

Personnally, I'm using hdmi_timings, so
vcgencmd hdmi_timings 640 0 16 64 120 480 0 1 3 16 0 0 0 75 0 31500000 1
will be really, really perfect !
May I ask you if you could also check if pixel multiplier is working (pixel_rep) ?
Thanks

@Grasshopper2

This comment has been minimized.

Copy link
Author

commented Aug 8, 2016

So far, I've only experimented with using 'hdmi_cvt'. For example:

hdmi_cvt=1024 448 60 3 1 0 0

However, I might also need to use 'hmdi_timings' at some point because it allows for finer tuning. I don't see the two options as being mutually exclusive.

Being able to set both parameters with vcgencmd would obviously be a huge step forward. However, it would be even better if the display timings could be set through fbset. This is how the framebuffer works on most PC versions of Linux, and many emulators rely on that behaviour.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

Being able to set both parameters with vcgencmd would obviously be a huge step forward. However, it would be even better if the display timings could be set through fbset. This is how the framebuffer works on most PC versions of Linux, and many emulators rely on that behaviour.

Not with the gpu side driver. The experimental arm side graphics driver should support standard linux ways of configuring displays (like xorg.conf).

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

Test firmware here: https://dl.dropboxusercontent.com/u/3669512/temp/firmware_hdmigencmd.zip
Should support the hdmi_cvt and hdmi_timings gencmds mentioned earlier.

@Grasshopper2

This comment has been minimized.

Copy link
Author

commented Aug 8, 2016

I realise this is probably asking too much at this point, however, I think the ideal scenario would be to allow the framebuffer to operate in one of three possible modes, which are as follows:

Mode 1.
Retain the current behaviour. So, the signal to the monitor remains constant, and the new display mode is created purely by utilising GPU scaling. The GPU will always scale the image by the same factor in both the x and y planes. If the selected resolution won't fit exactly on the screen, the driver will compensate by adding black bars to the left and right, or the top and the bottom of the usable display area.

Mode 2.
Similar to mode 1. However, the driver will ensure that the new display mode will always completely fill the screen. This would mean that, under some circumstances, the GPU would scale the image by a different factor in the x and y planes. This would mimic the behaviour of a traditional Linux framebuffer that you find on PC versions of Linux. This would probably be the best option for most people who are using a modern flat screen monitor or TV.

Mode 3.
Behave exactly like a traditional Linux framebuffer. This would mean that no GPU scaling takes place. Instead, the new display mode would be created by modifying the signal being sent to the monitor. This would be the best option for emulation purists who like to hook up their computer to a genuine CRT arcade monitor.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

I realise this is probably asking too much at this point

This seems to be diverging from this feature request.
The current job is to support changing the current hdmi_cvt and hdmi_settings (from config.txt) without requiring a reboot. Note the code being changed now has nothing to do with the framebuffer and is purely HDMI timing related.
Lets make sure this feature is usable before moving the goalposts.
Your additional requests seem more related to #638 than to this issue.

@Grasshopper2

This comment has been minimized.

Copy link
Author

commented Aug 8, 2016

Sorry, as you've pointed out, my previous post should really have gone into the #638 thread. I won't bother moving it as you've already cross referenced the threads (and the two issues are somewhat related anyway).

@ajefr

This comment has been minimized.

Copy link

commented Aug 8, 2016

Test firmware here: https://dl.dropboxusercontent.com/u/3669512/temp/firmware_hdmigencmd.zip
Should support the hdmi_cvt and hdmi_timings gencmds mentioned earlier.

Thanks you very, very much for this debug firmware.
But I just tried it on a raspbian jessie lite, and got error :
error=1 error_msg="Command not registered"

Here is my test command :
vcgencmd hdmi_timings=320 1 25 30 30 240 1 9 3 10 0 0 0 60 0 6400000 6

Maybe I made a mistake ?

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

Yes, you don't want the equals. Try:
vcgencmd hdmi_timings 320 1 25 30 30 240 1 9 3 10 0 0 0 60 0 6400000 6

popcornmix added a commit that referenced this issue Aug 10, 2016
See: raspberrypi/linux#1581

kernel: enable gembird joypad support
See: raspberrypi/linux#1589

kernel: Added HiFiBerry Digi+ Pro driver
See: raspberrypi/linux#1583

kernel: overlays: Add assert_falling_edge to pps-gpio overlay
See: raspberrypi/linux#1590

kernel: Experimental graphics driver DSI support
See: raspberrypi/linux#1556

firmware: Add customisation project board type
firmware: platform: Enable Bluetooth on custom

firmware: gencmd: Add support for hdmi_cvt and hdmi_timings
See: #637

firmware: arm_display: Allow source aspect ratio to be configured
See: #638

firmware: mmal: Allow /dev/vchiq to be opened initialised prior to mmal_vc_init
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Aug 10, 2016
See: raspberrypi/linux#1581

kernel: enable gembird joypad support
See: raspberrypi/linux#1589

kernel: Added HiFiBerry Digi+ Pro driver
See: raspberrypi/linux#1583

kernel: overlays: Add assert_falling_edge to pps-gpio overlay
See: raspberrypi/linux#1590

kernel: Experimental graphics driver DSI support
See: raspberrypi/linux#1556

firmware: Add customisation project board type
firmware: platform: Enable Bluetooth on custom

firmware: gencmd: Add support for hdmi_cvt and hdmi_timings
See: raspberrypi/firmware#637

firmware: arm_display: Allow source aspect ratio to be configured
See: raspberrypi/firmware#638

firmware: mmal: Allow /dev/vchiq to be opened initialised prior to mmal_vc_init
@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 10, 2016

The new gencmd is in latest rpi-update firmware.

@ajefr

This comment has been minimized.

Copy link

commented Aug 10, 2016

@popcornmix Thanks you really, really, really much !!! A great asset for all retro players.

May I ask you if the pixel_rep is working ? I tried different value and no pixel repetition, I would like to create mode like the CEA 2x, CEA 4x

Best regards

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 10, 2016

I believe pixel rep works, but it's intention is purely to allow a higher pixel clock rate for lower resolution modes. This is to allow enough data to be transferred for hdmi audio during the blanking periods.

i.e. you double the pixel clock and set pixel rep to 2x and you end up with exactly the same image displayed (but have more clock cycles available for audio during the blanking).

Are you expecting it to do something different?
Have you tried some of the standard 2x or 4x modes? (e.g. "CEA 6" ?)

@ajefr

This comment has been minimized.

Copy link

commented Aug 12, 2016

Thanks for your answer, I will try a little bit later the 2x and 4x option.
I may have another problem.
Is the new feature also update the dpi output ? Because it didn't seem to change the dpi output.
I tried switching from 320x240 to 640x480 and dpi output is still the one from the config.txt.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2016

I believe it should work with dpi. What do you have in config.txt and what commands are you running to change resolution?
What does

tvservice -s
vcgencmd measure_clock pixel

report before and after the change?

@ajefr

This comment has been minimized.

Copy link

commented Aug 13, 2016

Here is my config.txt :
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
framebuffer_width=320
framebuffer_height=240
disable_overscan=1
hdmi_timings=320 1 25 30 30 240 1 9 3 10 0 0 0 60 0 6400000 1
dpi_group=2
dpi_mode=87
hdmi_force_hotplug=1
force_hdmi_hotplug=1
dtparam=spi=off
dtparam=i2c_arm=on
dtoverlay=pi3-disable-bt-overlay
boot_delay=3
disable_splash=1
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=512
avoid_safe_mode=1
kernel=zImage

And the command I used to swith mode :
vcgencmd hdmi_timings 320 1 25 30 30 240 1 9 3 10 0 0 0 60 0 6400000 1
tvservice -e "DMT 87"
fbset -depth 8 && fbset -depth 16 -xres 320 -yres 240
or
vcgencmd hdmi_timings 640 0 16 64 120 480 0 1 3 16 0 0 0 75 0 31500000 1
tvservice -e "DMT 87"
fbset -depth 8 && fbset -depth 16 -xres 640 -yres 480

Both timing are working fine if used in config.txt

And for example, if I start with a 320x240 mode and want to swith to 640x480
Before
tvservice -s
state 0x400000 [LCD], 320x240 @ 0.00Hz, progressive
vcgencmd measure_clock pixel
frequency(29)=25200000
After
tvservice -s
state 0x400000 [LCD], 320x240 @ 0.00Hz, progressive
vcgencmd measure_clock pixel
frequency(29)=31500000

320x240 and 640x480 are only for test purpose, the aim of the project is to use other exotic resolution (not listed in CEA or DMT)

@Grasshopper2

This comment has been minimized.

Copy link
Author

commented Aug 18, 2016

This might be down to my lack of understanding, but I'm finding this new command very hit and miss.

For example, first I put the following in my config.txt and reboot the machine:

overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
disable_overscan=1
hdmi_force_hotplug=1
config_hdmi_boost=4
hdmi_cvt=800 600 60
hdmi_group=2
hdmi_mode=87

I see the expected 800*600 display mode. The purpose of this exercise is to check that my monitor can handle the custom resolution (which it should be able to, as it's a standard VGA mode).

I then put the following in my config.txt and reboot the machine:

overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
disable_overscan=1
hdmi_force_hotplug=1
config_hdmi_boost=4
hdmi_group=1
hdmi_mode=16

This time I see the 1920*1080 mode which I normally use with my monitor.

I then run the following script on the command line to switch to the custom mode:

#!/bin/bash
vcgencmd hdmi_cvt 800 600 60
tvservice -e "DMT 87"
fbset -g 800 600 800 600 8

And I get a black screen.

I then run the following script, which is supposed to restore the original screen mode:

#!/bin/bash
tvservice -e "CEA 16"
fbset -depth 8 && fbset -depth 16

And the screen remains black. During my experiments, the display has gone black quite often, and once that heppens, it doesn't seem to be possible to get back to a usable display.

Any ideas?

@ajefr

This comment has been minimized.

Copy link

commented Aug 18, 2016

By my side, I never got black screen.
Is your monitor switching to the correct frequency ? (ie is it saying you have a 800x600 input signal and after a 1920x1080 signal)
From my experience, in dpi mode, output signal is not updated

@Grasshopper2

This comment has been minimized.

Copy link
Author

commented Aug 18, 2016

Is your monitor switching to the correct frequency ?

I don't know. My monitor doesn't tell you what frequency it thinks it's receiving.

But anyway, wouldn't you expect the same behaviour regardless of whether the frequency is changed during the boot process or after?

@sigmaris

This comment has been minimized.

Copy link

commented Aug 23, 2016

I think I'm having the same problem with DPI output as @ajefr. I have this in my config.txt

dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1 #320x240p

So it boots in 320x240, then I try to switch to 640x480i like this:

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.19-v7+ #906 SMP Tue Aug 23 15:53:06 BST 2016 armv7l GNU/Linux
pi@raspberrypi:~ $ tvservice -s
state 0x400000 [LCD], 320x240 @ 0.00Hz, progressive
pi@raspberrypi:~ $ vcgencmd measure_clock pixel
frequency(29)=65000000
pi@raspberrypi:~ $ vcgencmd hdmi_timings 640 1 29 60 70 480 1 1 3 23 0 0 0 60 1 12800000 1
hdmi_timings=640 1 29 60 70 480 1 1 3 23 0 0 0 60 1 12800000 1
pi@raspberrypi:~ $ tvservice -e "DMT 87"
Powering on HDMI with explicit settings (DMT mode 87)
pi@raspberrypi:~ $ fbset -depth 8 && fbset -depth 16 -xres 640 -yres 480
pi@raspberrypi:~ $ fbset -depth 8 && fbset -depth 16 -xres 320 -yres 240
pi@raspberrypi:~ $ tvservice -s
state 0x400000 [LCD], 320x240 @ 0.00Hz, progressive
pi@raspberrypi:~ $ vcgencmd measure_clock pixel
frequency(29)=12800000

The tvservice -e and the fbset command doesn't change the resolution, it just scales the linux console down to 1/4th of the screen. I had to use the second fbset command to get things back to normal.

I think the problem is tvservice -e "DMT 87". It says "Powering on HDMI with explicit settings (DMT mode 87)" but what I actually want is for the DPI output to start using the new timings. I don't have anything connected to HDMI.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2016

Yes, you are correct tvservice is the wrong call to reinitialise the DPI display. I'll look into another scheme to do that.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2016

Can you test this firmware:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_dpi.zip

Note I haven't been testing with an actual display - just looking at the settings, so this may not work.

e.g. in config.txt

hdmi_cvt=1280 720 60
hdmi_pixel_freq_limit_min=31250000

and at run time:

pi@domnfs:~ $ vcgencmd version
Aug 23 2016 22:46:16 
Copyright (c) 2012 Broadcom
version 91ad33618a418c6416ebe04a3a1cc67d639c5af4 (clean) (release)
pi@domnfs:~ $ vcgencmd measure_clock pixel
frequency(29)=148500000
pi@domnfs:~ $ tvservice  -s
state 0x400000 [LCD], 1280x720 @ 0.00Hz, progressive
pi@domnfs:~ $ vcgencmd dispmanx_list
display:0 format:XRGB8888 transform:0 layer:-127 src:0,0,1280,720 dst:0,0,1280,720 cost:801 lbm:0
pi@domnfs:~ $ vcgencmd hdmi_cvt 1024 768 60
hdmi_timings=1024 0 48 104 152 768 1 3 2 25 0 0 0 60 0 63500000 3
pi@domnfs:~ $ tvservice -s
state 0x400000 [LCD], 1024x768 @ 0.00Hz, progressive
pi@domnfs:~ $ vcgencmd dispmanx_list
pi@domnfs:~ $ vcgencmd measure_clock dpi
frequency(4)=0
pi@domnfs:~ $ fbset -depth 8 && fbset -depth 32
pi@domnfs:~ $ vcgencmd dispmanx_list
display:0 format:XRGB8888 transform:0 layer:-127 src:0,0,1280,720 dst:0,96,1024,576 cost:1115 lbm:16384
pi@domnfs:~ $ vcgencmd measure_clock dpi
frequency(4)=63492000

So, a few points. The clock you want to measure is dpi not pixel.
There is a minimum dpi clock of 31.25MHz. This comes from the 2GHz PLL with a maximum divisor of 64. You can get lower resolution by using the pixel doubling modes. hdmi_cvt handles that for you, but hdmi_timings needs to be done manually.

@ajefr

This comment has been minimized.

Copy link

commented Aug 23, 2016

Hi
Just tried the new version, dpi is now updated successfully !
But it looks that hdmi_cvt won't compute low resolution (ie 320x240 give no output)
I thought that dpi clock could be as low as 4.8Mhz (coming from a 19.2Mhz clock ? )

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2016

There is a minimum dpi clock of 31.25MHz. This comes from the 2GHz PLL with a maximum divisor of 64.

It may be possible to use a different source, but that it not currently supported.

@Grasshopper2

This comment has been minimized.

Copy link
Author

commented Aug 24, 2016

I'll have a go with the new firmware this weekend.

But in the meantime, could someone tell me whether the issues being described above are specific to the DPI output mode?

I don't own a VGA 666 adapter so I'm currently only able to test the custom display modes with a regular LCD monitor conected through HDMI. As mentioned earlier, I'm getting a black screen most of the time.

I also tried testing the custom modes using a cheap Chinese HDMI to VGA adapter that I bought on Ebay. However, the adapter doesn't seem to process any modes that are not part of the HDMI standard. I initially thought this was a limitation of the adapter. However, I'm now beginning to wonder whether it's actually the RPi that's sending an incorrect signal.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2016

For HDMI you can give me your config and I'll check with my monitor (Dell P2415Q) if we are outputting something usable.
The Dell won't display anything, but it's pretty good with custom modes.
I also have a JVC and Panasonic TV which won't display anything that is not a standard CEA mode (live 1080p48).

@Grasshopper2

This comment has been minimized.

Copy link
Author

commented Aug 24, 2016

Unfortunately, I'm not near my RPi right now. But earlier in the thread I described a scenario where I was able to display a custom mode (800x600@60hz) if the mode was defined in config.txt. But if I tried to switch to the same mode after booting the RPi I got a blank screen.

I'll carry out some more tests this weekend.

@Sir-Ironic

This comment has been minimized.

Copy link

commented Aug 26, 2016

Hi all (sorry for poor language, i'm french)
Popcomix,
i tried you firmware and it works with my GPIO to SCART homemade adaptator.

I use an Rpi2/Recalbox disto and a CRT TV.
My prototype

I would like to créate a lot of resolution but i don't know what i can use modelines
I tryed to converts a lot of modelines to hdmi_timings but a very few work.

Modeline "384x224" 7.500 384 400 435 486 224 240 243 259 -hsync -vsync
to
hdmi_timings 384 1 16 35 51 224 1 16 3 16 0 0 0 60 0 7500000 1
This Hdmi_Timings doesn't woks

I don't know why a can't use differents Pixels clock. My TV is going dark, no picture
Everywhere, i read everybody use 4800000 and 6400000 pixels clock, nothing else, Why ?

This Hdmi_Timing work on my TV 👍 hdmi_timings=320 1 20 29 35 224 1 10 14 16 0 0 0 60 0 6400000 1 # 320:224 Sega Genesis (NTSC)
hdmi_timings=256 1 6 17 18 192 1 26 22 29 0 0 0 60 0 4800000 1 # 256:192 Sega Master System (NTSC)
hdmi_timings=256 1 8 17 21 224 1 7 10 24 0 0 0 60 0 4800000 1 # 256:224 NES, SNES (NTSC)
hdmi_timings=320 1 20 29 35 224 1 10 14 16 0 0 0 60 0 6400000 1 # 320:224 Sega Genesis (NTSC)
hdmi_timings=320 1 14 46 28 256 1 17 32 9 0 0 0 50 0 6400000 1 # 320:256 Amiga (PAL)

Is there a frequency limit for CRT ? a multiplicator to use ? Anything ?
Why this pixels clocks don't change for Genesis and Amiga resolutions ?
I read a lot of things but i'am in trouble.

Sorry if this is not the place to write, just again thanks for this firmware and the ability to change resolutions without rebooting.

@popcornmix

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2016

HDMI pixel clock should be between 25Mhz and 162MHz. For lower resolutions/framerates pixel doubling and a higher clock should be used.
For DPI the minimum pixel clock is 31.25MHz.

@sigmaris

This comment has been minimized.

Copy link

commented Aug 27, 2016

Using the firmware from https://dl.dropboxusercontent.com/u/3669512/temp/firmware_dpi.zip I can change custom resolutions on DPI successfully, thanks for implementing this feature!

I am using a 15kHz monitor so need to keep the pixel clock low for screen modes like 320x240, but I have found that integer divisors of 19.2MHz work OK (e.g 6.4MHz and 9.6MHz).

The only problem I'm having now is with interlaced modes. I tried an ultra-wide 1920x480i mode, and it looks like it is outputting two fields, but the fields don't contain the even and odd lines of a full frame. It looks like one field is just shifted about 50% vertically down the screen. It's easier to see in this photo of a 512x480i mode: http://imgur.com/UlddUA0
It looks almost as if the CRTC is not scanning out from the right area of the frame buffer for each field, or something like that.

Commands I'm using for 1920x480i and 512x480i modes:

vcgencmd hdmi_timings 512 1 25 46 17 480 1 1 3 23 0 0 0 60 1 9600000 1
vcgencmd hdmi_timings 1920 1 93 181 209 480 1 1 3 23 0 0 0 30 1 38500000 1
@Sir-Ironic

This comment has been minimized.

Copy link

commented Aug 27, 2016

I think (i hope but i don't know) Pixel Clock limit can be resolved.

Why, if i use a HDMI2VGA adaptator and a VGA2SCART cable, i can use hdmi_cvt=1920 240 60 1 0 0 0 on my CRT.
And i can't do what i want if i use a GPIO2VGA and this same VGA2SCART cable (Whith hdmi_timings).

Who can we join to ask if this is possible or if it's a GPIO2VGA limit.
(Sorry for my language, i'm french)

ian57 pushed a commit to ian57/recalbox-buildroot that referenced this issue Nov 10, 2016
…-userland to a1b89e91f393c7134b4cdc36431f863bb3333163 to have the video resolution change on the fly thanks to vcgencmd commande line see raspberrypi/firmware#637
@amadvance

This comment has been minimized.

Copy link

commented Dec 10, 2016

I'm experimenting with this feature for the AdvanceMAME emulator, and it works great!

But I have only one issue to report. After using "tvservice" to set the new timings, the screen remains black, and even the tricks of "fbset -depth 8 && fbset -depth 16" or "chvt 2 && chvt 1" may not work if they are executed immediately after the tvservice call.

This can be easily reproduced on the shell. For example:

$ tvservice -p && fbset -depth 8 && fbset -depth 16

result on my system always in a BLACK screen. When instead:

$ tvservice -p && sleep 0.2 && fbset -depth 8 && fbset -depth 16

always show a correct console screen.

At now I've inserted in the AdvanceMAME emulator a sleep of 250 ms to cope with this issue. But obviously it's just a hack to make it working. A solution that is not "delay" dependent would be greatly appreciated.

My firmware is from 25 November 2016, version 48a26a2a...
I can reproduce this with my standard HDTV and a Makibes 1024x600 LCD screen.

@joolswills

This comment has been minimized.

Copy link

commented Dec 10, 2016

@amadvance I can confirm this - in RetroPie when changing mode I wait 1 second before resetting framebuffer. Also happens when exiting the pipplware Kodi (it does a tvservice -p). For some reason this was working at some point but now often causes a black screen (but it's fine if a delay is added).

@joolswills

This comment has been minimized.

Copy link

commented Dec 10, 2016

I would add that the Kodi exit script does the chvt 2 && chvt 1 trick with no delay, and only recently started causing a black screen. With the RetroPie mode change code (tvservice, then fbset), I think I always had to put a delay in, so it may have just been lucky that the Kodi script used to work without issue.

@Phlamethrower

This comment has been minimized.

Copy link

commented Dec 16, 2016

I recently ran into a similar issue when I added support for this feature to RISC OS. I found that after performing the mode switch via the TV service I had to wait for a mode change notification (i.e. VC_HDMI_HDMI or VC_HDMI_DVI reason passed to the tvservice callback function). Otherwise the mailbox commands which re-initialise the framebuffer seem to get lost in a black hole somewhere (the GPU accepts them and produces a valid response, but the screen remains black).

I guess you can either modify the tvservice binary to wait for that notification when it performs a mode change, or bypass the binary and use the userland libraries directly.

@amadvance

This comment has been minimized.

Copy link

commented Dec 29, 2016

Interfacing directly with the userland libraries, and registering a callback made it working.
Thanks!

@amadvance

This comment has been minimized.

Copy link

commented Feb 12, 2017

Hi @popcornmix

Could you please confirm if with the HDMI interface there is still a lower limit of 25 MHz for pixel clock ? (you said it in August in a message above)

I'm asking because from experiments, it seems that also values lower than 25 MHz are working.
What don't work are the exact 4.8 MHz, 6.4 MHz, 9.6MHz and 19.2 MHz clocks. But everything that is different than these four values seems to be OK.

Thanks,
Andrea

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
See: raspberrypi/linux#1581

kernel: enable gembird joypad support
See: raspberrypi/linux#1589

kernel: Added HiFiBerry Digi+ Pro driver
See: raspberrypi/linux#1583

kernel: overlays: Add assert_falling_edge to pps-gpio overlay
See: raspberrypi/linux#1590

kernel: Experimental graphics driver DSI support
See: raspberrypi/linux#1556

firmware: Add customisation project board type
firmware: platform: Enable Bluetooth on custom

firmware: gencmd: Add support for hdmi_cvt and hdmi_timings
See: raspberrypi#637

firmware: arm_display: Allow source aspect ratio to be configured
See: raspberrypi#638

firmware: mmal: Allow /dev/vchiq to be opened initialised prior to mmal_vc_init
@mikoyv3

This comment has been minimized.

Copy link

commented Apr 14, 2017

why 8 then 16 on the fbset command?

fbset -depth 8 && fbset -depth 16

@amadvance

This comment has been minimized.

Copy link

commented Apr 15, 2017

A change in the bit depth force the use of the new timings.

@nagualcode

This comment has been minimized.

Copy link

commented Oct 12, 2017

Kind off-topic but:
Is there a config.txt line for:
vcgencmd force_audio hdmi 1 ?

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2018

Closing this issue as questions answered/issue resolved.
Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.

@JamesH65 JamesH65 closed this Jun 29, 2018
@radi77777

This comment has been minimized.

Copy link

commented Jul 2, 2018

@sigmaris

Hi, i´ve got same monitor ... do you have settings for 640x256 (amiga PAL 15khz) cause 320x240 doesn´t show up all pixels
see example:
https://www.dropbox.com/s/0uxybaoj2dl7gzd/IMG_8016.jpg?dl=0
https://www.dropbox.com/s/6szga6sqpdn0gbs/IMG_8013.jpg?dl=0
regards

radi777

Using the firmware from https://dl.dropboxusercontent.com/u/3669512/temp/firmware_dpi.zip I can change custom resolutions on DPI successfully, thanks for implementing this feature!

I am using a 15kHz monitor so need to keep the pixel clock low for screen modes like 320x240, but I have found that integer divisors of 19.2MHz work OK (e.g 6.4MHz and 9.6MHz).

The only problem I'm having now is with interlaced modes. I tried an ultra-wide 1920x480i mode, and it looks like it is outputting two fields, but the fields don't contain the even and odd lines of a full frame. It looks like one field is just shifted about 50% vertically down the screen. It's easier to see in this photo of a 512x480i mode: http://imgur.com/UlddUA0
It looks almost as if the CRTC is not scanning out from the right area of the frame buffer for each field, or something like that.

Commands I'm using for 1920x480i and 512x480i modes:

vcgencmd hdmi_timings 512 1 25 46 17 480 1 1 3 23 0 0 0 60 1 9600000 1
vcgencmd hdmi_timings 1920 1 93 181 209 480 1 1 3 23 0 0 0 30 1 38500000 1
@Sir-Ironic

@sigmaris

This comment has been minimized.

Copy link

commented Jul 2, 2018

@radi77777 Use http://www.epanorama.net/faq/vga2rgb/calc.html to calculate settings. You should keep Horizontal sync frequency around 15.7kHz, Horizontal sync pulse length around 4.7 microseconds and Vertical sync pulse length around 200 microseconds (follow the specification at http://www.kirurg.org/emame/arcadetiming/ for a 15kHz monitor)
Note that for low pixel clocks, the firmware seems to only support integer divisors of 19.2MHz, see #734. If using the open source vc4 DRM driver this is not an issue, but that currently requires a kernel patch and custom Device Tree for DPI support: raspberrypi/linux#2429

@radi77777

This comment has been minimized.

Copy link

commented Jul 2, 2018

oh. thx for fast reply :)
That´s too much of technical stuff for me ;((( . (Im not a coder or linux crack)
I bought Pi2SCART and its working perfect for snes emulation... For amiga it is impossible to find optimal settings ... I already used the calc..site but no luck....
As i know "interlaced modes doesn´t work for pi2scart .. but 640X256 actually should work in p mode.
for now im working with:
hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1 #240p
thx

@mortaca

This comment has been minimized.

Copy link

commented Jul 2, 2018

@radi77777 Use RGB-Pi, this have te hability to change the timings on the fly and have a big database with the correct resolution for Amiga and a lot of systems.

@radi77777

This comment has been minimized.

Copy link

commented Jul 2, 2018

ok . thx ... will try that...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.