|
Bugzilla – Full Text Bug Listing |
| Summary: | X segfaults in VIA driver when the "-configure" option is used | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.2 | Reporter: | Jiri Dluhos <jdluhos> |
| Component: | X.Org | Assignee: | Forgotten User tIuQKvCA4l <forgotten_tIuQKvCA4l> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Enhancement | ||
| Priority: | P4 - Low | CC: | markgray+to-suse, sass.joel, sndirsch, tee |
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Jiri Dluhos
2009-03-03 17:34:01 UTC
Ummm... are you really, 100%, sure that fixing a crash in X server (one that prevents standardized automatic configuration) is just an *enhancement*? :-O (Of course, fixing it would definitely enhance some users' experience...) (In reply to comment #1) > Ummm... are you really, 100%, sure that fixing a crash in X server (one that > prevents standardized automatic configuration) is just an *enhancement*? It is a feature which has been broken for some time due to "bit-rot" and nobody has missed it. It is doubtful that it ever actually worked very well since DDC is only recently starting to work, and does not work on quite a lot of hardware even today. It duplicates functionality which SaX2 will always perform much better. Apart from a brief mention on the Xfree86 4.01 wiki it is undocumented ("X -help" does not list it as an option, nor does "man xserver"). While i overstepped my brief as a screener by opining that it was an ENHANCEMENT, not a major bug hampering the release of 11.2, I have to ask: Once you removed the via driver, did "X -configure" actually produce a particularly usable xorg.conf? > It is a feature which has been broken for some time due to "bit-rot" and nobody > has missed it. I don't think this feature is useless. Yes, it is not needed in normal installation course which configures X server automatically. However, there are at least two cases when it is very useful: 1) Changing the graphics card in the computer to a type that needs another driver. In this case, X will not start on boot, and you can either manually rewrite the SaX-generated xorg.conf (which is quite complex and difficult to read), or use the autoconfiguration to give you a start. 2) When the SaX setup during the installation fails. This is almost 100% if you have more than one monitor (quite common in laptops connected to an external monitor) or more than one gfx card (increasingly common in laptops with dual powersave/performance hardware) and also with some new gfx cards; I had a laptop where SaX left the user with a black screen. > It duplicates functionality which SaX2 will always perform much better. I am sorry to say that, according to my experience, the reverse is true; SaX fails in many cases (see above) and the xorg.conf file produced by SaX is quite oldschool (it contains lots of stuff that gets completely ignored and only makes the conf file difficult to read) :-( > I have to ask: Once you removed the via driver, did "X -configure" actually > produce a particularly usable xorg.conf? Yes, it did :-) As the person who has been working on the via driver and on modesetting for more than 5years, and who has come up with quite a few of the advances in modesetting in this millenium, i can only say the following: F -configure and F sax.
I'll give it a quick try on my hw, but i won't be changing my view that -configure needs to die:
3c0b77c8 (Luc Verhaegen 2005-12-14 11:37:04 +0000 957) if (flags & PROBE_DETECT) {
3c0b77c8 (Luc Verhaegen 2005-12-14 11:37:04 +0000 958) xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "libv doesn't believe in "
3c0b77c8 (Luc Verhaegen 2005-12-14 11:37:04 +0000 959) "PROBE_DETECT calling PreInit.\n");
60f73e46 (Luc Verhaegen 2004-03-01 11:36:09 +0000 960) return FALSE;
3c0b77c8 (Luc Verhaegen 2005-12-14 11:37:04 +0000 961) }
We were trying to get rid of sax for ages, but were too busy changing the world with the radeonhd driver. Now, given novells new tactic, guess what we will be left with for much, much, much longer?
As an outsider i was unaware of the openSUSE plans for sax/X. I have always been impressed at how well SaX2 worked: neither Fedora nor Ubuntu configure X correctly for my hardware (the external monitors do not work), so I always assumed SaX2 was light-years ahead of the tools shipped with X.org. (I will butt out now.) (In reply to comment #3) > 1) Changing the graphics card in the computer to a type that needs another > driver. In this case, X will not start on boot, and you can either manually > rewrite the SaX-generated xorg.conf (which is quite complex and difficult to > read), or use the autoconfiguration to give you a start. Or boot into failsafe for a fbdev/vesa driver base X configuration. On top of it run YaST/SaX to reconfigure your new graphics hardware. > 2) When the SaX setup during the installation fails. This is almost 100% if > you have more than one monitor (quite common in laptops connected to an > external monitor) or more than one gfx card (increasingly common in laptops > with dual powersave/performance hardware) and also with some new gfx cards; I > had a laptop where SaX left the user with a black screen. SaX2 has been improved to always only create a configuration for the primary graphics card. > I am sorry to say that, according to my experience, the reverse is true; SaX > fails in many cases (see above) and the xorg.conf file produced by SaX is > quite oldschool (it contains lots of stuff that gets completely ignored and > only makes the conf file difficult to read) :-( SaX2 is doing to much. This is correct. See also Bug #441404, Bug #440973, that we're aware of this. But as you might know the X team has been downsized as well. :-( (In reply to comment #0) > Proposal: the VIA driver should be fixed to behave more politely when it does > not find its hardware; or, if it is too broken, it should be expelled into its > own package so it can be picked by users who know they have this card. The unichrome driver is already in its seperate package. What I could do is removing the requires to xorg-x11-driver-video-unichrome from xorg-x11-driver-video and add Supplements for 0x1106#0x3122#VT3122: CLE266 0x1106#0x7205#VT7205: KM400, KM400A, KN400, P4M800 0x1106#0x3108#VT3108: K8M800, K8N800, K8N800A to xorg-x11-driver-video-unichrome, so YaST autoselects it for installation if the appropriate hardware has been detected. (In reply to comment #8) > The unichrome driver is already in its seperate package. What I could do is > removing the requires to xorg-x11-driver-video-unichrome from > xorg-x11-driver-video and add Supplements for > > 0x1106#0x3122#VT3122: CLE266 > 0x1106#0x7205#VT7205: KM400, KM400A, KN400, P4M800 > 0x1106#0x3108#VT3108: K8M800, K8N800, K8N800A > > to xorg-x11-driver-video-unichrome, so YaST autoselects it for installation if > the appropriate hardware has been detected. done for Factory. *** Bug 491593 has been marked as a duplicate of this bug. *** *** Bug 497427 has been marked as a duplicate of this bug. *** This is simply a WONTFIX. Remove your xorg.conf and run 'X' if you want to use the Xserver's driver autoconfiguration. This will also be the default for factory. |