Hi Douglas, On 17 Dec 2009, at 18:56, Douglas McClendon wrote:
> Gary C Martin wrote: >> Getting bored and answering some of my own email (I can't sleep)... > > Been there... > >> On 17 Dec 2009, at 08:21, Gary C Martin wrote: >>> Hi Wade, >>> On 13 Dec 2009, at 22:23, Wade Brainerd wrote: > >>>>> - Without some VM hacking, VirtualBox displays Sugar in an >>>>> 800x600 window. The interface scales reasonably well, all >>>>> things considered, but toolbars often have missing widgets, or >>>>> widgets in drop down overflow menus. Fonts are also very large >>>>> for an 800x600 view. >>>> Anyone know how to bake in the VirtualBox Guest Tools? Is there >>>> an RPM I can just add in? In my experience, they have to be >>>> compiled locally against whatever kernel you're running. > > Now I'm having bad flashbacks to my time working at vmware on their guest > tools linux packaging. > >>> No, I've always had to follow the VB documentation to compile them >>> each time. >>> However, I did stumble over a VirtualBox trick today I didn't think >>> would work (well it didn't quite, but...). If you hit F12 you can >>> get to fiddle with the kernel boot parameters, in my ignorance I >>> tried adding vga=0x117 hoping to get a 1024x768x16. It came back >>> with an error about unknown video mode, and then provided me an >>> option to see a list of them to choose from. I managed to boot it >>> into a 1024x768x32 display (with no guest additions). It booted all >>> the way to X starting, at which point it switched itself back to >>> 800x600. So I'm guessing there is some other X setting, or some >>> trick to tell X to use the current resolution. On stopping Sugar >>> the display resized back up to 1024x768x32 just before closing, so >>> pretty sure it's something X. >> I really don't know what I'm doing here, so this is likely not the >> right way, but after booting with the kernel parameters set to >> vga=0x345 for a 1280x1024 display (a choice close to the XO default >> of 1200x900), I then did: >> sudo Xorg -configure :1 cp /root/xorg.conf.new /etc/X11/xorg.conf >> [there's no xorg.conf by default, and I couldn't fathom how else to >> get X to use a higher resolution] > > > This is related to a fedora bug I filed a little over two years ago- > > (qemu/kvm not vb, but same issue) > > https://bugzilla.redhat.com/show_bug.cgi?id=251264 Oooh, I think I recognise parts of that from my googling :-) > My incomplete knowledge/summary of the subsequent history was- > > - everybody else (other live linux distros) used 'hacks' of some nature or > another to detect and better configure X in this situation. > > - redhat X folks were on a set of rails towards a configurationless X nirvana > > - some issue with qemu's pci vga emulation made it not work automagically in > the new world order > > - fedora for at least one release added in the same kind of hack that I > originally asked for > > - somehow that got reverted and it appears we are back to the old behavior. > (despite ajax's comment #16 in my bug, and other comments in the subsequent > cloned bug) Thanks, that gives me a better backstory (I feel slightly less dumb). > What you are doing with the vga=0x317 etc, is triggering a vesa mode with a > higher resolution. These vesa modes are a kind of fallback. Also it sounds > like the behavior you are getting is that the new bootsplash infrastructure > (plymouth) is utilizing the vesa mode, but then X when it autoconfigures does > not. > > In my own fedora derivatives, to fight this, I basically add to the > initscripts to detect qemu, and write out an xorg config (much like it sounds > like you did). Probably there is some better solution coming from upstream > 'eventually'. > > >> ...and rebooted. On subsequent boots (I'm still manually hitting F12 >> and adding a kernel vga parameter) Sugar now shows up in 1200x900, >> all without installing any VB guest additions :-) > > The only issue is that like the vmware guest additions, the VB guest > additions probably do add performance improvements. Possibly, though I have been using a F11 with guest additions and sugar-jhbuild for development work on my Mac, I don't notice any regressions so far. The tweaked Blueberry image now feels a better environment than trying to work in F11 with sugar-jhbuild on top; keys all work (cursors also), faster launch/shutdown direct into Sugar, no hidden Fedora widgets getting confused and/or nagging with their information bubbles. > My vague recollection is that the vmware guest additions were sufficiently > open sourced such that they would eventually land upstream, and thus not have > this problem (except for the zillions of vmware customers using > virtualization to run distros that are older and thus won't see the open > source version come from a newer X version). > > Also, you should be able to add the kernel vga parameter to your bootloader > config so you don't have to type it manually. Though since it is really the > xorg.conf that sets the resolution for real use (not just the splash), that > should be sufficient. I've just added my vga=0x345 to the /boot/grub/grub.conf file and it's booting into my resolution of choice with no manual intervention :-) I did notice a vga mode close to my native display 1900x1200, I'm quite tempted to give it a shot and make my little Sugar Blueberry applescript icon auto start it in fullscreen (no guest additions needed for fullscreen). > Executive summary- blah. I hope that rambling reduces more confusion than it > creates. Thanks, yea. :-) Regards, --Gary _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
