X on UEFI systems.

[Vasily Levchenko]

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 :) .
> 
> - ajax
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20091214/3327cc13/attachment.htm>