Hello everyone,
Yesterday Trevor mentioned that Brad (was it him?) is having issues getting video output on Fedora 32 using a Matrox G200e.
Coincidentally, I have a server with the exact same video card that I can use for testing.
After updates, same issue happened here. No video.
The fix:
1) Obviously, we need to boot first. So edit the GRUB boot entry and pass the parameter "vga=793" right after "quiet".
2) Then, edit /etc/default/grub and, on GRUB_CMDLINE after quiet, add
(...) quiet -- vga=793"
Last time I looked, the "--" after the last parameter will ensure that any Kernel updates and whatnot will not remove this parameter. That may have changed, it's been a while, but it does work anyway.
Then, reinstall GRUB.
The issue:
card sees a monitor that supports a higher resolution than it can display, tries to use it, fails miserably. That parameter will force the 1280x1024 resolution, which is working fine on my 1080p display.
* To see all modes, pass "vga=ask" after quiet. Press ENTER to see available modes.
* To use another one, convert the Mode for the desired Resolution to decimal. To do so, I used:
printf "%d\n" 0x319 (for 1280x1024)
Equals 793. vga=793. :D
(obviously, most of that is most likely redundant to some - or even most - here. Still, in case it is useful to someone, there it is!)
On 2020-12-09 Alberto Abrao wrote:
Yesterday Trevor mentioned that Brad (was it him?) is having issues getting video output on Fedora 32 using a Matrox G200e.
Thanks Alberto! I thought there might be a cmd line workaround. We'll try that out asap. His monitor is probably only 1024x768 but I'll just lookup the code for that.
The kernel messages we got made it sound like something worse was going on, but perhaps it was misleading. If you don't hear back, assume it worked!
Again, thanks. And we'll see if my RHBZ gets anywhere on it eventually, as obviously one shouldn't have to hack the cmd line to make it work (as it did for 7+ years).
On 2020-12-13 11:00 p.m., Trevor Cordes wrote:
Thanks Alberto! I thought there might be a cmd line workaround. We'll try that out asap. His monitor is probably only 1024x768 but I'll just lookup the code for that.
The kernel messages we got made it sound like something worse was going on, but perhaps it was misleading. If you don't hear back, assume it worked!
Again, thanks. And we'll see if my RHBZ gets anywhere on it eventually, as obviously one shouldn't have to hack the cmd line to make it work (as it did for 7+ years).
Hello Trevor,
I hope it helps!
I will kindly ask you to let me know if it does not work. The machine is still here and I am willing to poke around to reproduce any other issues you may find.
I posted a message there as well to see if it helps them find the culprit. It should "just work" like you mentioned. Last time I had to mess with video modes on Linux, I was using XFree86 on a Trident 9000-something.
On 2020-12-14 Alberto Abrao wrote:
I will kindly ask you to let me know if it does not work. The machine is still here and I am willing to poke around to reproduce any other issues you may find.
Turns out it did work! Thanks! I found a table of all the vga= values on the net.
The video works on boot now, but it takes 120s to boot until it reaches a point where it switches to a vga mode that isn't slow as molasses. I think we've all seen over the years at least one time where a boot console scrolls like a 1200 baud modem. That's what we're seeing here with the new vga mode, obviously it's a barebones non-accelerated mode.
I have no idea why it eventually switches to a faster mode and still works! But I'm not complaining.
Since we never reboot that box, an extra 2 mins during reboot is not important. So problem solved (in terms of good workaround found)!
On 2020-12-18 7:19 p.m., Trevor Cordes wrote:
Turns out it did work! Thanks! I found a table of all the vga= values on the net.
The video works on boot now, but it takes 120s to boot until it reaches a point where it switches to a vga mode that isn't slow as molasses. I think we've all seen over the years at least one time where a boot console scrolls like a 1200 baud modem. That's what we're seeing here with the new vga mode, obviously it's a barebones non-accelerated mode.
From my research, passing vga=ask will give you the codes for modes supported by the video adapter on the system. Those would be accelerated.
May I ask you to share the code you used? I would love to see if it results in the same behavior on my end :)
I will also give you a code for 1024x768 straight from the vga=ask + converted to pass as a vga= parameter to the kernel so you can test and see if it, pun may be intended, accelerates.
Kind regards,
On 2020-12-19 9:24 a.m., Alberto Abrao wrote:
I will also give you a code for 1024x768 straight from the vga=ask + converted to pass as a vga= parameter to the kernel so you can test and see if it, pun may be intended, accelerates.
Hello again everyone,
Trevor, I have just tried vga=791 here and it works for 1024x768, without the symptom you described. (vga=791 corresponds to 1024x768x16)
vga=792 is for 1024x768x32, which also seems OK.
I am curious to try the code you used, just to see if the same thing happens here :)
Kind regards,
On 2020-12-20 6:02 p.m., Alberto Abrao wrote:
Hello again everyone,
Trevor, I have just tried vga=791 here and it works for 1024x768, without the symptom you described. (vga=791 corresponds to 1024x768x16)
vga=792 is for 1024x768x32, which also seems OK.
I am curious to try the code you used, just to see if the same thing happens here :)
Also, in case it is useful:
I took a picture of the output of vga=ask - all modes supported should be here. Just remember to convert the three-digit code before the desired resolution using:
printf "%d\n" 0x(code)
e.g.
printf "%d\n" 0x317 (for 1024x768x16)
https://muug.abrao.net/71aabbd2-cbcd-49bb-9ff3-6d6919108cfb.jpg
Please let me know if those are different than the ones you found. I am curious to know if these are video-interface specific or not.
Kind regards,
-
Alberto Abrao -
Trevor Cordes