Announcement

Collapse
No announcement yet.

EDID and KMS

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    what about setting the resolution on the kernel line in grub? It seems to only use the max supported by edid?

    Also is there a user space utility for reading edid? there used to be one that worked in 32bit mode called read-edid but it doesnt work in 64bit. Is there any plan for something similar that will work with KMS? It would be real nice to be able towrite a script that reads the monitors edid info and then set the resolution before X is even started...

    Comment


    • #12
      IIRC, you can get the edid info from sysfs. Unfortunately, there is not a lot you can do for the fb console at the moment since the kernel fb interface doesn't support multi-head cards. Right now the console comes up in the preferred mode of the monitor or a supported clone mode if multiple monitors are present.

      Comment


      • #13
        Does anyone know if there are plans to allow modesetting from userspace? I have an EDID in Magnavox 1080p HDTV reporting wrong dot clock. I took a look at drm_edid.c in kernel tree but it doesn't look like the quirks addressed there would fix my issue.

        Is there anywhere specific to report EDID quirks aside from the dev mailing lists?

        X is working fine with custom modeline but fbcon is borked with KMS.

        Here is the working X modeline:
        "1920x1080@59" 146.0 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

        And here is EDID data reported:
        Code:
        saturn:~# get-edid | parse-edid 
        parse-edid: parse-edid version 2.0.0
        get-edid: get-edid version 2.0.0
        
            Performing real mode VBE call
            Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
            Function supported
            Call successful
        
            VBE version 300
            VBE string at 0xc01d8 "ATI ATOMBIOS"
        
        VBE/DDC service about to be called
            Report DDC capabilities
        
            Performing real mode VBE call
            Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
            Function supported
            Call successful
        
            Monitor and video card combination does not support DDC1 transfers
            Monitor and video card combination supports DDC2 transfers
            0 seconds per 128 byte EDID block transfer
            Screen is not blanked during DDC transfer
        
        Reading next EDID block
        
        VBE/DDC service about to be called
            Read EDID
        
            Performing real mode VBE call
            Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
            Function supported
            Call successful
        
        EDID claims 1 more blocks left
        
        
        *********** Something special has happened!
        Please contact the author, Matthew Kern
        E-mail: pyrophobicman@gmail.com
        Please include full output from this program (especially that to stderr)
        
        
        
        Reading next EDID block
        
        VBE/DDC service about to be called
            Read EDID
        
            Performing real mode VBE call
            Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
            Function supported
            Call successful
        
        EDID claims 1 more blocks left
        EDID blocks left is wrong.
        Your EDID is probably invalid.
        parse-edid: EDID checksum passed.
        
            # EDID version 1 revision 3
        Section "Monitor"
            # Block type: 2:0 3:fc
            Identifier "MAGNAVOX TV"
            VendorName "PHL"
            ModelName "MAGNAVOX TV"
            # Block type: 2:0 3:fc
            # Block type: 2:0 3:fd
            HorizSync 30-75
            VertRefresh 56-62
            # Max dot clock (video bandwidth) 160 MHz
            # DPMS capabilities: Active off:no  Suspend:no  Standby:no
        
            Mode     "1920x1080"    # vfreq 60.000Hz, hfreq 67.500kHz
                DotClock    148.500000
                HTimings    1920 2008 2052 2200
                VTimings    1080 1084 1089 1125
                Flags    "+HSync" "+VSync"
            EndMode
            Mode     "1920x1080"    # vfreq 30.000Hz, hfreq 33.750kHz
                DotClock    74.250000
                HTimings    1920 2008 2052 2200
                VTimings    1080 1084 1089 1125
                Flags    "+HSync" "+VSync"
            EndMode
            # Block type: 2:0 3:fc
            # Block type: 2:0 3:fd
        EndSection
        
        Xorg:
        (II) RADEON(0): EDID for output HDMI-0
        (II) RADEON(0): Manufacturer: PHL  Model: d02a  Serial#: 16843009
        (II) RADEON(0): Year: 2007  Week: 14
        (II) RADEON(0): EDID Version: 1.3
        (II) RADEON(0): Digital Display Input
        (II) RADEON(0): Max Image Size [cm]: horiz.: 64  vert.: 36
        (II) RADEON(0): Gamma: 2.20
        (II) RADEON(0): No DPMS capabilities specified
        (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 
        (II) RADEON(0): First detailed timing is preferred mode
        (II) RADEON(0): redX: 0.632 redY: 0.324   greenX: 0.273 greenY: 0.591
        (II) RADEON(0): blueX: 0.144 blueY: 0.068   whiteX: 0.280 whiteY: 0.285
        (II) RADEON(0): Supported established timings:
        (II) RADEON(0): 640x480@60Hz
        (II) RADEON(0): 800x600@56Hz
        (II) RADEON(0): 800x600@60Hz
        (II) RADEON(0): 1024x768@60Hz
        (II) RADEON(0): Manufacturer's mask: 0
        (II) RADEON(0): Supported standard timings:
        (II) RADEON(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
        (II) RADEON(0): Supported detailed timing:
        (II) RADEON(0): clock: 148.5 MHz   Image Size:  640 x 360 mm
        (II) RADEON(0): h_active: 1920  h_sync: 2008  h_sync_end 2052 h_blank_end 2200 h_border: 0
        (II) RADEON(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 v_blanking: 1125 v_border: 0
        (II) RADEON(0): Supported detailed timing:
        (II) RADEON(0): clock: 74.2 MHz   Image Size:  640 x 360 mm
        (II) RADEON(0): h_active: 1920  h_sync: 2008  h_sync_end 2052 h_blank_end 2200 h_border: 0
        (II) RADEON(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 v_blanking: 1125 v_border: 0
        (II) RADEON(0): Monitor name: MAGNAVOX TV
        (II) RADEON(0): Ranges: V min: 56 V max: 62 Hz, H min: 30 H max: 75 kHz, PixClock max 160 MHz
        (II) RADEON(0): Number of EDID sections to follow: 1
        (II) RADEON(0): EDID (in hex):
        (II) RADEON(0):         00ffffffffffff00410c2ad001010101
        (II) RADEON(0):         0e110103804024780ac1eca153469724
        (II) RADEON(0):         11474923080081800101010101010101
        (II) RADEON(0):         010101010101023a801871382d40582c
        (II) RADEON(0):         450080682100001e011d801871382d40
        (II) RADEON(0):         582c450080682100001e000000fc004d
        (II) RADEON(0):         41474e41564f582054560a20000000fd
        (II) RADEON(0):         00383e1e4b10000a2020202020200117
        Working dot clock is 146.0 but EDID reports 148.5.

        Thanks in advance!

        Comment


        • #14
          What kernel are you using kms from?

          Comment


          • #15
            2.6.33-rc7 at the moment. Also (not that it matters for framebuffer) running Debian unstable with Xorg 1.7.4. DRM, Mesa, and xf86-video-ati from master.

            This is not a Radeon (RV620) specific issue. It also occurs with NVIDIA cards as well.

            I'm using this box for MythTV and X is working fine with tear free Xv. fbcon isn't a big deal for me... just a little annoying when booting or troubleshooting with overscan on console.

            Would you recommend an email to kernel dev responsible for EDID quirks? Or is there a mechanism in the works for manual modes specified via kernel parm?

            Comment


            • #16
              Originally posted by amphigory View Post
              Would you recommend an email to kernel dev responsible for EDID quirks? Or is there a mechanism in the works for manual modes specified via kernel parm?
              Yes send an email to dri-devel and file a bug on https://bugs.freedesktop.org

              Comment


              • #17
                Thanks! I posted here to see if anyone had a workaround or if my reasoning was unsound. I didn't want to needlessly distract kernel gods from pondering imponderables in the forest of source trees on Mount Olympus.

                Comment

                Working...
                X