On Dec 14, 2009, at 5:44 PM, Adam Jackson wrote:

On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote:
On 12/11/2009 02:41 PM, Adam Williamson wrote:
On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote:
File a bug please, attaching your xorg.conf, Xorg.0.log and output of
the dmesg command (all from inside of VB virtual machine, of course).

...aaaand (oh boy, I love it when a plan comes together) mark it as
blocking F13Beta , because I reckon this breaks beta criterion #4:

https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria

I like the sentiment here, but I'm not sure this is really in the
spirit of the criteria - Vasily, as I understand it, is still in the
process of implementing the support for UEFI on VirtualBox.

There's at least two issues here.

One is that we're not shipping the native X driver for vbox video yet.
Last I checked this was because it's hidden away in the vbox source, and
didn't build against whatever X server we were shipping, and that vbox
upstream didn't _want_ it shipped externally yet because they hadn't
finalized the interface.

Right, looks like it isn't good time to package vboxvideo.

The other is that the kernel doesn't seem to be binding an efifb device
to it,

Kernel uses efifb, and progress bar with logo drawn in the center looks nice and correct.

and/or that it is and X is not noticing that and thus loads vesa
instead of fbdev.

X detects fbdev right (at least X -configure creates xorg.conf with right driver), but it couldn't detect modes (resolution)

using fbdev, thus X loads vesa to somehow fill the gaps imho.

#0 fbdev_open (scrnIndex=<value optimized out>, dev=0x1501fc "/dev/fb0", namep=0x0) at fbdevhw.c:412

#1 0x0014fc80 in fbdevHWProbe (pPci=0x0, device=0x0, namep=0x0) at fbdevhw.c:442

#2 0x00c5e4b5 in FBDevProbe (drv=0x8236b00, flags=<value optimized out>) at fbdev.c:394

#3 0x080a7c4e in xf86CallDriverProbe (drv=0x8236b00, detect_only=0) at xf86Init.c:663

#4 0x080a92fe in InitOutput (pScreenInfo=0x8212500, argc=1, argv=0xbfd96fc4) at xf86Init.c:939

#5 0x0806ba2b in main (argc=1, argv=0xbfd96fc4, envp=0xbfd96fcc) at main.c:315

fbdev_open with (,namep = 0x0,) doesn't call ioctl(/* /dev/fb0*/,FBIOGET_FSCREENINFO,), which might returns required information:

(gdb) call ioctl(fd,0x4602,(void*)(&fix))
$2 = 0
(gdb) p fix
$3 = {id = "EFI VGA\0\0\0\0\0\0\0\0", smem_start = 0x80000000 <Address 0x80000000 out of bounds>, smem_len = 6291456, type = 0, 
  type_aux = 0, visual = 2, xpanstep = 0, ypanstep = 0, ywrapstep = 0, line_length = 4096, mmio_start = 0x0, mmio_len = 0, accel = 0, 
  reserved = {0, 0, 0}}

ioctl(/* /dev/fb0*/,FBIOGET_FSCREENINFO,) called from fbdev_open with (,namep != 0x0,), but I am not sure how fbdevHWProbe(,namep != 0x0,) will affect probing algorithm and X working :) .