| Summary: | xf86-video-vga has blank screen on my VIA VT8623 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Jeremy C. Reed <reed> |
| Component: | Driver/VGA | Assignee: | Luc Verhaegen <libv> |
| Status: | RESOLVED WONTFIX | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | high | ||
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | NetBSD | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Jeremy C. Reed
2006-05-26 16:23:22 UTC
Since i just removed static dotclocks from the vga driver (for a range that is the two possible dotclocks plus a margin) this probably belongs to me. This graphics device is a VT3122 btw, as described on unichrome.sf.net, which is the _only_ naming scheme that is useful and sane. For starters: VGA compatibility is a fable, you should not be using it under any circumstances. IBM defined H/VSync and H/VBlank in such a way that they can not be expanded without breaking, and they are expanded on almost all hardware available today. This means that the chances of you getting a working mode with VGA are extremely small and that you should use the proper modesetting driver for your graphics device. I of course have a VT3122, and will verify this, but i do seem to recall that only 320x240 (doublescan) was an accepted mode for the vga driver. But if it is non-functional, then that's just what it is and chances of it getting fixed are extremely small. Ah. I just scrolled over your pci listing: ECS G320. Of course you won't get a working mode. What were you expecting? > Ah. I just scrolled over your pci listing: ECS G320. Of course you won't get a
> working mode. What were you expecting?
I am expecting that the documentation, preferably the manual page, to have some
details about this.
It is a little confusing to me, since my NetBSD system also has a vga(4) which
is not X related which is in current usage. I assumed my system has a generic
VGA-compatible video card.
The xf86-video-vga vga(4) manual page says: "The vga driver supports most
VGA-compatible video cards. There are some known exceptions, and those
should be listed here."
Is my situation something that should be listed in the manual page?
Should the Xorg server using "vga" be allowed to run and just have a blank/black
screen while clients are running (but unusable)? This seems like a bug to me and
this bug report should not be resolved.
I'd expect at least some indication that X is not working -- such as Xorg
closing with a clear error message.
I am reopening this bug. I believe the fix should be either in documentation or
having xf86-video-vga cleanly exit when unusable.
IMHO VGA is fundamentally broken on all recent hardware. Not everyone agrees. People insist on using it as a final fallback. My VT3122 gets 320x200@8bpp (mode 13h) on the CRT np, but i know that this is by sheer luck only. Also, VGA has no idea about output devices, the IBM PS/2 came with its own dedicated monitor. It has no idea about how to deal with your unichrome when set up to use the panel (scaler, some combination of primary/secondary/shadow, backlight, etc). If this driver is meant to be the final fallback, then you do not want to limit its use. I personally never want to dump users into this driver at all, but I am pretty much alone in that. As a VBE and BIOS hater, i currently would even prefer to write a basic (non VBE) int10 driver than to keep on using VGA as the final fallback. With a halfdecent VGA BIOS (which isn't a given), you would've enjoyed 320x200@8bpp on your panel. Should the manpage state the following then: "VGA was introduced in 1987 and wasn't designed with extensibility in mind. You can try this, but you might not get a mode at all, and there is no way for us to tell wether or not you have a useful image. You have been warned." Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. |
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.