Code: Select all
dtoverlay=dpi24
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=0x6f005
hdmi_cvt=1024 600 60 6 0 0 0
/shudder A couple of weeks ago I did a proofreading pass over a 400 page manuscript of my wife's WIP. But that was fiction. Easy to read and no verification of actual facts required.
hdmi_cvt will apply to the HDMI port (which will be active at the same time. I don't recall if it got duplicated to dpi_cvt or not.tomasf wrote: ↑Wed Jun 26, 2019 5:46 pmHi,
I received my Raspberry Pi 4B today. Seems fantastic so far!
One problem I have encountered is getting my DPI display to work. It works great on my 3B+, but it's all black on my 4B. It's one of these: https://www.waveshare.com/wiki/7inch_LCD_for_Pi
I'm basically using the configuration lines from that page:It uses the documented backward compatible hdmi_cvt entry. Just an idea, but has this perhaps stopped working on RPi 4? Do I need to craft a dpi_timings entry instead? I tried to construct one from the panel data sheet, but it's pretty tough. ( https://www.waveshare.com/w/upload/1/1a ... LCD_DS.pdf )Code: Select all
dtoverlay=dpi24 enable_dpi_lcd=1 display_default_lcd=1 dpi_group=2 dpi_mode=87 dpi_output_format=0x6f005 hdmi_cvt=1024 600 60 6 0 0 0
Or if that isn't it, any other ideas? Thank you!
Code: Select all
$ cvt 1024 600 60
# 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz
Modeline "1024x600_60.00" 49.00 1024 1072 1168 1312 600 603 613 624 -hsync +vsync
See
6by9 wrote: ↑Wed Jun 26, 2019 6:18 pmIf not, then running "cvt 1024 600 60" gives the standardised timings for that mode.That's not quite in the right format for dpi_timings.Code: Select all
$ cvt 1024 600 60 # 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz Modeline "1024x600_60.00" 49.00 1024 1072 1168 1312 600 603 613 624 -hsync +vsync
That format is https://github.com/raspberrypi/linux/bl ... des.h#L157 where you can see values are cumulative. For dpi_timings they are independent, so a little bit of subtraction is required.
Code: Select all
1024 (horizontal pixels) self-explanatory
1 (invert hsync) I suppose this corresponds to "-hsync" in the cvt output. Negative sounds like it would be considered to be inverted?
48 (h front porch) hsync_start-hdisplay (1072-1024 = 48)
96 (hsync pulse width) hsync_end-hsync_start (1168-1072 = 96)
144 (h back porch) htotal-hsync_end (1312-1168 = 144)
600 (vertical pixels) self-explanatory
0 (invert vsync) Corresponds to +vsync? See above.
3 (v front porch) vsync_start-vdisplay (603-600 = 3)
10 (v sync pulse width) vsync_end-vsync_start (613-603 = 10)
11 (v back porch) vtotal-vsync_end (624-613 = 11)
0 (v sync offset a) should be zero according to docs
0 (v sync offset b) ditto
0 (pixel rep) ditto
60 (frame rate) self-explanatory
0 (interlaced) zero according to docs
49000000 (pixel frequency) 49 MHz from cvt output. Makes sense and is within the range according to that datasheet.
3 (aspect ratio) 15/9 is the closest aspect ratio in the list. Actual aspect ratio is 128/75.
I'll try and pull out the full timings that your hdmi_cvt line applies when I'm in the office tomorrow.tomasf wrote: ↑Wed Jun 26, 2019 9:21 pm
Thanks for that. Very useful.
I constructed a `dpi_timings` from this and got: `dpi_timings=1024 1 48 96 144 600 0 3 10 11 0 0 0 60 0 49000000 3`.
Sadly, it doesn't work. Here's my thinking behind each parameter:
I tried all four combinations of inverted [hv]sync, but to no avail. Screen is still just black.Code: Select all
1024 (horizontal pixels) self-explanatory 1 (invert hsync) I suppose this corresponds to "-hsync" in the cvt output. Negative sounds like it would be considered to be inverted? 48 (h front porch) hsync_start-hdisplay (1072-1024 = 48) 96 (hsync pulse width) hsync_end-hsync_start (1168-1072 = 96) 144 (h back porch) htotal-hsync_end (1312-1168 = 144) 600 (vertical pixels) self-explanatory 0 (invert vsync) Corresponds to +vsync? See above. 3 (v front porch) vsync_start-vdisplay (603-600 = 3) 10 (v sync pulse width) vsync_end-vsync_start (613-603 = 10) 11 (v back porch) vtotal-vsync_end (624-613 = 11) 0 (v sync offset a) should be zero according to docs 0 (v sync offset b) ditto 0 (pixel rep) ditto 60 (frame rate) self-explanatory 0 (interlaced) zero according to docs 49000000 (pixel frequency) 49 MHz from cvt output. Makes sense and is within the range according to that datasheet. 3 (aspect ratio) 15/9 is the closest aspect ratio in the list. Actual aspect ratio is 128/75.
Is there anything obviously wrong with these values? Thanks!
Oh, I was watching an old video of Caspa the Lion Man starring Buster Crabbe and then.....I see the news about the pi 4 running Buster.W. H. Heydt wrote: ↑Wed Jun 26, 2019 11:49 pmThe reference is to the dog in the Toy Story movies. Your picture, however, is Crabbe as Flash Gordon. (And, no, I didn't have to look that up.)
There are probably folks at RPT already thinking about the Pi6, while the Pi5 is probably already starting to be sketched out.
That's consistent with the initial manufacturing mix and the RPT/RPF expectations of usage patterns, as compared to what the early adopters went for.So, I just got a pi4b 2GB, others were sold out. 4GB sold out. I'm downloading image file and flashing uSD right now....
Glad I live a few miles from Micro Center. Micro Center should pay me for advertising for them.
jamesh mentioned that they had been discussing the Pi6 a few days ago.W. H. Heydt wrote: ↑Thu Jun 27, 2019 1:00 amThere are probably folks at RPT already thinking about the Pi6, while the Pi5 is probably already starting to be sketched out.
Which would have broken the $35 price point. Either that, or other features would have to be left out.ScriptBasic wrote: ↑Thu Jun 27, 2019 3:16 amThe base RPi 4 B should have started off at 4 GB with a socket to add more.
That made me chuckle. It's not 1980 and a DIP 2K DIP RAM expansion for your Z80 SBC.The base RPi 4 B should have started off at 4 GB with a socket to add more.
everyone has different needs, personnally I'd even like a 512MB version since my usage needs very little RAM.ScriptBasic wrote: ↑Thu Jun 27, 2019 3:16 amThe base RPi 4 B should have started off at 4 GB with a socket to add more.
if you plug it into the usb 3 socket you will get usb3 speedsSjurdur wrote: ↑Thu Jun 27, 2019 8:03 amThis article lists a few enclosures to give you an idea of what I am talking about: https://www.anandtech.com/show/13953/pl ... ule-review
Is this technically possible? Or is the pi limited to only sata drives?
Factor 4 sounds very good. (Not to confuse with "Factor 5" and their Turrican.)
Nope.ScriptBasic wrote: ↑Thu Jun 27, 2019 3:16 amThe base RPi 4 B should have started off at 4 GB with a socket to add more.