Bug 18122 - xf86-video-chips: video chip not detected
Summary: xf86-video-chips: video chip not detected
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/chips (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-19 10:46 UTC by M. van den Hemel
Modified: 2009-07-19 01:43 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
lspci output (972 bytes, text/plain)
2008-10-19 10:46 UTC, M. van den Hemel
no flags Details
Xorg.log where the video chip is detected (31.92 KB, text/plain)
2008-10-19 10:47 UTC, M. van den Hemel
no flags Details
Xorg.log where the video chip is not detected (6.19 KB, text/plain)
2008-10-19 10:50 UTC, M. van den Hemel
no flags Details
Another Xorg.log where the video chip is not detected (CT65555) (5.04 KB, text/plain)
2009-05-01 07:01 UTC, Pierre Cardoso
no flags Details
possible patch (1.46 KB, patch)
2009-06-29 23:54 UTC, Matthieu Herrb
no flags Details | Splinter Review
working patch (2.64 KB, patch)
2009-07-05 07:59 UTC, Marien Zwart
no flags Details | Splinter Review

Description M. van den Hemel 2008-10-19 10:46:12 UTC
Created attachment 19744 [details]
lspci output

Since version 1.2.0 of xf86-video-chips my onboard PCI CT69030 is not detected anymore. Initing X (via startx) result in

'(EE) No devices detected' 

If I specify a generic Chips&Technologies video card (using xorgconfig), the CT69030 is detected, but the startup process still fails with the message above.

Older version of the same driver worked without problems, choosing a vesa driver also works.

I add three attachments:

- Output from lspci
- An Xorg.log which fails
- An Xorg.log of an older version, which worked.
Comment 1 M. van den Hemel 2008-10-19 10:47:56 UTC
Created attachment 19745 [details]
Xorg.log where the video chip is detected

This Xorg.log is of an older version and shows the CT69030 being correctly identified and used.
Comment 2 M. van den Hemel 2008-10-19 10:50:23 UTC
Created attachment 19746 [details]
Xorg.log where the video chip is not detected

This is an Xorg.log from cf86-video-chips version 1.2.0, where the video chip is not found.
Comment 3 Pierre Cardoso 2009-05-01 07:01:18 UTC
Created attachment 25333 [details]
Another Xorg.log where the video chip is not detected (CT65555)

Xorg 1.6.0
Comment 4 Pierre Cardoso 2009-05-01 07:02:39 UTC
Hello,
I have the very same problem since Ubuntu Intrepid, and it remains with Ubuntu Jaunty. I'm just providing here a copy of an Xorg.log which fails in ubuntu Jaunty - but it's very similar to the one already submitted.
My video chip is a CT65555.
My computer is a toshiba satellite 4000CDS.
Thanks,
Pierre
Comment 5 Marien Zwart 2009-05-22 13:37:00 UTC
There were two issues with the driver I had to fix to get it working in a libpciaccess-enabled world. I'm testing on a Toshiba 440CDT laptop with a C&T F65554 chipset.

The first bug is easy to fix, although it took me forever to spot it. On line 816 of ct_driver.c there is a call "xf86AddDriver(&CHIPS, module, 0);" that should be "xf86AddDriver(&CHIPS, module, HaveDriverFuncs);". Without passing this flag only the first part of the DriverRec structure is copied, missing the libpciaccess chips_device_match and CHIPSPciProbe functions. Because the driver passes NULL instead of CHIPSProbe for the old-style probe function if compiled with XSERVER_LIBPCIACCESS this leaves it with no probe functions and the failure in the logs on this bug.

(I guess no hardware was available to test the libpciaccess version of the driver? If I understand the code correctly it will not work with XSERVER_LIBPCIACCESS at all...)

Unfortunately fixing that bug exposes another problem, and I do not know how to fix it. On line 1205 of ct_driver.c it does "cPtr->Chipset = cPtr->pEnt->chipset;", and then compares cPtr->Chipset to various values from the CHIPSType enum, which is a driver-internal enum identifying supported chipsets, with valid values simply starting at 0. But the cPtr->pEnt->chipset value at that point is the pci device id (hoping that's the right term), in my case PCI_CHIP_65554, value 0xe4, which is not a valid CHIPSTYPE enum. So the code misidentifies the chipset and I get garbage.

Without libpciaccess CHIPSPCIchipsets ends up getting used to convert the pci device id to the driver's own chipset identifier. I do not know how to get the libpciaccess-based probe to do the same thing without doing it manually after the probe, which does not seem sane (makes no sense and might even break if the device is not actually probed through libpciaccess). For now I've hacked around it by inserting "if (cPtr->pEnt->chipset == PCI_CHIP_65554) cPtr->pEnt->chipset = CHIPS_CT65554;" before the assignment mentioned above. This makes the laptop work, but is obviously completely insane horrible code that should not make it into the driver.

I'm hoping this is enough information for someone who knows how the probe functions interact to fix this properly.
Comment 6 Matthieu Herrb 2009-06-29 23:54:21 UTC
Created attachment 27248 [details] [review]
possible patch

Can you test the attached patch?
Comment 7 Marien Zwart 2009-07-05 07:59:34 UTC
Created attachment 27396 [details] [review]
working patch

Sorry for the delay in testing this.

The "possible patch" did not work: it got the chipset wrong, leading to corrupt graphics and a segfault shortly after starting the server. The attached patch does work and might even be sane. Only tested with a ct65554 and libpciaccess though.
Comment 8 Pierre Cardoso 2009-07-12 08:49:26 UTC
Hello,
I managed to apply the "working patch" on the Ubuntu Jaunty version of the chips xserver ( 1.2.1-1 , as seen here http://packages.ubuntu.com/jaunty/xserver-xorg-video-chips ). This patch works with my computer (CT65555 chipset, Toshiba 4000CDS laptop).
Thanks.
Comment 9 Matthieu Herrb 2009-07-19 01:43:05 UTC
Thanks for the correct patch and testing
Pushed commit 722267e99012d0b8bbd7f22eaeac99e85bf48e0c


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.