Hi, This is git as of 87345e820d20f1a98216c52e156c2e18c15ffa44 I've connected an intel mac mini with a Panasonic PT AX-100E LCD beamer. While this worked fine using the analog cable (either with a 1280x768 or a 1280x720 resolution) using the digital signal with a DVI to HDMI adapter doesn't work for high resolutions. 1024x768 and lower resolutions are fine while higher (1280 x XY) resolutions don't display any image. Looking at the log the calculated vert refresh rate seems to be wrong since it's always zero: For the 1280x768 mode: (II) intel(0): Modeline "1280x768"x0.0 80.14 1280 1344 1480 1680 768 769 772 795 (47.7 kHz) (II) intel(0): Adjusted mode for pipe A: (II) intel(0): Modeline "1280x768"x0.0 80.14 1280 1344 1480 1680 768 769 772 795 (47.7 kHz) chosen: dotclock 160457 vco 1604571 ((m 117, m1 20, m2 5), n 5, (p 10, p1 1, p2 10)) and for the 1280x720 mode (handcrafted modeline in xorg.conf): (II) intel(0): Modeline "1280x720"x0.0 76.50 1280 1340 1620 1688 720 731 738 757 (45.3 kHz) (II) intel(0): Adjusted mode for pipe A: (II) intel(0): Modeline "1280x720"x0.0 76.50 1280 1340 1620 1688 720 731 738 757 (45.3 kHz) chosen: dotclock 153600 vco 1536000 ((m 80, m1 12, m2 8), n 3, (p 10, p1 1, p2 10)) The x0.0 looks like a driver bug. The log of driver version 2.1.1 says further down for these two modes: (EE) intel(0): I830 Vblank Pipe Setup Failed 0 (EE) intel(0): I830 Vblank Pipe Setup Failed 0 but this error message is gone in git. Everything looks o.k. for 1024x768. xorg.conf and logfiles for 1280x720 are attached.
Created attachment 12274 [details] xorg.conf
Created attachment 12275 [details] Xorg.0.log
As you can see from the Xorg.0.log file the vert refresh rates look o.k. now in git but there's still now picture.
Sounds like it might be bad EDID data, updating summary
The video modes queried via EDID are certainly way off - the only mode queried has a resolution 1920x540 while the projector only supports 1280x720. The frequencies look rather weird too: Edid says: Ranges: V min: 24 V max: 61 Hz, H min: 28 H max: 49 kHz, PixClock max 150 MHz While the documentation says: HorizSync 16-70 kHz VertRefresh 50-80 Hz Option "MinClock" "24000" Option "MaxClock" "120000" I tried setting these in xorg.conf but it seems at least the dotclock seems to be ignored. The dotclock for the 1280x Modes is > 150MHz, the dotclock for the 1028x768 Mode (which works) is 140Mhz, maybe that's just too high. The above Minclock/MaxClock settings don't seem to have any effect.
have you tried if 2.2.0 driver can fix your issue?
Would you please: 1. attach the xorg.log using analog cable with your monitor (with option ModeDebug turned on). I want to see if the EDID data probed with analog cable is the same with the DVI one. 2. can you try a reduced blanking mode for 1280x768 (you can calculate it with #cvt -r 1280 768 and use xrandr to add this mode) to see if it is really the pixclock issue (reduced blanking mode requires lower pixclock).
The problem is still present in 2.2.0 as well as current git HEAD.
The reduced blanking mode: "1280x768R" 68.00 1280 1328 1360 1440 768 771 781 790 +hsync -vsync selected via: xrandr --output TMDS-1 --mode 1280x768R -d :0 doesn't show a picture either.
Created attachment 13000 [details] Logfile with analog cable logfile with the analog cable instead of the HDMI/DVI adaptor
(In reply to comment #10) > Created an attachment (id=13000) [details] > Logfile with analog cable > > logfile with the analog cable instead of the HDMI/DVI adaptor > Hi, Guido Sorry for the long latency... When you say analog cable, you are using DVI->VGA cable? And the only output on mac mini is DVI? When using analog cable, from the log I've seen both VGA and TMDS-1 output are active. If DVI port is your only output, then only one should be active, either TMDS-1 with DVI->VGA cable or VGA with external display connected directly to the VGA port of your pc if exists. While using DVI->HDMI cable, only TMDS-1 is active. Following is a small test patch to enable VGA output on your machine, Would you please have a try? Thanks, Hong diff --git a/src/i830_crt.c b/src/i830_crt.c index 82a774a..57a5782 100644 --- a/src/i830_crt.c +++ b/src/i830_crt.c @@ -381,6 +381,8 @@ i830_crt_detect(xf86OutputPtr output) out: i830ReleaseLoadDetectPipe (output, dpms_mode); + /* just for test: always enable CRT output */ + status = XF86OutputStatusConnected; return status; }
The mac mini only has a single DVI as video output. Apple provides an adaptor to VGA. This is what I'm using when speaking of the analog cable. When running with DVI you simply remove the adaptor and plug in the the DVI cable as is (in my case I'm using a DVI to HDMI converter cable then). You attached patch doesn't change anything. Please note that for 1024x768 and below everything works fine, it's the larger resoultions that cause the trouble. Cheers, -- Guido
(In reply to comment #12) > The mac mini only has a single DVI as video output. Apple provides an adaptor > to VGA. This is what I'm using when speaking of the analog cable. When running OK, then logfile with analog cable is weird. (II) intel(0): Output VGA connected (II) intel(0): Output TMDS-1 connected Our driver detected two outputs are active, the VGA port (which is not existed on your machine) and the DVI output. Also when setting the mode on TMDS-1 output, we get "not supported" (II) intel(0): SDVO: W: 16 E2 1D 00 98 51 D0 25 20 (SDVO_CMD_SET_OUTPUT_TIMINGS_PART1) (II) intel(0): SDVO: R: (Not supported) Would you please ignore the VGA output and then try the analog cable to see if everything is OK. You can add Option "Monitor-VGA" "VGA" to Device section and and a new monitor section to disable VGA output. Section "Monitor" Identifier "VGA" Option "ignore" "true" EndSection Thanks, Hong
Sure. We now have (when using the analog cable): (II) intel(0): Output VGA using monitor section VGA (**) intel(0): Option "Ignore" "true" (II) intel(0): Output LVDS using monitor section TMDS-1 (**) intel(0): Option "PreferredMode" "1024x768" ... (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A (II) intel(0): Output TV is connected to pipe none
Guido, do you have chance to try this Mac on another LCD display with DVI port?
Sure. I do have a HP 2207h LCD Display connected via the very same DVI<->HDMI converter since several months now. It's working nicely (besides the fact that switching to the console only gives a blank screen - but that's a completely different issue).
(In reply to comment #16) > Sure. I do have a HP 2207h LCD Display connected via the very same DVI<->HDMI > converter since several months now. It's working nicely (besides the fact that > switching to the console only gives a blank screen - but that's a completely > different issue). > Guido, it sounds like an issue related with your beamer. Do you have another PC with DVI or HDMI port to try with this beamer? (In reply to comment #9) > The reduced blanking mode: > "1280x768R" 68.00 1280 1328 1360 1440 768 771 781 790 +hsync -vsync > selected via: > xrandr --output TMDS-1 --mode 1280x768R -d :0 > doesn't show a picture either. > Hong, Is this modeline correct?
I don't think it's the beamer by itself since I remember running it in high resolution under OS X once (don't have that around anymore, sorry). The german computer magazine c't once mentioned that the PT AX-100E is very sensitive to the modeline settings with HDMI so it might just be that the auto probed modeline is bogus as are the ones I tried. Nevertheless it does work with other operating systems, so the beamer by itself should be o.k. so it looks like an xorg driver issue to me.
ok. Hong, will you latest change to SDVO help on this bug? could you point Guido the patch to test? thanks.
(In reply to comment #19) > ok. Hong, will you latest change to SDVO help on this bug? could you point > Guido the patch to test? thanks. > Guido, it's the fix in bug# 15766 c# 27. The patch has been commited on 4th, June. Have you get a chance to try a new driver after that date? thanks.
ping for response...
...will be about two weeks until I'll have the hardware to test this.
ping again...
I tried 2.4.2 (from Debian experimental) - it still doesn't work. 1024x768 is still fine. Switching to: * 1152x864: blank screen * 1280x720 (with custom modeline): blank screen * 1280x768 disappeared completely from the list of available modes I'll attach an up to date xorg.log. Sorry for the late reply, I'm back near the hardeare now and would still love to run it in 1280x720 so turn around cycles should be much quicker again.
Created attachment 18822 [details] Xorg.0.log switching to 1152x864
how about the patch in bug#16515c#33?
I don't see how this is related. I'm not having generic display problems - only some specific hires don't display. The patch doesn't seem to do anything in this area. But if you confirm this could be related I'll give it a try.
Zhenyu, does your recent patch for DVI-I in 2.5 release help here?
Guido, please remove the Ignore CRT option, retest lastest Debian or 2.5 driver in git, and attach your log with ModeDebug turns on. Current driver should be able to detect your VGA as disconnected now. The problem is your DVI port should use VGA DDC to get the modes ( Mac's HW design determins ). thanks.
Will do. This might be a couple of weeks though since the device is in for repair at the moment.
Tried that but it's getting even worse: * most of the time when starting X I get: (EE) intel(0): underrun on pipe A! (EE) intel(0): underrun on pipe A! * after these you have to reboot (reloading the module isn't an option since the i915 module stays in use) * disabling 'Option"Monitor-VGA" "VGA"' dosn't change anything in that respect * now the driver doesn't even detect any sane 1280x7* modes anymore * using the custom modeline (which works for analog) doesn't help either * it still doesn't seem to parse any edid extension blocks, which would probably help a lot for HDMI modes I've attached the Xorg.0.log as requested. Thanks for trying to help but I'll tick to 1024x768 for the now and replace video by something non intel'ish soon since this didn't make any progress in the last year. Thanks again, -- Guido
Created attachment 20834 [details] Xorg log with 2.5.1
assigned to Ma Ling
seems like the correct timing might be 1280x720 74.25 1280 1319 1367 1648 720 724 729 750 http://web.telia.com/~u45802574/ce/reviews/PT-AX100E.html does it work?
Created attachment 26886 [details] please try the debug patch against latest 2 driver, thanks a lot.
Created attachment 26887 [details] plese use this one to replace last one patch against latest driver, thanks
(In reply to comment #34) > seems like the correct timing might be > 1280x720 74.25 1280 1319 1367 1648 720 724 729 750 > http://web.telia.com/~u45802574/ce/reviews/PT-AX100E.html > does it work? ping ~
mark as worksforme since no user response since comment# 34... please reopen if it doesn't work for you.
This is still an issue. I just didn't get around to test with that exact chipset yet. However the given modeline shows a picture on a GM45 chipset althoug, the picture is has just a far too strung red component so it's barely readable.
(In reply to comment #39) > This is still an issue. I just didn't get around to test with that exact > chipset yet. However the given modeline shows a picture on a GM45 chipset > althoug, the picture is has just a far too strung red component so it's barely > readable. > I'm confused. isn't you are using a Mac? Do you move to a new platform now? The issue on the GM45 based platform should be opened as another bug.. Do you also connect your PXA beamer to it? I wish we can get user's update in time to help us prioritize bug fixing. thanks.
(In reply to comment #40) > (In reply to comment #39) > > This is still an issue. I just didn't get around to test with that exact > > chipset yet. However the given modeline shows a picture on a GM45 chipset > > althoug, the picture is has just a far too strung red component so it's barely > > readable. > > > I'm confused. isn't you are using a Mac? Do you move to a new platform now? > The issue on the GM45 based platform should be opened as another bug.. Do you > also connect your PXA beamer to it? > I wish we can get user's update in time to help us prioritize bug fixing. > thanks. ping ~ BTW, have you tested the patch in comments #36? If it does not work I will send another one. I think our driver should detect HDMI-1, instead of TMDS-1. Thanks Ma Ling
Created attachment 27261 [details] pleaset try the patch on your machine, thanks. Hi Guido, If the patch in comments #36 doesn't work please try this one. Thanks Ma Ling
(In reply to comment #42) > Created an attachment (id=27261) [details] > pleaset try the patch on your machine, thanks. > Hi Guido, > If the patch in comments #36 doesn't work please try this one. > Thanks > Ma Ling ping ~
(In reply to comment #39) > This is still an issue. I just didn't get around to test with that exact > chipset yet. However the given modeline shows a picture on a GM45 chipset > althoug, the picture is has just a far too strung red component so it's barely > readable. > Guido, would you elaborate more on the GM45 platform you use now, such as logs with modedebug on? I assume it's not a Mac anymore, right?
(In reply to comment #34) the modeline does indeed seem to work on the Mac Mini.
(In reply to comment #42) I can't check this easily. Is there a way to test this with 2.3.2? I backported the patch but it didn't change anything, possibly because there's HDMI code missing in 2.3.2? Since this is a production machine I'll have to build a sid chroot with Xorg in it, that will take some time until I get around to do that.
(In reply to comment #44) attached as xorg.gm45.log
Created attachment 27612 [details] Xorg.log for GM45 chipset Sony Vaio TT
(In reply to comment #46) > (In reply to comment #42) > I can't check this easily. Is there a way to test this with 2.3.2? I backported > the patch but it didn't change anything, possibly because there's HDMI code > missing in 2.3.2? Since this is a production machine I'll have to build a sid > chroot with Xorg in it, that will take some time until I get around to do that. No the patch in comments #42 is for sdvo not hdmi, so could you please update your driver, because we have made a lot of work on sdvo? Ma Ling(In reply to comment #47) > (In reply to comment #44) attached as xorg.gm45.log If you changed platform, please reopen another bug.
looks like now the bug is a dup as other bugs about how to read out EDID correctly on Mac.
(In reply to comment #50) > looks like now the bug is a dup as other bugs about how to read out EDID > correctly on Mac. For this requestion,Guido please try the below patch -http://bugs.freedesktop.org/attachment.cgi?id=26873, which can fetch edid for dvi output in UMS mode. Thanks Ma Ling
(In reply to comment #51) > (In reply to comment #50) > > looks like now the bug is a dup as other bugs about how to read out EDID > > correctly on Mac. > For this requestion,Guido please try the below patch > -http://bugs.freedesktop.org/attachment.cgi?id=26873, > which can fetch edid for dvi output in UMS mode. > Thanks > Ma Ling ping ~
(In reply to comment #52) I would but currently 2.8.0 fails to detect any output besides LVDS: ~$ xrandr xrandr: Output DVI2 is not disconnected but has no modes Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1366x768 59.9*+ 1360x768 59.8 1024x768 85.0 75.0 70.1 60.0 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 DVI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) DVI2 connected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) (with and without the patch)
Scratch that actually. Detection of another HDMI monitor (HP w2207h) just worked fine. Seems to be a problem with the PT-AX100E and so I retested with the PT-AX100E and the GM45 (as requested): First of all using the patch comment #51 makes no difference. I always get the output from comment #53. If then do: $ xrandr --newmode 1280x720 74.25 1280 1319 1367 1648 720 724 729 750 xrandr: Output DVI2 is not disconnected but has no modes $ xrandr --addmode DVI2 1280x720 xrandr: Output DVI2 is not disconnected but has no modes $ xrandr --output DVI2 --mode 1280x720 I get the redish output as described in comment #39.
(In reply to comment #54) > Scratch that actually. Detection of another HDMI monitor (HP w2207h) just > worked fine. Seems to be a problem with the PT-AX100E and so I retested with > the PT-AX100E and the GM45 (as requested): > > First of all using the patch comment #51 makes no difference. I always get the > output from comment #53. If then do: > Guido, looks like the projector is quite unfriendly to us. :) a couple of things need your response: 1) I remember previously, at least the AX100E can be detected automatically on the GM45-based laptop as connected, according to comment# 48. we would like to know why it's always show disconnected with 2.8.0 driver now. Could you please attach the xorg.log with option "modedebug" "true"? just start into X, no need to try to bring the project up with any trick... 2) you mentioned that the modeline of 1280x720 74.25 1280 1319 1367 1648 720 724 729 750 works with the projector when connected to Mac mini in comment# 45. Could you reproduce that with 2.8.0 with the same trick you do on the GM45 laptop? > $ xrandr --newmode 1280x720 74.25 1280 1319 1367 1648 720 724 729 750 > xrandr: Output DVI2 is not disconnected but has no modes > $ xrandr --addmode DVI2 1280x720 > xrandr: Output DVI2 is not disconnected but has no modes > $ xrandr --output DVI2 --mode 1280x720 > > I get the redish output as described in comment #39. >
(In reply to comment #55) > (In reply to comment #54) > > Scratch that actually. Detection of another HDMI monitor (HP w2207h) just > > worked fine. Seems to be a problem with the PT-AX100E and so I retested with > > the PT-AX100E and the GM45 (as requested): > > > > First of all using the patch comment #51 makes no difference. I always get the > > output from comment #53. If then do: > > > > Guido, looks like the projector is quite unfriendly to us. :) a couple of > things need your response: > > 1) I remember previously, at least the AX100E can be detected automatically on > the GM45-based laptop as connected, according to comment# 48. we would like to > know why it's always show disconnected with 2.8.0 driver now. Could you please > attach the xorg.log with option "modedebug" "true"? just start into X, no need > to try to bring the project up with any trick... > Guido, the projector is actually detected as "connected" in comment# 53, rather than disconnected. please ignore the first part of 1) above. However, A xorg.log with option "modedebug" "true" would still help us to figure out why there is no valid mode in the EDID got from the projector, which is the root cause of the bug... Please help upload the xorg.log. thanks.
ping..
ping~
Agree with what Michael said in comment #50. It is a duplicated bug of the bugs about how to read EDID on mini-Mac. When the monitor is connected through the DVI apadptor, the system can't read the EDID. As it is marked as connected, the xsever will add the default mode for the output device. But unfortunately some modes can't be supported. For example: 1280x720, 1280x720. So there exist the following two issues on this mini-mac. 1. it can't read EDID through the mini-dvi to DVI adaptor. 2. If we solve the first issue, we can't parse the detailed timing mode from additional EDID block. In fact this issue happens when the gm45 is used. Now I am working on this issue. thanks.
please try this patch posted in bug# 23098. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg42703.html
*** This bug has been marked as a duplicate of bug 23098 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.