Shop OBEX P1 Docs P2 Docs Learn Events
P2 DVI/VGA driver - Page 18 — Parallax Forums

P2 DVI/VGA driver

11415161820

Comments

  • evanhevanh Posts: 15,694
    edited 2022-03-11 14:41

    @evanh said:
    ... that's a good point, I haven't carefully compared the streamer command ordering ...

    Okay, this will be it. I can see you've reordered the hsync XCONTs. For something called "breezeway" by the looks. At least that's a why.

  • evanhevanh Posts: 15,694

    Oh, for some reason you've moved

                                xcont   m_bs, hsync0            'generate horizontal FP blanking
    

    outside the hsync subroutine. So not all hblanking calls will start with a front porch.

  • roglohrogloh Posts: 5,606
    edited 2022-03-11 14:44

    Probably some sort of optimization, to buy time or more cycles for the mouse sprite or to save instruction space etc...

  • evanhevanh Posts: 15,694

    I've moved that instruction, from where it was, back into the hsync subroutine and it's fixed the issue. :)

    hsync
                                xcont   m_bs, hsync0            'generate horizontal FP blanking
                                xzero   m_sn, hsync1            'generate the sync pulse
                                wrlong  status, statusaddr      'update the sync status per line
    dobreeze                    xcont   m_br, hsync0            'do breezeway before colour burst
                                setcq   cq                      'reapply CQ for PAL colour changes
    doburst                     xcont   m_cb, colourburst       'do the PAL/NTSC colour burst
    flipref                     xor     cq, palflipcq           'toggle PAL colour output per scanline
    bp          _ret_           xcont   m_bv, hsync0            'generate the back porch
    
  • evanhevanh Posts: 15,694
    edited 2022-03-11 16:49

    Holy cow! E-EDID is ghastly! ... It looks like what I'm after is called DisplayID. I'm guessing it was introduced alongside DisplayPort. It details supporting of VRR features.

  • evanhevanh Posts: 15,694
    edited 2022-03-12 02:44

    @rogloh said:
    I have a Pioneer plasma TV (1366x768) to test with over HDMI or VGA, ...

    That's the weirdest resolution. 1366 doesn't divide by 8. Now you've pointed it out I see that my Dick Smith TV is also spec'd exactly the same native resolution ... and neither driver works ... okay, Eric's one simply can't do exactly that resolution since it's locked to multiples of 8. Your one just stops displaying anything above 1360 horizontal ...

    EDIT: Correction, Eric's driver needs multiples of 16 to behave. ie: An even number of columns ... Been all the way up to 1600x900 with this driver - 370 MHz sysclock, 24 Hz refresh.

    Your driver also rounds to multiples of 8, and also has a character column glitch with odd number of columns ... and still no picture above 1360 ... the TV reports no mode detected, nor invalid, but also not auto-power-down.

    EDIT2: LOL, guess what? Putting that damn front porch XCONT back where you had it fixes the hi-res limitation. Must just be a coincidence it hit right on the 1366 point.

  • roglohrogloh Posts: 5,606
    edited 2022-03-12 02:48

    My driver can go up to 1920x1200 at 60Hz with VGA. It works on my Dell monitor at native resolution, but it needs a specific timing setup to sync right, only possible once I obtained it for that model from somewhere online.

    I'll probably have to look into this xcont moving thing at somet point if you think it is a bug and causes sync issues, can't say I was really paying a lot of attention at 1.45am to what you were saying.

    Update: I think the Pioneer can accept both 1360 and 1368 pixel widths as well, IIRC.

  • evanhevanh Posts: 15,694
    edited 2022-03-12 04:05

    Huh, you know you can free up a lump of cogRAM in your driver. Those two "interlaced" sync overlays are sitting in the initial ORG 0 section. They should really have their own ORGs.

    EDIT: Oh, nevermind. I see that space is the font cache.

  • evanhevanh Posts: 15,694
    edited 2022-03-12 05:32

    @rogloh said:
    My driver can go up to 1920x1200 at 60Hz with VGA.

    I can get the prop2 DVI output doing 1920x1200 :) But at only 15 Hz refresh. TV not happy. :( Best I can get displayed is 1920x768@24. Of course, with the native LCD res being lower, not all pixels are there anyway.

    EDIT: Actually, with a 16:9 aspect display, a 2:1 resolution looks nice. So something like 800x400 or 1024x512 or 1280x640 ... Hehe, I guess that means an 8x16 font still isn't tall enough when pixels are square.

  • evanhevanh Posts: 15,694
    edited 2022-03-13 11:24

    In my wandering about looking up EDID programming, I came across the odd disparaging comments like display drivers don't bother with much beyond the basics ...

    Well, having now decoded the data stored in my TV, I'm not surprised that drivers don't use much info from the devices. It just reads like a fixed set for the whole product range! There's no specifics that are correct for the model. :( The only info probably correct is the EDID supported standard and year of firmware revision.

    EDIT: I guess PC monitors will be better. After all, EDID was always a PC thing from the outset.

    The annoying part is my TV is really flexible timings wise. It just doesn't advertise it .... the craziest part is it even has an FD tagged "Range Limits" descriptor block defined. But the parameters are just not anything like reality. PS: They're not broken, they are a reasonable range. Just not what the TV can actually do.

    PPS: When I say it doesn't advertise it: There is a flag to say if it supports "continuous frequency" or not. And it ain't set.

  • I found this EDID decoder software in C that can display human readable EDID data, how good/accurate it is I'm not sure, but I extracted my own plasma TV EDID string after plugging it into my Mac and extracting the data. I've attached the source code for this program, you need to compile it then feed it the EDID hex string as file data.

    Once the monitor was connected, on my MAC I first extracted the EDID hex data string using this command, but I am not sure what command Windows/Linux would have to get it.
    ioreg -l | grep -5 IODisplayEDID

    Here's what it output...
    RLs-MacBook-Pro:edid roger$ ./edid-decode plasma.edid

    Extracted contents:
    header:          00 ff ff ff ff ff ff 00
    serial number:   1e 6d 01 00 01 01 01 01 01 15
    version:         01 03
    basic params:    80 10 09 78 0a
    chroma info:     ee 91 a3 54 4c 99 26 0f 50 54
    established:     a1 08 00
    standard:        71 4f 81 80 01 01 01 01 01 01 01 01 01 01 01 01
    descriptor 1:    02 3a 80 18 71 38 2d 40 58 2c 45 00 a0 5a 00 00 00 1e
    descriptor 2:    1b 21 50 a0 51 00 1e 30 48 88 35 00 a0 5a 00 00 00 1c
    descriptor 3:    00 00 00 fd 00 3a 3e 1e 53 10 00 0a 20 20 20 20 20 20
    descriptor 4:    00 00 00 fc 00 4c 47 20 54 56 0a 20 20 20 20 20 20 20
    extensions:      01
    checksum:        e2
    
    EDID version: 1.3
    Manufacturer: GSM Model 1 Serial Number 16843009
    Made in week 1 of 2011
    Digital display
    Maximum image size: 16 cm x 9 cm
    Gamma: 2.20
    RGB color display
    First detailed timing is preferred timing
    Display x,y Chromaticity:
      Red:   0.6396, 0.3300
      Green: 0.2998, 0.5996
      Blue:  0.1503, 0.0595
      White: 0.3125, 0.3291
    Established timings supported:
      720x400@70Hz 9:5 HorFreq: 31469 Hz Clock: 28.320 MHz
      640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
      800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz
      1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz
    Standard timings supported:
      1152x864@75Hz 4:3 HorFreq: 67500 Hz Clock: 108.000 MHz
      1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz
    Detailed mode: Clock 148.500 MHz, 160 mm x 90 mm
                   1920 2008 2052 2200 hborder 0
                   1080 1084 1089 1125 vborder 0
                   +hsync +vsync 
                   VertFreq: 60 Hz, HorFreq: 67500 Hz
    Detailed mode: Clock 84.750 MHz, 160 mm x 90 mm
                   1360 1432 1568 1776 hborder 0
                    768  771  776  798 vborder 0
                   -hsync +vsync 
                   VertFreq: 59 Hz, HorFreq: 47719 Hz
    Monitor ranges (GTF): 58-62Hz V, 30-83kHz H, max dotclock 160MHz
    Monitor name: LG TV
    Has 1 extension blocks
    Checksum: 0xe2 (valid)
    
    CTA extension block
    Extension version: 3
    51 bytes of CTA data
      Video data block
        VIC  16 1920x1080@60Hz 16:9  HorFreq: 67500 Hz Clock: 148.500 MHz
        VIC  31 1920x1080@50Hz 16:9  HorFreq: 56250 Hz Clock: 148.500 MHz
        VIC   4 1280x720@60Hz 16:9 (native) HorFreq: 45000 Hz Clock: 74.250 MHz
        VIC  19 1280x720@50Hz 16:9  HorFreq: 37500 Hz Clock: 74.250 MHz
        VIC   5 1920x1080i@60Hz 16:9  HorFreq: 33750 Hz Clock: 74.250 MHz
        VIC  20 1920x1080i@50Hz 16:9  HorFreq: 28125 Hz Clock: 74.250 MHz
        VIC   3 720x480@60Hz 16:9  HorFreq: 31469 Hz Clock: 27.000 MHz
        VIC   2 720x480@60Hz 4:3  HorFreq: 31469 Hz Clock: 27.000 MHz
        VIC  18 720x576@50Hz 16:9  HorFreq: 31250 Hz Clock: 27.000 MHz
        VIC  32 1920x1080@24Hz 16:9  HorFreq: 27000 Hz Clock: 74.250 MHz
        VIC  33 1920x1080@25Hz 16:9  HorFreq: 28125 Hz Clock: 74.250 MHz
        VIC  34 1920x1080@30Hz 16:9  HorFreq: 33750 Hz Clock: 74.250 MHz
        VIC  21 1440x576i@50Hz 4:3  HorFreq: 15625 Hz Clock: 27.000 MHz
        VIC   1 640x480@60Hz 4:3  HorFreq: 31469 Hz Clock: 25.175 MHz
      Audio data block
        AC-3, max channels 6
          Supported sample rates (kHz): 48 44.1 32
          Maximum bit rate: 640 kHz
        Linear PCM, max channels 2
          Supported sample rates (kHz): 192 96 48 44.1 32
          Supported sample sizes (bits): 24 20 16
      Vendor-specific data block, OUI 000c03 (HDMI)
        Source physical address 1.0.0.0
        Supports_AI
        DC_36bit
        DC_30bit
        DC_Y444
        Maximum TMDS clock: 225MHz
        Extended HDMI video details:
          3D present
          3D-capable-VIC mask present
          3D: Side-by-side (half, horizontal)
          3D: Top-and-bottom
          3D VIC indices: 2 3 4 5 9 11
          VIC index 0 supports side-by-side (half, horizontal)
          VIC index 1 supports side-by-side (half, horizontal)
          VIC index 9 supports side-by-side (half, horizontal)
          VIC index 5 supports side-by-side (half, horizontal)
          VIC index 3 supports side-by-side (half, horizontal)
      Extended tag: Colorimetry data block
        xvYCC601
        xvYCC709
    Underscans PC formats by default
    Basic audio support
    Supports YCbCr 4:4:4
    Supports YCbCr 4:2:2
    1 native detailed modes
    Detailed mode: Clock 74.250 MHz, 160 mm x 90 mm
                   1920 2008 2052 2200 hborder 0
                    540  542  547  562 vborder 0
                   +hsync +vsync interlaced 
                   VertFreq: 60 Hz, HorFreq: 33750 Hz
    Detailed mode: Clock 74.250 MHz, 160 mm x 90 mm
                   1280 1390 1430 1650 hborder 0
                    720  725  730  750 vborder 0
                   +hsync +vsync 
                   VertFreq: 60 Hz, HorFreq: 45000 Hz
    Detailed mode: Clock 148.500 MHz, 160 mm x 90 mm
                   1920 2008 2052 2200 hborder 0
                   1080 1084 1089 1125 vborder 0
                   +hsync +vsync 
                   VertFreq: 60 Hz, HorFreq: 67500 Hz
    Checksum: 0x31 (valid)
    
    One or more of the timings is out of range of the Monitor Ranges:
      Vertical Freq: 24 - 75 Hz
      Horizontal Freq: 15625 - 67500 Hz
      Maximum Clock: 148.500 MHz
    
  • evanhevanh Posts: 15,694
    edited 2022-03-13 11:58

    Ya, 160 mm x 90 mm is the sort of rubbish I'm seeing here too. And 58-62 Vfreq! That's stupid small range. I bet it's completely wrong and the monitor your TV can actually do a wide range.

    Oh, and the very end has a different set of limits:

      Vertical Freq: 24 - 75 Hz
      Horizontal Freq: 15625 - 67500 Hz
    

    That looks much more reasonable. I wonder how it found those.

  • evanhevanh Posts: 15,694

    @rogloh said:
    I found this EDID decoder software in C that can display human readable EDID data, how good/accurate it is I'm not sure, but I extracted my own plasma TV EDID string after plugging it into my Mac and extracting the data. I've attached the source code for this program, you need to compile it then feed it the EDID hex string as file data.

    Extracted contents:
    header:          00 ff ff ff ff ff ff 00
    serial number:   36 83 01 ee 01 01 01 01 01 14
    version:         01 03
    basic params:    80 a0 5a 78 0a
    chroma info:     0d c9 a0 57 47 98 27 12 48 4c
    established:     21 08 00
    standard:        81 80 01 01 01 01 01 01 01 01 01 01 01 01 01 01
    descriptor 1:    02 3a 80 18 71 38 2d 40 58 2c 45 00 40 84 63 00 00 1e
    descriptor 2:    01 1d 00 72 51 d0 1e 20 6e 28 55 00 40 84 63 00 00 1e
    descriptor 3:    00 00 00 fc 00 54 56 0a 20 20 20 20 20 20 20 20 20 20
    descriptor 4:    00 00 00 fd 00 30 3e 0e 46 0f 00 0a 20 20 20 20 20 20
    extensions:      01
    checksum:        f4
    
    EDID version: 1.3
    Manufacturer: MTC Model ee01 Serial Number 16843009
    Made in week 1 of 2010
    Digital display
    Maximum image size: 160 cm x 90 cm
    Gamma: 2.20
    RGB color display
    First detailed timing is preferred timing
    Display x,y Chromaticity:
      Red:   0.6250, 0.3398
      Green: 0.2802, 0.5947
      Blue:  0.1552, 0.0703
      White: 0.2832, 0.2978
    Established timings supported:
      640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
      800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz
      1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz
    Standard timings supported:
      1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz
    Detailed mode: Clock 148.500 MHz, 1600 mm x 900 mm
                   1920 2008 2052 2200 hborder 0
                   1080 1084 1089 1125 vborder 0
                   +hsync +vsync 
                   VertFreq: 60 Hz, HorFreq: 67500 Hz
    Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
                   1280 1390 1430 1650 hborder 0
                    720  725  730  750 vborder 0
                   +hsync +vsync 
                   VertFreq: 60 Hz, HorFreq: 45000 Hz
    Monitor name: TV
    Monitor ranges (GTF): 48-62Hz V, 14-70kHz H, max dotclock 150MHz
    Has 1 extension blocks
    Checksum: 0xf4 (valid)
    
    CTA extension block
    Extension version: 3
    40 bytes of CTA data
      Video data block
        VIC  31 1920x1080@50Hz 16:9  HorFreq: 56250 Hz Clock: 148.500 MHz
        VIC  16 1920x1080@60Hz 16:9  HorFreq: 67500 Hz Clock: 148.500 MHz
        VIC  20 1920x1080i@50Hz 16:9  HorFreq: 28125 Hz Clock: 74.250 MHz
        VIC   5 1920x1080i@60Hz 16:9  HorFreq: 33750 Hz Clock: 74.250 MHz
        VIC  19 1280x720@50Hz 16:9  HorFreq: 37500 Hz Clock: 74.250 MHz
        VIC   4 1280x720@60Hz 16:9  HorFreq: 45000 Hz Clock: 74.250 MHz
        VIC  18 720x576@50Hz 16:9  HorFreq: 31250 Hz Clock: 27.000 MHz
        VIC  17 720x576@50Hz 4:3  HorFreq: 31250 Hz Clock: 27.000 MHz
        VIC  22 1440x576i@50Hz 16:9  HorFreq: 15625 Hz Clock: 27.000 MHz
        VIC  21 1440x576i@50Hz 4:3  HorFreq: 15625 Hz Clock: 27.000 MHz
        VIC   3 720x480@60Hz 16:9  HorFreq: 31469 Hz Clock: 27.000 MHz
        VIC   2 720x480@60Hz 4:3  HorFreq: 31469 Hz Clock: 27.000 MHz
        VIC   7 1440x480i@60Hz 16:9  HorFreq: 15734 Hz Clock: 27.000 MHz
        VIC   6 1440x480i@60Hz 4:3  HorFreq: 15734 Hz Clock: 27.000 MHz
        VIC   1 640x480@60Hz 4:3  HorFreq: 31469 Hz Clock: 25.175 MHz
        VIC  32 1920x1080@24Hz 16:9  HorFreq: 27000 Hz Clock: 74.250 MHz
      Audio data block
        Linear PCM, max channels 2
          Supported sample rates (kHz): 48 44.1 32
          Supported sample sizes (bits): 24 20 16
        AC-3, max channels 6
          Supported sample rates (kHz): 48 44.1 32
          Maximum bit rate: 640 kHz
      Speaker allocation data block
        Speaker map:
          FL/FR - Front Left/Right
      Vendor-specific data block, OUI 000c03 (HDMI)
        Source physical address 1.0.0.0
        Supports_AI
        DC_36bit
        DC_30bit
        DC_Y444
        Maximum TMDS clock: 225MHz
      Extended tag: Video capability data block
        YCbCr quantization: No Data (0)
        RGB quantization: Selectable (via AVI Q) (1)
        PT scan behaviour: Support both over- and underscan (3)
        IT scan behaviour: Always Underscanned (2)
        CE scan behaviour: Support both over- and underscan (3)
    Underscans PC formats by default
    Basic audio support
    Supports YCbCr 4:4:4
    Supports YCbCr 4:2:2
    0 native detailed modes
    Detailed mode: Clock 148.500 MHz, 1600 mm x 900 mm
                   1920 2448 2492 2640 hborder 0
                   1080 1084 1089 1125 vborder 0
                   +hsync +vsync 
                   VertFreq: 50 Hz, HorFreq: 56250 Hz
    Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
                   1280 1720 1760 1980 hborder 0
                    720  725  730  750 vborder 0
                   +hsync +vsync 
                   VertFreq: 50 Hz, HorFreq: 37500 Hz
    Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
                   1920 2008 2052 2200 hborder 0
                    540  542  547  562 vborder 0
                   +hsync +vsync interlaced 
                   VertFreq: 60 Hz, HorFreq: 33750 Hz
    Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
                   1920 2448 2492 2640 hborder 0
                    540  542  547  562 vborder 0
                   +hsync +vsync interlaced 
                   VertFreq: 50 Hz, HorFreq: 28125 Hz
    Checksum: 0x1d (valid)
    
    One or more of the timings is out of range of the Monitor Ranges:
      Vertical Freq: 24 - 60 Hz
      Horizontal Freq: 15625 - 67500 Hz
      Maximum Clock: 148.500 MHz
    
  • evanhevanh Posts: 15,694
    edited 2022-03-13 12:35

    Different to what I found in the EDID but still wrong:

    One or more of the timings is out of range of the Monitor Ranges:
      Vertical Freq: 24 - 60 Hz
      Horizontal Freq: 15625 - 67500 Hz
      Maximum Clock: 148.500 MHz
    

    Max Vfreq is 75 Hz in reality.

  • evanhevanh Posts: 15,694
    edited 2022-03-13 12:27

    Oh, I wonder if that's the spread of ranges found in the various fixed modes. And it's reporting the spread as not fitting the spec'd limits. That would add up.

    EDIT: Yep, that's exactly it. It is comparing against the parameters found from an $FD tagged "Range Limits" descriptor block.

  • evanhevanh Posts: 15,694
    edited 2022-03-13 13:01

    So EDID is a write-off. ... or, I suppose EDID could be treated as a safe starting point. Like a recommended range.

  • Yeah, the limits in the EDID may not actually mean anything. The detailed resolutions are totally good to use as-is though. That's what PCs do (and you can force graphics cards to emit many wonderful custom modes like 720x540@160Hz by overriding EDID data in the registry)

  • evanhevanh Posts: 15,694
    edited 2022-03-13 22:19

    Obviously the common modes work. Don't need any data to tell me that. If the displays aren't going to be accurate about reporting their limits then EDID isn't of much value.

  • EDID: Everyone Does It Differently.
    Sorry. I’ll see myself out…

  • evanhevanh Posts: 15,694

    I need a silly giggle after that. :)

  • hinvhinv Posts: 1,255
    edited 2022-03-17 20:31

    @rogloh said:
    My driver can go up to 1920x1200 at 60Hz with VGA. It works on my Dell monitor at native resolution, but it needs a specific timing setup to sync right, only possible once I obtained it for that model from somewhere online.

    Is that a 2410F or some other model? What is your sysclock for that? How much time in % do you have per line and per flyback( I'm not sure what it is called on an LCD)

  • No it's a 2405FPW LCD model. I used 308MHz sysclock. Here's the timing I have for 1920x1200. Blanking interval is 160/(160+1920) or ~7.7% per scanline and 35/(1200+35) or ~2.8% per frame.

    wuxga_timing ' experimental 1920x1200@60Hz for Dell 2405FPW at 77*4 MHz YMMV
                long   CLK308MHz
                long   308000000
                       '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
                       '     1 bit         7 bits      8 bits      8 bits    8 bits
                long   (SYNC_POS<<31) | ( 48<<24) | ( 32<<16) | (80<<8 ) |(1920/8)
    
                       '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
                       '     1 bit         8 bits      3 bits      9 bits   11 bits
                long   (SYNC_NEG<<31) | (  3<<23) | (  6<<20) | ( 26<<11) | 1200
                long   2<<8
                long   0
                long   0   ' reserved for CFRQ parameter
    

    I also found a timing online that works cleanly at 1920x1080 @ 60Hz on this monitor too without pixel stretching or resampling. This is at a lower 277MHz sysclock.

    customtiming
                long    0 ‘ automatically setup clock 
                long    277000000
    
                       '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
                       '     1 bit         7 bits      8 bits      8 bits    8 bits
                long   (vid.SYNC_POS<<31) | ( 48<<24) | ( 32<<16) | ( 80 <<8 ) |(1920/8)
    
                       '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
                       '     8 bit         8 bits      3 bits      9 bits   11 bits
                long   (vid.SYNC_NEG<<31) | (  3<<23) | (  5<<20) | ( 23<<11) | 1080
                long   2<<8
                       '_Breezeway__C-Burst__FrontPorchHi__SyncWidthHi__BackPorchHi
                       '  8 bits     8 bits     8 bits        4 bits        4 bits
                long   0
                long   0   ‘ reserved for CFRQ parameter
    
  • evanhevanh Posts: 15,694
    edited 2022-03-19 04:20

    Roger,
    Time to clean up that structure:
    - As you know, I'm keen on the modeline timings becoming 16-bit per timing component.
    - The system clock mode value can be ditched completely now you've got the auto-generate code.
    - I'm also thinking the clock frequency should be removed too. Set it separately and then read clkfreq global in the driver. The only wobbly part about this is how to determine an appropriate SETXFRQ value for analogue video ports. Eric's driver relies on always having a layer of code like his text mode setup code to generate this for the driver.

    To complicate things with how the driver starts up, as I've recently discovered, the SETXFRQ concern doesn't apply to DVI/HDMI at all. Apart from the obvious fixed sysclock/10, the dot clock frequency isn't strongly specified to each video mode because the video resolution and dot clock don't have to be guessed at by the monitor/TV. The digital link naturally conveys these parameters exactly. As such, refresh rates and blankings can be wide ranging and thereby have no need for specific mode clock rates. So, setup approach becomes quite different.

    PS: To sum up: In both approaches, sysclock frequency is not specified by the video mode. Well, there is a minimum of 250 MHz for digital links but that's not a video mode limit. And I think it'd be ill advised to go smaller than sysclock/2 in any mode.

  • evanhevanh Posts: 15,694

    @evanh said:
    - I'm also thinking the clock frequency should be removed too. Set it separately and then read clkfreq global in the driver. The only wobbly part about this is how to determine an appropriate SETXFRQ value for analogue video ports. Eric's driver relies on always having a layer of code like his text mode setup code to generate this for the driver.

    What I'd like to do is have a specified refresh rate in the structure instead of the usual pixel rate. Then derive the pixel rate. A lot less divides this way.

  • @evanh said:
    Roger,
    Time to clean up that structure:
    - As you know, I'm keen on the modeline timings becoming 16-bit per timing component.
    - The system clock mode value can be ditched completely now you've got the auto-generate code.
    - I'm also thinking the clock frequency should be removed too. Set it separately and then read clkfreq global in the driver. The only wobbly part about this is how to determine an appropriate SETXFRQ value for analogue video ports. Eric's driver relies on always having a layer of code like his text mode setup code to generate this for the driver.

    To complicate things with how the driver starts up, as I've recently discovered, the SETXFRQ concern doesn't apply to DVI/HDMI at all. Apart from the obvious fixed sysclock/10, the dot clock frequency isn't strongly specified to each video mode because the video resolution and dot clock don't have to be guessed at by the monitor/TV. The digital link naturally conveys these parameters exactly. As such, refresh rates and blankings can be wide ranging and thereby have no need for specific mode clock rates. So, setup approach becomes quite different.

    PS: To sum up: In both approaches, sysclock frequency is not specified by the video mode. Well, there is a minimum of 250 MHz for digital links but that's not a video mode limit. And I think it'd be ill advised to go smaller than sysclock/2 in any mode.

    I'll have think about your suggestions as it's a lot of work to go change all this and test etc, and it affects every different output type as well. How big is this new timing structure going to be and how flexible is it? Do you have a proposed structure to show?

    We could remove the PLL clock mode parameter but I believe I've used the clock frequency of a video mode before I switch into it so it can control other things like memory driver timing etc. The PLL clock mode parameter is already optional but could be handy to have around if you need to finely manage it yourself for some reason. For the P2 beginners it is also handy to have the driver automatically setup the PLL in the stock video modes because you then don't need to worry about setting all this up in advance. Timing already gets complex enough.

    @evanh said:
    What I'd like to do is have a specified refresh rate in the structure instead of the usual pixel rate. Then derive the pixel rate. A lot less divides this way.

    Maybe we just need a tool that can take the refresh rate and auto generate the timing structure from that. I do already have an API that can customize a timing structure from some parameters. Maybe refresh rate could be another input, or just create another API to build the structure based on desired refresh rate and resolution... that might be better really.

  • evanhevanh Posts: 15,694
    edited 2022-03-19 08:32

    @rogloh said:
    How big is this new timing structure going to be and how flexible is it? Do you have a proposed structure to show?

    Nothing special. Just the simple parts I've listed.

            word    60    ' Vertical Frequency (Refresh Rate)
    
            word    1200    ' Vertical Visible
            word    3       ' Vertical Front Porch
            word    (vid.SYNC_NEG<<15) | 6   'bit15 is VSync Polarity, [14:0] is VSync Width
            word    26      ' Vertical Back Porch
    
            word    1920    ' Horizontal Visible
            word    48      ' Horizontal Front Porch
            word    (vid.SYNC_POS<<15) | 32   'bit15 is HSync Polarity, [14:0] is HSync Width
            word    80      ' Horizontal Back Porch
    
  • evanhevanh Posts: 15,694
    edited 2022-03-19 08:57

    @rogloh said:
    Maybe we just need a tool that can take the refresh rate and auto generate the timing structure from that. I do already have an API that can customize a timing structure from some parameters. Maybe refresh rate could be another input, or just create another API to build the structure based on desired refresh rate and resolution... that might be better really.

    The driver is already doing that in various ways. This structure is only used for passing parameters. It's not stored in the active display cogRAM. For example, each needed streamer component is picked from the structure and embedded into its relevant mode words.

    The interfacing spin code in the driver for embedding all those values can all be bolstered to perform different/alternative calculations.

  • evanhevanh Posts: 15,694
    edited 2022-03-19 11:34

    vtot = vvis + vfp + vs + vbp
    htot = hvis + hfp + hs + hbp
    pixelfreq = vfreq * vtot * htot
    SETXFRQ divider = $8000_0000 * pixelfreq / clkfreq

    Only a single divide! Pixel frequency would need to be capped to half of sysclock frequency. It's up to the user to make that fit.

    EDIT: I guess it's only one divide when using preset timings anyway. Where it does make a difference is when dynamically calculating the blanking times from a smaller set of parameters.

  • evanhevanh Posts: 15,694

    My old DVI monitor is funny when DVI linked. It is sort of fixated with supporting the old PC graphics modes. As in it doesn't like accepting much other than them. But it doesn't have any need of the old VGA timings for those modes so as long as the vfreq and resolution matches, then it'll display the image.

    Completely different story when plugged in with an analogue VGA cable though. Excepting the sync positions, deviate a few percent from the known timings and all bets are off.

  • evanhevanh Posts: 15,694
    edited 2022-03-19 13:50

    Ah, got it. With DVI link, excepting the old PC modes, max v-blanking is only 35 lines! That sucks. And h-res has to be in multiples of 16, but this is no issue. And, excepting the old PC modes again, an arbitrary minimum resolution of 450x450, I think, too. Practical min resolution with flexible timings is 464x450.

    So, it's not too fussy about the resolutions but is very fussy about v-blanking. That explains why, previously, the higher resolution modes all worked - because they generally defaulted to tight blankings. At least h-blanking seems to be more forgiving.

    Pity these limits aren't being specified in EDID.

Sign In or Register to comment.