Summary: | [SDVO-TV UMS]Sometimes X doesn't start on D945GCLF2 with only TV connected | ||
---|---|---|---|
Product: | xorg | Reporter: | georgy@kibardin.name <george-kibardin> |
Component: | Driver/intel | Assignee: | ykzhao <yakui.zhao> |
Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | CC: | haien.liu, michael.fu, sven.ginka |
Version: | unspecified | Keywords: | NEEDINFO, patch |
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Description
georgy@kibardin.name
2009-03-21 03:52:48 UTC
Try more times is usually method to make TV light up, even on my LF2 board BIOS can't seem to light up TV every time. Have you tried to tune on i2c delay timers to see if external SDVO device likes more delays? As far as I understand the logic there is no timeout, after some replies with "pending" status we get "success" with no devices detected: (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Success) Then, I made a conclusion that TV detection fails sometimes and in this case sending the command again looks like the only solution. P.S. My board's bios sometimes also doesn't light up a TV, but when it does in most cases it is out of sync. why 5? is it the best number you've tried? have you tried if 2 will just work for you? Once or twice it required 3 attempts. So, I decided that 5 would be enough :) Hi George, Could you please upload your log file with modedebug option on? Thanks Ma Ling Created attachment 24470 [details]
Debug log
Sure.
Actually, the log fragment I mentioned before was also created with debug mode on
Created attachment 24603 [details]
Could you please try the debug patch on your machine, then upload log with modedebug option on, thanks.
I tried several times and it looks like this works. In logs I use to get something like this: (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 08 00 (Success) Sometimes it is just 3 lines: (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 08 00 (Success) So, Wang was right it is about timeouts! Thank you! (In reply to comment #8) > I tried several times and it looks like this works. > In logs I use to get something like this: That means the patch work for you? Created attachment 24629 [details]
please try the patch on your machine, thanks.
hi George,
Could you please try the general debug patch on your machine?
Thanks
Ma Ling
First time I tried to restart X after applying this patch I got: (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Success) as you can see no displays are detected. Best, George (In reply to comment #11) > First time I tried to restart X after applying this patch I got: > (II) intel(0): SDVOB: W: 0B > (SDVO_CMD_GET_ATTACHED_DISPLAYS) > (II) intel(0): SDVOB: R: 00 00 (Pending) > (II) intel(0): SDVOB: R: 00 00 (Success) > as you can see no displays are detected. > Best, > George So only the patch in comments #7 is useful to you ? Yes, but this looks very strange. Maybe first time I was lucky and accidentally had no problems. I'll try #7 again. h(In reply to comment #13) > Yes, but this looks very strange. Maybe first time I was lucky and accidentally > had no problems. I'll try #7 again. George, do you have some update :-)? Thanks Ma Ling Sorry, I ran out of time for a while. I hope this weekend I try it. Finally with #7 I got: (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 00 00 (Success) so, no device connected. Created attachment 24859 [details]
please try the patch on your machine, thanks.
Sdvo device shall act on optcode and update
commmand status register within 15 micro-seconds, but our code has waited for 50 micro-seconds. BTW could you have another the same brand and model machine or sdvo card to try this issue?
thanks
maling
The very first reboot I got: (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Success) Unfortunately, I have no other intel device :( Created attachment 26795 [details]
please try the debug patch against latest driver on your machine
The patch attempt to detect connection status at multiple times (5 as you suggested), please try it.
Thanks for your help
Ma Ling
(In reply to comment #19) > Created an attachment (id=26795) [details] > please try the debug patch against latest driver on your machine > The patch attempt to detect connection status at multiple times (5 as you > suggested), please try it. > Thanks for your help > Ma Ling Ping ~ Sorry, I'm a bit out of time currently, but, I hope, this week I'll test it. *** Bug 20639 has been marked as a duplicate of this bug. *** This patch works. I got this in logs: (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Pending) (II) intel(0): SDVOB: R: 00 00 (Success) (II) intel(0): SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) (II) intel(0): SDVOB: R: 08 00 (Pending) (II) intel(0): SDVOB: R: 08 00 (Pending) (II) intel(0): SDVOB: R: 08 00 (Pending) (II) intel(0): SDVOB: R: 08 00 (Pending) (II) intel(0): SDVOB: R: 08 00 (Success) Thank you! Thanks for the testing. From the test it seems that it can work well only when the SDVO command is sent several times. If so, IMO this will be related with the hardware issue. Will you please also attach the vbios dump? Thanks. vbios dump - how to do this? # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom then submit teh rom.bin Created attachment 29252 [details]
ROM dump
Sorry for delay :(
Created attachment 29549 [details] [review] Add some delay for SDVO tv detection Will you please try this debug patch on the latest intel-graphics driver and see whether the SDVO-TV can be detected correctly? thanks. Its not that easy. First I need to upgrade a lot of stuff then I need to port my patch (those one attached to https://bugs.freedesktop.org/show_bug.cgi?id=20684 and also posted to mailing list) to the latest version, so, this will take a while. ping~ George Kibardin PING George Kibardin with 56(84) bytes of data. 64 bytes from George Kibardin: icmp_seq=1 ttl=55 time=5.95 ms 64 bytes from George Kibardin: icmp_seq=2 ttl=55 time=4.86 ms 64 bytes from George Kibardin: icmp_seq=3 ttl=55 time=4.94 ms ..... Sorry, I hope this week I find some time to upgrade (my current xorg is 1.5.3 which is not enough to build 2.8.1) Created attachment 29898 [details] [review] New SDVO properties It looks like upgrade is almost complete so I'll check the patch. BTW, I've ported new SDVO properties forward to 2.8.1. Please take a look. (In reply to comment #32) > Created an attachment (id=29898) [details] > New SDVO properties > > It looks like upgrade is almost complete so I'll check the patch. > > BTW, I've ported new SDVO properties forward to 2.8.1. Please take a look. This is to add the SDVO-TV property in UMS mode. Is it still necessary to add it in UMS mode? As a whole, it is ok. But I have the following problems. a. the picture enhancement property should be defined for every SDVO device. Maybe there exist two SDVO devices with the picture enhancement property. b. whether the property should be added based on the enhancement capability. After you finish it, please send it to intel-gfx mailing list. thanks. Do you mean that everything is supposed to happen in KMS? I could port it there, but it looks like in this case it is still required to do something in UMS (at least to transfer the settings to KMS). About more than one SDVO devices. Do you mean that i830_sdvo_priv is shared between theese devices? P.S. For now the patch is still ok :) The UMS will not be supported again. So please try the debug patch in https://bugs.freedesktop.org/show_bug.cgi?id=24290#C6 and see whether the issue still exists(Please do the test in KMS mode). Thanks. (In reply to comment #35) > The UMS will not be supported again. So please try the debug patch in > https://bugs.freedesktop.org/show_bug.cgi?id=24290#C6 and see whether the issue > still exists(Please do the test in KMS mode). > Thanks. From the description it seems that the SDVO-TV sometimes can't be detected correctly. But sometimes it can be detected correctly. It has the same issue with the bug 24290. So please try the debug patch in bug24290#c6 and see whether the issue still exists. And this bug will be marked as the dup of bug24290. Thanks. *** This bug has been marked as a duplicate of bug 24290 *** About my patch with new SDVO properties. I found that all these properties are implemented in kernel mode so, my patch is almost unnecessary. The only problem is that I don't quite get how to use these properties? They don't seem to be accessible via xrandr or xorg.conf (In reply to comment #37) > About my patch with new SDVO properties. I found that all these properties are > implemented in kernel mode so, my patch is almost unnecessary. The only problem > is that I don't quite get how to use these properties? They don't seem to be > accessible via xrandr or xorg.conf > The property can be adjusted by using xrandr. Thanks. |
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.