Arch Linux

Attached is the Xorg.0.log file from a successful boot. Note that the difference is what happens after unloading the fbdevhw submodule. In the broken log (patched xf86-video-fbdev), x startup dies right there. In the working log (xf86-video-fbdev patches 3 & 4 removed), x startup goes on to load both the vbe and int10 submodules, and then successfully initialises vesa. Patch 3 seems to short-circuit the loading of vbe and int10 (and the subsequent vesa initialisation).

Let me know if you need any other logs.

As far as I can tell, patch 3 breaks vesafb. I've tried a number of workarounds, none successfully. So far, the only thing that works is building out the package without patches 3 & 4.

What bothers me is that the archiso live media boots up and starts X successfully. The installation, extracted from the same live media, doesn;t work. Since the installation is just an unsquashed replica of the live media's root partition, it's practically identical, but only works with the modified version of xf86-video-fbdev. The only differences are the initramfs hooks (no archiso hooks - and yes, I've tried adding the kms hook) and the installation uses grub vs syslinux for its bootloader. I've burrowed down into both trying to figure out if there's some other difference, but I can;t find anything else. I think you'd agree, that if there is something in the system setup that can be done to satisfy patch 3, that would be preferable to modifying the patch. Any ideas?

Ok. I did some manual code tracing and I believe what's happened is that patches 3/4 break the fbdev failsafe - and I think it's fixable.

First, I want to let you know that including virtualbox-guest-modules-arch does 'fix' the problem - X starts up successfully with vboxvideo. This is not an unacceptable solution for me - I'll just include the modules with every build going forward. However, the fbdev failsafe was coded for a reason and it does work when needed and when used properly as a failsafe.

Both FBDevPciProbe and FBDevPreInit ultimately call either fbdev_pci_open or fbdev_open, depending on the value of the pci_device pointer. If the pointer is null, fbdev_open is called; if the pointer is not null, fbdev_pci_open is called. If the pci data is garbage and fbdev_pci_open is called, the operation fails, and I believe that's what's happening when running the OS in vbox without the vboxvideo driver. The failsafe occurs when you pass NULL to either FBDevPciProbe or FBDevPreInit. A NULL pci_device pointer parameter will cause both of these functions to call fbdev_open instead of fbdev_pci_open, and that's the key to the failsafe. If fbdev_open first tries to acquire the name of the framebuffer device via the environment (dev = getenv("FRAMEBUFFER")) and if it's unable to get the device name, it makes a last ditch effort using /dev/fb0. I believe that's how it worked when fbdev was unable to acquire valid pci data for the system graphics device (vbox without vboxvideo).

I think this can be fixed as follows:

FBDevPciProbe:

if (fbdevHWProbe(dev, device, NULL)) {
pScrn->driverVersion = FBDEV_VERSION;
pScrn->driverName = FBDEV_DRIVER_NAME;
pScrn->name = FBDEV_NAME;
pScrn->Probe = FBDevProbe;
pScrn->PreInit = FBDevPreInit;
pScrn->ScreenInit = FBDevScreenInit;
pScrn->SwitchMode = fbdevSwitchMode;
pScrn->AdjustFrame = fbdevAdjustFrame;
pScrn->EnterVT = fbdevEnterVT;
pScrn->LeaveVT = fbdevLeaveVT;
pScrn->ValidMode = fbdevValidMode;

xf86DrvMsg(pScrn->scrnIndex, X_CONFIG,
"claimed PCI slot %d@%d:%d:%d\n",
dev->bus, dev->domain, dev->dev, dev->func);
xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"using %s\n", device ? device : "default device");
}
else if (fbdevHWProbe(NULL, device, NULL)) {
pScrn->driverVersion = FBDEV_VERSION;
pScrn->driverName = FBDEV_DRIVER_NAME;
pScrn->name = FBDEV_NAME;
pScrn->Probe = FBDevProbe;
pScrn->PreInit = FBDevPreInit;
pScrn->ScreenInit = FBDevScreenInit;
pScrn->SwitchMode = fbdevSwitchMode;
pScrn->AdjustFrame = fbdevAdjustFrame;
pScrn->EnterVT = fbdevEnterVT;
pScrn->LeaveVT = fbdevLeaveVT;
pScrn->ValidMode = fbdevValidMode;

xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"using %s\n", device ? device : "default device");

}
else {
pScrn = NULL;
}

FBDevPreInit:

if (!fbdevHWInit(pScrn, pci_dev, xf86FindOptionValue(fPtr->pEnt->device->options, "fbdev")))
if (!fbdevHWInit(pScrn, NULL, xf86FindOptionValue(fPtr->pEnt->device->options, "fbdev")))
return FALSE;


I can test this solution and let you know if it works as expected, but this would restore the fbdev failsafe.

The above solution does indeed work as expected. It restores the failsafe.

fbdev.c is attached. If you decide to use it, please let me know.

Meanwhile, I'll include virtualbox-guest-modules-arch in my builds.

You should report this upstream to confirm this is a proper fix.

You might also want to apply at least one more commit that seems important:
https://cgit.freedesktop.org/xorg/driver/xf86-video-fbdev/commit/?id=2c5eba85740e6a7ced8ada0ee45fdd74e4bca364

Please test xf86-video-fbdev-0.4.4+12+ge0bce0d-1, this version is 10 commits newer than the current version in repository. If this doesn't fix your problem, please file a bug upstream instead.