Created attachment 34198 [details]
Xorg.0.log

Created attachment 34199 [details]
dmesg (drm.debug=0x04)

Created attachment 34200 [details]
intel_reg_dumper

Created attachment 34201 [details]
vbios.dump

Created attachment 34202 [details]
xrandr (verbose)

Hi, 
    From the LVDS EDID info it seems that it can parse the following display mode:
    >  "1280x800"      # vfreq 59.996Hz, hfreq 48.597kHz
                DotClock        65.800000
                HTimings        1280 1292 1322 1354
                VTimings        800 803 806 810
                Flags   "-HSync" "-VSync"
    
     At the same time we can get the following panel info from the VBT info.
    > panel type 13: 1280x800 clock 65800000
                info:
                  LVDS: 0x42300300
                  PP_ON_DELAYS: 0x025807d0
                  PP_OFF_DELAYS: 0x01f407d0
                  PP_DIVISOR: 0x00270f05
                  PFIT: 0x20000000
                timings: 1280 1292 1322 1354 800 803 806 810 65800.00 (good)


     From the above info it seems that the LVDS panel limit is 1280x800. In such case we can't get the resolution of "1360x768".

Thanks.
   Yakui

Hi,
It isn't 1280x800[1]. Also, I already used it at 1366x768 (or maybe 1360x768, I don't remember) with linux and a nvidia card (I remember I had to google a bit and modify something in xorg.conf) and with a friend's laptop with Windows Vista (I don't remember the graphic card, but it was nvidia or ati).

[1]http://www.avmagazine.it/news/televisori/lcd-concept-loewe-hd-ready_265.html

Created attachment 34305 [details] [review]
try the debug patch that dump EDID info

Hi, 
   From the EDID for HDMI we can get the following display modes:
    >Modeline 45:"1280x720" 50 74250 1280 1720 1760 1980 720 725 730 750 0x48 0x5
    >Modeline 47:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
    >Modeline 44:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
    >Modeline 43:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
    >Modeline 49:"720x576" 50 27000 720 732 796 864 576 581 586 625 0x40 0xa
    >Modeline 48:"720x480" 60 27000 720 736 798 858 480 489 495 525 0x40 0xa

   Unfortunately the mode of 1360x768 is not found.
   
   Will you please try the attached debug patch and attach the output of dmesg?

Thanks.

Here it is. I attached also a snip of /var/log/messages because dmesg output was truncated.

Cheers,
Darkbasic

Created attachment 34324 [details]
dmesg-dump_edid_mode (drm.debug=0x04)

Created attachment 34325 [details]
messages-dump_edid_mode (drm.debug=0x04)

Hi, 
    Thanks for the info.
    From the EDID info it seems that we still can't get the display mode of "1360x768" from the EDID. Even when I look at the video block in extensional EDID block, the display mode of "1360x768" can't be found. 

    As we rely on the EDID to get the display mode, I have no idea why the ATI/NV can get the display mode of 1366x768 for this monitor.
    Can you have an opportunity to try windows on this box and see whether the display mode of "1366x768" can be recognized?

thanks.

I will try again with the laptop I already used and tell you exactly which resolution it uses (if 1366x768 or 1360x768 and which rate) and the video card it has.

Thank you

Here are the resolutions I found with windows and an nvidia card:

http://darkbasic.homelinux.com/1360_resolutions.jpg

1360x768 works flawlessly with vista and nvidia.

I"m just curious - the xorg.log shows it's LVDS. Is it a all-in-one machine? How did you test with a Nv card?

>                   _*LVDS*_: 0x42300300
>                   PP_ON_DELAYS: 0x025807d0
>                   PP_OFF_DELAYS: 0x01f407d0
>                   PP_DIVISOR: 0x00270f05
>                   PFIT: 0x20000000
>                 timings: 1280 1292 1322 1354 800 803 806 810 65800.00 (good)
> 
> 
>      From the above info it seems that the _*LVDS*_ panel limit is 1280x800. In
> such case we can't get the resolution of "1360x768".

I didn't notice he was talking about LVDS! Maybe he wanted to write HDMI instead?

Laptop's monitor is 1280x800 indeed, but I can get higher resolutions with HDMI (like 1920x1200@50Hz, only 2560x1600 does not work). If the resolution is higher than LVDS I can't mirror it, but it's quite obvious.

> I didn't notice he was talking about LVDS! Maybe he wanted to write HDMI
> instead?

At first I thought that you expected the 1366x768 display mode for LVDS. Then I realized that you were talking about the external display device.

From the dmesg log in comment #10 we get the corresponding EDID for the external HDMI device. But unfortunately from the contained EDID info we can get the following display mode. But unfortunately the display mode of 1366x768 can't be found.
    >1280x720@ 60Hz
    >1280x720@ 50Hz
    >1920x1080i@ 60Hz/50Hz: This is removed as the interlace is not supported.
    >1024x768@ 60Hz
    >800x600@ 60Hz
    >720x576@ 50 
    >720x480@ 60

> Laptop's monitor is 1280x800 indeed, but I can get higher resolutions with HDMI
> (like 1920x1200@50Hz, only 2560x1600 does not work). If the resolution is
> higher than LVDS I can't mirror it, but it's quite obvious.

Why does it work on Windows?
Shouldn't be possible to bypass the edid and simply force the resolution?
With my 2560x1600 main monitor it doesn't even recognize 1920x1200@50Hz and I have to create the modeset, but then it works.

So you can't use xrandr to create a 1360x768 or 1366x768 mode and then use it?  That usually works...

No, it doesn't work...
If you need some more logs please let me know, I still did not solved it.

When I force the signal to 1366x768 (HDMI), I get a black screen. For me it's not clear what should be the best xorg.conf configuration for intel drivers but here is mine.

Section "ServerLayout"
        Identifier      "Default Layout"
        Screen          "TV"
EndSection

Section "Device"
        Identifier      "Intel HD Graphics"
        Driver          "intel"
        BusID           "PCI:0:2:0"
        Option          "monitor-HDMI2" "TSB-TV"
        #Option          "ForceSDVODetect" "on"
        #Option         "UseEdidFreqs" "FALSE"
        #Option         "UseEDIDDpi" "FALSE"
        #Option         "IgnoreEDID" "1"
        #Option         "ModeValidation" "NoEdidModes"
        Option          "ConnectedMonitor"      "TSB-TV"
        #R Option          "CustomEDID"            "TSB-TV:/etc/X11/TSB0103.bin"
        Option         "ModeDebug" "true"
EndSection

Section "Monitor"
        Identifier      "TSB-TV"
        VendorName      "Toshiba"
        ModelName       "42WLG66"
        Option          "Enable"  "true"
        Modeline "1920x1080i"   74.25  1920 2448 2492 2640  1080 1084 1094 1125 interlace +hsync +vsync
        Modeline "1920x1080i_28.00"  73.79  1920 1968 2160 2400  1080 1081 1084 1098 interlace -HSync +Vsync
       Modeline "1368x768_60.00"  85.86  1368 1440 1584 1800  768 769 772 795  -HSync +Vsync
       Modeline "1280x720_50.0"   74.25  1280 1720 1760 1980  720 725 730 750 +hsync +vsync
       Option "PreferredMode"  "1368x768_60.00"
#        HorizSync 15.0 - 46.0
#        VertRefresh 49.0 - 122.0
EndSection

Section "Monitor"
        Identifier      "VGA1"
        Option          "Ignore" "true"
EndSection

Section "Screen"
        Identifier      "TV"
        Device          "Intel HD Graphics"
        Monitor         "TSB-TV"
        DefaultDepth  24
        SubSection "Display"
                Depth          24              
                Modes         "1920x1080i" "1920x1080i_28.00" "1366x768" "1280x720_50.0"
                Virtual         1920 1080
        EndSubSection
EndSection

Unfortunately the issue is still alive and kicking :(
I have another 1366x768 monitor (an LG 22LH2000) and it works flawlessly, the Loewe still doesn't work. With nvidia binary drivers it works flawlessly!


P.S.
I don't have a single nvidia card anymore to test it thanks to their anti open source strategy.

Well, this is a case of some random board manufacturer connecting something ugly to the lvds port ... the driver currrently enforces that lvds out always uses the fixed timing provided by the bios in the vbt. If you're bored, you could crawl around in intel_lvds.c and add a quirk table entry/function like for no_lvds that disables that intel_lvds->fixed_mode checking and fixup (and also the use of the panel fitter).

I'm way too snowed under, so don't count on me doing that :( Also, it's easier if you have the b0rked hw at hand ...

[ps: If you want to do this and get stuck somewhere, annoy us on #intel-gfx ...]

Uhm, why LVDS? Does my laptop use some kind of LVDS->HDMI adapter? The output is called HDMI1 in xrandr.

P.S.
My laptop is a Samsung X360.

Oops, indeed I've mixed things up - two many bug reports to shuffle ;-)

Looking at your xrandr --verbose output I _do_ see that we seem to detect two 1360x768 modes for your HDMI connector. Do they not work when you try to set them with xrandr? Or is that xrandr output from a different card?

I manually created both, but they don't work with the Loewe (with the LG they work flawlessly).

Ok, so I've looked at the dmesg output and there's simply no higher resolution progressive mode in there (well, higher than 1280x720). But there is an interlaced mode being announced, so I suspect that's actually what you've been running on other hw. But current i915 kernels simply don't support interlaced.

But you're lucky and I've just recently fixed this up, so can you please try the interlaced branch from my kernel repo at:

http://cgit.freedesktop.org/~danvet/drm/

That should give you a nice high-res hdmi output.

I'm not so lucky, with your interlaced branch it does see two new modes (1920x1080 @25Hz and @30Hz) but there is so much flickering that they are simply unusable. There is no 1360x768 mode, I tried to create an interlaced one @30Hz but it doesn't work. With the nvidia at the 1360x768 resolution I remember it was perfect, no flickering and an awesome quality (it didn't seem "scaled" like @1280x720).

Well, the thing is that afaik your edid doesn't contain that mode. And I have no idea where the nvidia blob got it from ...

About the interlaced patches not working nicely: Can you please describe the flicker? Maybe upload a video if that can show it?

> the thing is that afaik your edid doesn't contain that mode

Maybe, but I manually created a 1360x768 interlaced mode and it doesn't work, how do you explain that?

> Maybe upload a video if that can show it?

I will.

On Fri, Feb 10, 2012 at 22:20,  <bugzilla-daemon@freedesktop.org> wrote:
> Maybe, but I manually created a 1360x768 interlaced mode and it doesn't work, how do you explain that?

I suspect that nvidia uses the 1080i mode and upscales the lower
progressive mode to that. Another possibility is that your display
uses the cea block to announce this mode. Kernel 3.3 gained support
for that, I suggest you use the drm-intel-next branch from

http://cgit.freedesktop.org/~danvet/drm-intel/

that now also contains the interlaced support with one additional
bugfix. If this kernel detects new modelines, please attach the output
of xrandr.

http://files.linuxsystems.it/temp/2012-02/loewe_1080i_1.mp4
http://files.linuxsystems.it/temp/2012-02/loewe_1080i_2.mp4
http://files.linuxsystems.it/temp/2012-02/loewe_1080i_3.mp4

Unfortunately it doesn't show it very well, but for comparison you can see a video of my laptop:
http://files.linuxsystems.it/temp/2012-02/laptop.mp4

I'm going to try drm-next...

Your drm-intel-next branch does not recognize 1080i, are you sure it does support interlaced mode?
There isn't any new mode anyway.

> --- Comment #33 from darkbasic <darkbasic@linuxsystems.it> 2012-02-10 17:58:40 PST ---
> Your drm-intel-next branch does not recognize 1080i, are you sure it does support interlaced mode?
> There isn't any new mode anyway.

Oops, sorry, too many branches. I'd like you to test drm-intel-next-queued
from the same git repo. Current -next does indeed not yet recongize the
interlaced modes, and it also does not parse the cea extension block.

WOW I just discovered there is a brand new CRYPTO_SERPENT_SSE2_X86_64 in linux-3.3, I do use serpent to encrypt the whole root partition, that's a great news!

evdev does not work with this kernel (even after recompiling against it) :(
Unfortunately I will not be able to test something else before 20/02/2012 because I will be away.

I'm back, no new modes and same terrible quality @1080i with drm-intel-next-queued.

Created attachment 59354 [details] [review]
fixup sdvo timing stuff for hdmi outputs

Shot in the dark, maybe that helps. Btw I've noticed that your dmesg doesn't contain all the messages from the boot. Can you boot again with drm.debug=0xe and ensure that you grab the entire thing (including the very first boot messages)?

Created attachment 59368 [details]
dmesg 3.4-rc1 + handle-input-output-sdvo-timings-separately drm.debug=0xe

Awesome, I just discovered I can't adjust the screen brightness anymore with 3.4-rc1, is it possible there is no kernel upgrade without at least one serious regression for my laptop? :(

Unfortunately your patch (on top of 3.4-rc1) doesn't work, I attached full dmesg with drm.debug=0xe (~1MB O_O)

Well, now with the complete dmesg I could have told you right away that the patch won't change anything for you, sorry for any false hopes.

For the backlight issue, please run a bisect and file a bug on kernel bugzilla (or yell around on lkml, that might help). Usually the culprit is your platform's backlight driver, not drm/i915.

No problem, I lost any hope for this laptop since the switch to KMS. Everything worked flawlessly in the UMS era, now when something suddenly starts working properly at least two more things break. I'm sorry for the previous dmesg, I didn't notice it was trunked.

Regarding the backlight issue i915 isn't the one to blame, instead samsung_laptop is a well known son of a bitch (with very few hopes to get a fix).

I'm already saving some money to buy a Vaio Z-series when Haswell goes out, hopefully this nightmare will end in no more than a year.

I've looked again at your videos and this is very ugly - somehow your screen effectively switches between the two fields instead of interleaving them.

The laptop video, was that from the same screen, but at the right resolution (i.e. 1366x768)?

No, the laptop video was (as the name states) from my laptop's screen (at the right resolution which is 1280x800). I did it just to show that the terrible quality on the Loewe videos isn't due to a bad camera.

Ok, we've again fixed tons of hdmi bugs and additionally added some code to add more default modes (with a 16:9 and 16:10 aspect ratio). All these patches are merged for 3.5 in Linus' git tree already. Can you please test what happens if you run that? It should give you at least the mode you want with xrandr ...

Thanks, I will test it as soon as -rc1 gets released (I have lots of things to test in 3.5 and I prefer to keep track of the snapshot).

Nothing, it still doesn't detect 1360x768 and 1080i still sucks. Also, if I manually create the 1360x768 mode it doesn't work.

Anyway I found something in dmesg:

[   91.575032] Monitor-Mwait will be used to enter C-3 state
[   91.673302] ata1.00: configured for UDMA/133
[   91.673308] ata1: EH complete
[   91.673474] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   92.111583] EXT4-fs (dm-1): re-mounted. Opts: commit=600
[   92.928891] EXT4-fs (dm-1): re-mounted. Opts: commit=600
[  187.225883] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 121
[  187.225886] Raw EDID:
[  187.225889]          00 ff ff ff ff ff ff 00 31 e5 11 f4 01 01 01 01
[  187.225891]          00 ff 01 03 80 07 04 78 0a 0d c9 a0 57 47 98 27
[  187.225893]          12 48 4c 01 08 00 01 01 01 01 01 01 01 01 01 01
[  187.225894]          01 01 01 01 01 01 01 1d 00 bc 52 d0 1e 20 b8 28
[  187.225896]          55 40 bc 8a 21 00 00 1e 01 1d 80 d0 72 1c 16 20
[  187.225898]          10 2c 25 80 bc 8a 21 00 00 9e 00 00 00 fc 00 4c
[  187.225900]          4f 45 57 45 20 48 44 4d 49 20 54 56 00 00 00 fd
[  187.225902]          00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.252964] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 175
[  187.252966] Raw EDID:
[  187.252968]          00 ff ff ff ff ff ff 00 31 e5 11 f4 01 01 01 01
[  187.252971]          00 ff 01 03 80 07 04 78 0a 0d c9 a0 57 47 98 27
[  187.252973]          12 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.252975]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.252977]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.252979]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.252981]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.252983]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.279993] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 219
[  187.279995] Raw EDID:
[  187.279997]          00 ff ff ff ff ff ff 00 31 e5 11 f4 01 01 01 01
[  187.279999]          00 ff 01 03 80 07 04 78 0a 0d c9 a0 57 47 ff ff
[  187.280013]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.280024]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.280027]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.280029]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.280031]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.280033]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.306993] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 233
[  187.306995] Raw EDID:
[  187.306997]          00 ff ff ff ff ff ff 00 31 e5 11 f4 01 01 01 01
[  187.306998]          00 ff 01 03 80 07 04 78 0a 0d c9 a0 57 47 98 27
[  187.307012]          12 48 4c 01 08 00 01 01 01 01 01 01 01 01 01 01
[  187.307024]          01 01 01 01 01 01 01 1d 00 bc 52 d0 1e 20 b8 28
[  187.307026]          55 40 bc 8a 21 00 00 1e 01 1d 80 d0 72 1c 16 20
[  187.307028]          10 2c 25 80 bc 8a 21 00 00 9e 07 ff ff ff ff ff
[  187.307030]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.307032]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  187.307038] i915 0000:00:02.0: HDMI-A-1: EDID block 0 invalid.
[  509.534395] ata1.00: configured for UDMA/133
[  509.534400] ata1: EH complete
[  509.534593] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  511.098539] EXT4-fs (dm-1): re-mounted. Opts: commit=0
[  511.158098] EXT4-fs (dm-1): re-mounted. Opts: commit=0

Hm, we seem to have an extrem hard time reading the edid. And I've looked through older kernels, and the same problem persists there, too. Have you noticed that (i.e. xrandr would take ages and sometimes not return the edid ...)?

Another thing: Can you please attach the raw edid for your hdmi screen. You can find it in

/sys/class/drm/card0/card0-HDMI-1/edid

(or slightly different numbers, depending up on you're hw).

Created attachment 62729 [details]
loewe edid

Attached.

xrandr doesn't take ages, it's quite fast instead.


Another thing: gmbus still doesn't work :(

[  364.956293] [drm] GMBUS [i915 gmbus dpc] timed out, falling back to bit banging on pin 4

It seems we are none the wiser. Does the bug still persist with recent kernels (upstream and drm-intel-next-queued)?

I'd say this bug got fixed by Takashi's patch:
drm/edid: Add a workaround for 1366x768 HD panel
commit id c09dedb7a

Let's just close this bug for now. Feel free to reopen if the issue persist after tested with newer Kernel.

3.8-rc5, still not fixed

So indeed, nothing in the EDID leads to believe the panel supports 1360x768. Apparently a lot of "720p" panels are actually 1360x768 natively. Maybe we should just add this mode under specific conditions. I also found:

https://groups.google.com/forum/#!searchin/linux-sunxi/1360/linux-sunxi/oGa0L2T0jiY/6lOyRpXH6PgJ

Damien seems to be eager to be Mr. EDID ;-)

Could you try these modes?

The first one comes from the DMT standard. More exactly it could be that this TV actually has DisplayID (!) and a VESA timing block. That's my current best guess :)

{MODEPREFIX, 85500, 1360, 1424, 1536, 1792, 0, 768, 771, 777, 795, 0, V_PHSYNC | V_PVSYNC, MODESUFFIX},

The other try is a random guess from the Internet when trying to look for your monitor's brand

"1360x768" 72,050 1360 1408 1440 1520 768 771 776 790 -hsync -vsync

Note that the DisplayID theory would also explain that it worked with UMS, the xserver has code to decode the VESA timings block.

Timeout. Please reopen if the problem persists with recent kernels.

Closing after 2 years timeout.