Andrei Borzenkov composed on 2015-03-28 08:03 (UTC+0300):
Fri, 27 Mar 2015 06:23:52 -0400 Felix Miata composed:
FWIW, since my last response in this thread I have done a BIOS Vivid beta HTTP installation, mainly to be able to try and figure out how Grub2 configuration works without fouling openSUSE installations with a mix of bootloaders. As yet, allowing boot from its Grub2 instead of openSUSE's Grub Legacy I have yet to see the first Kubuntu boot message, no matter what I do in edit mode in the Grub2 menu. I get nothing but black until the SDDM greeter shows up. Booted from Grub2 the Kubuntu ttys are using broken EDID claiming 1280x1024 while the actual native that makes circles look like circles is 1440x900. Booting Vivid from openSUSE's Grub Legacy it's a simple matter of video=1440x900@60 producing the expected result.
Do you mean that adding the same parameter to grub2 command line does not work?
At this point I don't remember the time period when I posted the above. However, in more recent hours, I have been trying to make progress on several fronts WRT Vivid. To that end, I've tried to get re-subscribed via https://lists.gnu.org/mailman/listinfo/bug-grub without success, being black-holed by Earthlink, and waiting on follow-up response from grub-devel-owner after replying to his initial response. To answer your immediate question, video=1440x900@60 does currently work for the vttys, and get picked up by Xorg, whether on Grub Legacy cmdline or Grub2 cmdline. http://fm.no-ip.com/Tmp/Linux/Buntu/ contains varous cmdline iterations and resulting fbset output in the form cmdline2015032#####.txt. Sorting that listing by date you can find and examine which iteration of /etc/default/grub and /boot/grub/grub.cfg each followed, though nothing is indicative whether I edited the cmdline before hitting F10, only the net results. Outputs from vbeinfo and monitor-edid are there too, along with one Xorg.0.log from proper operation. What I've been trying to figure out since is why video=1440x900x## does not work with either GRUB_GFXPAYLOAD or GRUB_GFXPAYLOAD_LINUX. My current thought is that limitation may be the same as or related to $SUBJECT OP's failure to make 1920x1080 work on his UEFI 13.2 installation, a mode Grub2 cannot use cannot be slipstreamed directly to the kernel. My particular problem seems to have been reported on http://ubuntuforums.org/showthread.php?t=1474799&p=9256938#post9256938 5 years ago, and apparently not yet solved. So, my other thought is it may be that the two of us have 16:10 (41cm x 26cm) displays manufactured with the same broken EDID claiming to have a 5:4 mode (1280x1024) as native. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org