egnor / pivid

Experimental video code for Linux / Raspberry Pi
MIT License
28 stars 4 forks source link

Support for less-common video modes #8

Closed egnor closed 2 years ago

egnor commented 2 years ago

Currently pivid only supports video modes corresponding to CTA-861 (consumer electronics TV modes), VESA DMT (list of monitor modes), or VESA CVT (formulas for computing monitor modes outside of DMT). However, some modes don't conform to any of them, even CVT, because of a nonstandard aspect ratio or the like. For example, @aubilenon has a 1080x1080 HDMI display whose modes don't correspond to any of these.

aubilenon commented 2 years ago

pivid_scan_displays doesn't show anything that looks promising

=== /dev/dri/card0 (vc4): platform/gpu/drm/card0 (gpu)
17:56:47.806     20u I [display] Opening display "/dev/dri/card0"...
Screen #32  HDMI-1 [connected]
  2560x1600p @60.000 280.9M    30[120-]150  5[12-]20 [ACTIVE]
  1920x1080i @60.000  74.2M    88[ 44+]148  4[10+]31 16:9
  1920x1080i @59.940  74.2M    88[ 44+]148  4[10+]31 16:9
  1280x720p  @60.000  74.2M   110[ 40+]220  5[ 5+]20
  1280x720p  @60.000  74.2M   110[ 40+]220  5[ 5+]20 16:9
  1280x720p  @59.940  74.2M   110[ 40+]220  5[ 5+]20 16:9
  1440x480i  @59.940  27.0M    38[124-]114  8[ 6-]31
   720x480p  @60.000  27.0M    16[ 62-]60   9[ 6-]30 4:3
   720x480p  @59.940  27.0M    16[ 62-]60   9[ 6-]30 4:3
   720x480i  @60.002  13.5M*2  19[ 62-]57   8[ 6-]31 4:3
   720x480i  @59.940  13.5M*2  19[ 62-]57   8[ 6-]31 4:3
   640x480p  @60.000  25.2M    16[ 96-]48  10[ 2-]33 4:3
   640x480p  @59.952  25.2M     8[ 96-]56   2[ 2-]41
   640x480p  @59.940  25.2M    16[ 96-]48  10[ 2-]33 4:3

Screen #41  HDMI-2 [connected]
  2560x1600p @60.000 280.9M    30[120-]150  5[12-]20 [ACTIVE]
  1920x1080i @60.000  74.2M    88[ 44+]148  4[10+]31 16:9
  1920x1080i @59.940  74.2M    88[ 44+]148  4[10+]31 16:9
  1280x720p  @60.000  74.2M   110[ 40+]220  5[ 5+]20
  1280x720p  @60.000  74.2M   110[ 40+]220  5[ 5+]20 16:9
  1280x720p  @59.940  74.2M   110[ 40+]220  5[ 5+]20 16:9
  1440x480i  @59.940  27.0M    38[124-]114  8[ 6-]31
   720x480p  @60.000  27.0M    16[ 62-]60   9[ 6-]30 4:3
   720x480p  @59.940  27.0M    16[ 62-]60   9[ 6-]30 4:3
   720x480i  @60.002  13.5M*2  19[ 62-]57   8[ 6-]31 4:3
   720x480i  @59.940  13.5M*2  19[ 62-]57   8[ 6-]31 4:3
   640x480p  @60.000  25.2M    16[ 96-]48  10[ 2-]33 4:3
   640x480p  @59.952  25.2M     8[ 96-]56   2[ 2-]41
   640x480p  @59.940  25.2M    16[ 96-]48  10[ 2-]33 4:3

I have been able to get X to output 1080x1080 with this stuff in my /boot/config.txt

hdmi_cvt:0=1080 1080 60 3 0 0 0
hdmi_cvt:1=1080 1080 60 3 0 0 0 
hdmi_group:0=2
hdmi_mode:0=88
hdmi_group:1=2
hdmi_mode:1=88

I got there long enough ago that I don't remember how I arrived at it, though I remember a bit of flailing, so I have no idea why it says 88 instead of 87 there.

egnor commented 2 years ago

Interesting, so the display itself doesn't present a 1080x1080 mode for negotiation.

In some ways this simplifies things-- instead of worrying about paying attention to modes offered by the display, I'll just come up with a way to specify entirely custom mode timings, and we can figure out (experimentally, if needed) what the screen wants. What happens when you send a 1920x1080 mode to that screen? Does it lop it off, or letterbox? (Does the screen have a data sheet?)

It's interesting that the Raspberry Pi is able to make a 1080x1080 CVT mode. I'll need to re-read the spec-- maybe my CVT algorithm is just being too picky about aspect ratios: https://github.com/egnor/pivid/blob/a1c742d86069ee27954fbfff73572d72b9391a89/display_mode.cpp#L27

If so, I can just fix that and then you specify 1080x1080 and it's all good.

egnor commented 2 years ago

Ah, looks like Reduced Blank Timing v2 allows arbitrary aspect ratios. I'd been too lazy to implement reduced blanking, but that seems like the right path forward. Maybe I can convince myself that any non-antediluvian screen will support reduced blanking, so we can just output RB for simplicity.

egnor commented 2 years ago

OK, 2928a35416b8cf6bb7ced8f1ce8cd85a03f7dc64 should fix this. It uses Reduced Blanking v2 whenever computing modes with CVT (which happens when falling back from the lists of "standard" modes). It also adds a new pivid_list_modes tool that can be used to list the modes it generates

% build/pivid_list_modes --x 1080 --y 1080
*** No CTA-861 modes match 1080x1080 ?hz

*** No VESA DMT modes match 1080x1080 ?hz

=== CVT synthesized modes for 1080x1080 ?hz ===
 1080x1080p @60     77.33M      8[ 32+]40  17[ 8-]6   [RBv2]

Of course, I can't actually test that mode with @aubilenon's display, but the timings do match other CVT generators, so hopefully I got the math right.